Allow granular control over loading pre-processor syntax files #133
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
The change in commit ba9a3db is documented in the README, to augment the information regarding pre-processor languages and g:vue_disable_pre_processors.
|
Tests are failing. I'll fix shortly. |
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).
janlazo
added a commit
to janlazo/dotvim8
that referenced
this pull request
Apr 7, 2019
Anticipating posva/vim-vue#133 which should resolve perf issues with this plugin coc-vetur provides the autocomplete for Vue SFC.
janlazo
added a commit
to janlazo/dotvim8
that referenced
this pull request
Apr 8, 2019
Anticipating posva/vim-vue#133 which should resolve perf issues with this plugin coc-vetur provides the autocomplete for Vue SFC.
janlazo
added a commit
to janlazo/dotvim8
that referenced
this pull request
Apr 8, 2019
Anticipating posva/vim-vue#133 which should resolve perf issues with this plugin coc-vetur provides the autocomplete for Vue SFC. Stop coc.nvim from autoupdating coc-vetur on startup because I run multiple vim/nvim everyday. I don't use spacemacs because of autoupdate on startup.
janlazo
added a commit
to janlazo/dotvim8
that referenced
this pull request
Apr 9, 2019
Anticipating posva/vim-vue#133 which should resolve perf issues with this plugin coc-vetur provides the autocomplete for Vue SFC. Stop coc.nvim from autoupdating coc-vetur on startup because I run multiple vim/nvim everyday. I don't use spacemacs because of autoupdate on startup.
|
Is this PR ready? |
|
Yeah, this should be ready to merge. I have actually been holding off on this because I wanted to see what I could do with #128, but so far I haven't really had the time to work on that. I'll have a further look at this PR tonight and merge it in. I'm also thinking of merging in the work on the performance-enhancement branch, and enable that when |
adriaanzon
pushed a commit
that referenced
this pull request
Jul 24, 2019
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.
You can now set |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In addition to
g:vue_disable_pre_processors, which is an "all or nothing" approach to loading pre-processor syntax files, ag:vue_pre_processorsoption is exposed as well. This is a List of names of pre-processor syntaxes to load, to allow the user to enjoy syntax highlighting for one or two pre-processor languages without incurring the performance penalty of loading all of them at the same time.Notable reasons not to merge this:
g:vue_pre_processorsaltogether.In the meantime, however, as none of the above solutions are fleshed out as of yet (particularly in the context of syntax), this change could be a way to mitigate the issue.