Open dracorp opened 6 years ago
What are you trying to achieve? Using for
option for filetype-specific plugins is mostly unnecessary and discouraged. They are inherently designed to be loaded on demand, and an additional lazy loading mechanism from vim-plug is completely unnecessary for them.
See https://github.com/junegunn/vim-plug/wiki/faq#when-should-i-use-on-or-for-option
Sometimes I don't need additional menu in Gvim. Sometimes there is a conflict in mapping. So using for
option is useful.
The above example (my code) is stupid or at least incorrect, but the question is still valid.
Since Plug is the central piece for downloading plugins and placing them to be autoloaded, I think it is the perfect place to organize on demand rules.
For me it's not a matter of optimization. Can't always rely on plugin authors to implement specifically for certain file types and I wouldn't want them to. The scope for use cases and user preference is too big.
Related: I've tried and failed to split Plug
calls into relevant ftplugins, problem being that plug#end()
call would have to come after all the ftplugins are loaded.
Similarly, it would also be nice to group the non-filetype-specific Plug
calls into files under plugin/
without explicitely sourcing them, relying on Vim runtime load order instead, but this has similar problems.
Loading plugs incrementally as per https://github.com/junegunn/vim-plug/issues/615 would likely solve this.
What is the best way to group plugins for same filetype? I wanted to use this:
But it does not work. I want to avoid use multiply keyword for:
Of course xs and pm files have same filetype: perl. This is only example.
Best regards Piotr