It was superseded by g:vue_pre_processors (#133)
I could add a message if g:vue_disable_pre_processors is set, asking
people to update their config to the new variable, but I'd rather not
interrupt people's workflows.
close#131
Setting this option seems to do more harm than good. To avoid confusion, it's better to remove it altogether.
Currently, the recommended approach to use existing plugins for HTML, CSS or JavaScript, is to explicitly configure that plugin to support Vue files.
The plugin's current behavior is reliant on the order of loading
pre-processor syntax files. In particular, Vader tests are failing for
SCSS snippets; SASS syntax identifiers are applied instead.
Unfortunately, no ordering information can be embedded in a Dictionary,
so s:language_config must be turned into a List.
In the unconfigured case (no g:vue_disable_pre_processors, no
g:vue_pre_processors), pre_processors can be initialized to a
well-ordered List of languages (ordered as they appear in
s:language_config), instead of the unstable keys() on a dict.
Random access of language config is faster from a dict, though, so a
dict is rebuilt in s:language_dict. Going through the s:language_config
List for every pre-processor in pre_processors is O(m * n), as opposed
to building s:language_dict once then looping through pre-processors
once for O(m + n) (since dict access is constant time).
The change in commit ba9a3dbc4e is
documented in the README, to augment the information regarding
pre-processor languages and g:vue_disable_pre_processors.
Prior to this commit, there was a single Boolean option,
g:vue_disable_pre_processors, which would only activate either *every*
pre-processor syntax file or none of them at all.
This was a known pain point when it comes to performance. On some
machines, loading all the pre-processor syntax files could slow down Vim
noticeably, hence the need for such an option in the first place.
However, turning all of them off means having to live with no syntax
highlighting at all if one uses a pre-processor language.
This commit introduces another option: g:vue_pre_processors. This is a
List of names of pre-processor syntaxes, e.g. ['pug','scss']. If a user
provides this option, only the named pre-processor syntax files will be
loaded.
This change still allows for g:vue_disable_pre_processors: If
g:vue_disable_pre_processors is truthy, pre-processor syntax files
aren't loaded regardless of the value of g:vue_pre_processors.
Setting options for ALE in this file can sometimes overwrite settings that users set, say if they set global settings for ALE after ftplugin files are loaded. The Vue files should not be checked with ESLint by default, and ESLint checking should be enabled manually after installing the Vue ESLint plugin.
* Remove Typescript section. As long as the highlighting "just works", a section in the FAQ shouldn't be needed.
* Fix typo
* Add some more explanation
* Add links to referenced plugins
* removed preprocessing langs from registration
I'm not sure if this will work
* add back support for pre-processors
adds back support for preprocessors, but keeps vim fast when not in use
* completely removed support for preprocessors
testing to see if completely removing preprocessor language registrations will make syntime reports more performant
* added back conditional support
conditional support should work now
* just testing remove all preprocessor support
* I think this will work
* i found the actual bug
some regex statements are being checked several times
* quick fix for now
I only apply a quick fix until I can get to the root of the problem. For this, in order to turn off the preprocessors which seem to bog down vim, just put `let g:avoid_pre_processors = 1` in the .vimrc (or neovim equivalent).
* forgot endif statement
* testing behavior
* removed line to test behavior
* Update readme.md
* Update readme.md
* Update vue.vim
* Update vue.vim
* Update readme.md
Removes omit_attr argument from s:register_language(), because html,
javascript, and css regions were the only ones that used it, and they
are now handled by syntax/html.vim.
`runtime! syntax/html.vim` also has the advantage that we can hook into
the html syntax, meaning that we can add stuff like highlighting
javascript expressions inside vue directives, and add our own html
attributes.
Also removes the start of line limitation introduced in previous commit
