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.
Ian Emnace