Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#lang filetype detection is harmful #62

Open
dmitrii-ubskii opened this issue Jan 21, 2021 · 2 comments
Open

#lang filetype detection is harmful #62

dmitrii-ubskii opened this issue Jan 21, 2021 · 2 comments

Comments

@dmitrii-ubskii
Copy link

This needs to be configurable as to which dialects, or at least disableable. As it is now, adding vim-racket removes language support in vim, because what used to at least be recognized as ft=scheme is now ft=sicp or ft=br, which is worse than useless, unless you happen to have the specific plugin.

Temporary workaround for users of vim-plug:
Plug 'wlangstroth/vim-racket', { 'do': 'echo au BufRead,BufNewFile *.rkt,*.rktl set filetype=racket > ftdetect/racket.vim' }

@benknoble
Copy link
Contributor

This is at least partially my fault; I advocated for this on the basis that not all *rkt files are actually racket, and the racket syntax shouldn't try to highlight them all.

OTOH, br is now correctly mapped to racket, and it's trivial to add sicp/etc. (My fork adds, for example, info and info/setuptab, which it supports. My fork also supports the new jsond language, but it doesn't need extra configuration precisely because of the new mechanism.)

See g:racket_hash_lang_dict in ftdetect/racket.vim. It would be nicer to merge the user's config with the defaults, but I didn't do that yet as I haven't needed it.

benknoble added a commit to benknoble/vim-racket that referenced this issue Aug 14, 2021
Using
  let g:var = get(g:, 'var', default)
is an idiom for allowing a user to set the variable themselves but have
a default intact. In the case of lists/dictionaries, I use an empty
default and then extend() with the actual default: this essentially
merges the default with the user value. In the list case, there is no
way to not get the defaults; here, this should not be harmful. In the
dictionary case, I specify the 'keep' argument so that user values
override the defaults in case of a collision on keys.

Note that it is probably silly to override
g:racket_hash_lang_modifiers_regex or g:racket_hash_lang_regexp, but I
allow it anyway.

Related: wlangstroth#62
@benknoble
Copy link
Contributor

I've pushed a commit in my fork which supports user overriding much easier. Simply let g:racket_hash_lang_dict = … to install your own overrides, which are merged with some reasonable defaults (user values take precedence).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants