Vim-plug: { 'on' : [ '<Plug>*', 'Com*' ] } for ALL "<Plug>" & "Command" bindings?

[phongvcao]

Hi,

I have been using vim-plug for a while and very impressed. I just have a small question: There are many plugins that have many s & commands, and according to the examples in the doc & Issues, it seems that we would have to list all of these s & commands out if I want vim-plug to lazy-load the plugin on use. Consider YankRing.vim for example, this is what I have in my .vimrc

Plug 'vim-scripts/YankRing.vim', { 
            \ 'on' : [ 'YRToggle', 'YRClear', 'YRShow', 'YRGetElem', 
            \          'YRGetMultiple', 'YRPush', 'YRPop', 'YRYankCount',
            \          'YRYankRange', 'YRDeleteRange', 'YRPaste', 'YRReplace',
            \          'YRMapsCreate', 'YRMapsDelete', 'YRSearch', 
            \          'YRCheckClipboard', 'YRRunAfterMaps' ] }

Is there any way in vim-plug that allows us to shorten the above 'on' list, like the following:

Plug 'vim-scripts/YankRing.vim', { 'on' : [ 'YR*', '<Plug>' ] }

which delays loading of plugin until a command whose pattern matches "YR*" or when any of the plugin is invoked?

[junegunn]

vim-plug does not know in advance which commands and mappings are going to be available until it actually loads the plugin. Since there is no strict naming rule for <Plug> mappings of a plugin, it's not possible for vim-plug to intercept the unresolved key binding. For commands, we can consider using CmdUndefined autocmd to support wildcard patterns, however the downsides are 1. you don't get command-line auto-completion until the plugin is loaded, 2. and we can't avoid the initial E492: Not an editor command error.

Note that on and for options are mostly workarounds for badly-structured plugins, and usually there are better ways to solve the loading time issue, namely, fixing the plugin. So I don't think it's the right direction that we make those options more sophisticated. I suggest that you contact the author of the plugin to address the issue, or fork the repo and fix it to use native autoload feature of Vim.

[junegunn]

Oh, and a little known fact is that you don't have to write the full <Plug> mapping on on option. This works:

Plug 'junegunn/vim-easy-align', { 'on': '<Plug>(Easy' }

nmap ga <Plug>(EasyAlign)

• ga
  
  
  
  • <Plug>(Easy
  
  
  • Triggers vim-plug to load the plugin
  
  
  • After loading the plugin, vim-plug will re-emit <Plug>(Easy which is then combined with the remainder Align) which gives the full <Plug>(EasyAlign)
  
  

[phongvcao]

@junegunn oh that's nice. So <Plug> doesn't work but <Plug>(Easy works? How about just <Plug>(? BTW, I think we need to update the doc or smt to include this interesting feature.

[junegunn]

How about just (?

Then it will load the plugin even when unrelated mappings are issued. e.g. <Plug>(Whatever) will trigger loading of vim-easy-align, and I don't think it's what you want.

I think we need to update the doc

Thanks. I'll consider that. But these days I usually advise _against_ using on-demand loading, and I don't feel like providing more information on it as I'm afraid doing so might encourage users to "abuse" it more even when they don't really need it or when there are better alternatives.