Open marcoslopes opened 5 years ago
This is still the issue.
Adding wildcards to the 'for'
option makes on-demand loading work as expected for sub-filetypes:
Plug 'mattn/emmet-vim', { 'for': '*html*' }
It should also be noted that Emmet has its own support for lazy-loading:
let g:user_emmet_install_global = 0
autocmd FileType html,css EmmetInstall
For on-demand loading, e.g., of
Plug 'mattn/emmet-vim', { 'for': 'html' }
vim-plug creates the following autocommand:
autocmd PlugLOD FileType html call <SID>lod_ft('html', ['emmet-vim'])
As this stands, the html
filetype must be matched verbatim in order for the autocommand to execute. The pattern argument (:h autocmd-pattern
) can use wildcards (*
) for looser matching, which is why the above workaround works. However, this may have implications behind the scenes since the wildcards are also passed to s:lod_ft
:
autocmd PlugLOD FileType *html* call <SID>lod_ft('*html*', ['emmet-vim'])
From what I can tell, the filetype argument to s:lod_ft
ultimately gets treated as a glob pattern anyway.
Some ideas to consider are:
Does the above workaround and subsequent passing of wildcards to s:lod_ft
constitute intended behavior?
If yes, then no code modifications are necessary, but this use case should be documented in the README.
If no, then...
Should wildcards be added to the autocommand pattern whenever 'for'
is used? That is, should the template in plug.vim:413 look like autocmd FileType *%s* call <SID>lod_ft(%s, %s)
?
If yes, then users would lose the ability to restrict on-demand loading to verbatim filetype patterns. This probably isn't a significant issue, but just something to be aware of. Perhaps a 'strict'
option could prevent the addition of wildcards.
if no, then...
Should wildcards, if used like in the workaround above, be stripped when passed to s:lod_ft
?
basically the following works:
but just
jinja
or justhtml
does not:I am happy to leave
jinja.html
in my config, but based on this help it seems that it should take into consideration either.