Grouping plugins for same filetypes

[dracorp]

What is the best way to group plugins for same filetype? I wanted to use this:

if index(['pm','perl','xs'], &filetype) > -1
  Plug 'vim-perl/vim-perl'
  Plug 'vim-scripts/perl-support.vim'
endif

But it does not work. I want to avoid use multiply keyword for:

  Plug 'vim-perl/vim-perl', {'for',['perl','xs','pm']}
  Plug 'vim-scripts/perl-support.vim', {'for',['perl','xs','pm']}

Of course xs and pm files have same filetype: perl. This is only example.

Best regards Piotr

[junegunn]

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

[dracorp]

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.

[SephVelut]

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.

[mwgkgk]

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.