Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deferred loading on autocmd (#event[#pattern]) #548

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

junegunn
Copy link
Owner

Does not mean that I'm positive on this. I'm just posting the patch as it was trivial to implement the idea.

Plug 'SirVer/ultisnips',  { 'on': '#InsertEnter' }
Plug 'junegunn/goyo.vim', { 'on': ['Goyo', '#BufEnter#README,BUILD,CHANGELOG'] }

(See :help exists() for #event#pattern syntax)

e.g.
    Plug 'SirVer/ultisnips',  { 'on': '#InsertEnter' }
    Plug 'junegunn/goyo.vim', { 'on': ['Goyo', '#BufEnter#README'] }
@vheon
Copy link
Contributor

vheon commented Oct 31, 2016

Since which version is the #event#pattern syntax supported? Just asking because you don't seems to have a minimum version of vim for vim-plug and I wouldn't want you to break some users :)

@junegunn
Copy link
Owner Author

It has been quite some time.

vim/vim@f4cd3e8
vim/vim@a9b1e74

The code in this PR only uses exists('##EventName'). #event#pattern syntax was chosen not to introduce a new, arbitrary syntax, but it's not directly used. The code splits the string.

@vheon
Copy link
Contributor

vheon commented Oct 31, 2016

Thanks for digging that up! 😉 As usual I hope that there is a real use for this other than YCM (I know you get a lots of requests from it).

@@ -526,6 +531,14 @@ function! s:lod_map(map, names, with_prefix, prefix)
call feedkeys(substitute(a:map, '^<Plug>', "\<Plug>", '') . extra)
endfunction

function! s:lod_autocmd(name)
call s:lod([a:name], ['ftdetect', 'after/ftdetect', 'plugin', 'after/plugin'])
call s:dobufread([a:name])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be problematic.
I found this PR when looking for a better way to handle custom InsertEnter handling.

I am using the following:

    Plug 'Shougo/deoplete.nvim', {'on': []}
    …
    augroup vimplug_load_on_insertmode
      autocmd!
      autocmd InsertEnter * call plug#load(
            \ 'cursorcross.vim',
            \ 'delimitMate',
            \ 'deoplete.nvim',
            \ ) | call deoplete#enable()
            \ | autocmd! vimplug_load_on_insertmode
    augroup END

And here the call to deoplete#enable() adds a BufEnter autocmd that gets triggered then.
It is a bit weird, since plug#load() should be finished already, before deoplete#enable() then sets up the BufEnter autocmd?! (I have also put it into a separate function to make sure | does not cause it).

Maybe the BufEnter gets queued after the InsertEnter?!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The dobufread happens for ftplugin …/.vim/plugged/jedi-vim//**, which is triggered through another handler:

    function s:my_insertenter_python()
      if &ft ==# 'python'
        call plug#load(
            \ 'deoplete-jedi',
            \ 'jedi-vim',
            \ )
        autocmd! vimplug_load_on_insertmode_python
      endif
    endfunction
    augroup vimplug_load_on_insertmode_python
      autocmd!
      autocmd InsertEnter * call s:my_insertenter_python()
    augroup END

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, this explains the issue: there are two calls to plug#load in that setup.

@blueyed
Copy link
Contributor

blueyed commented Dec 1, 2016

I think this would be good to have.

But for my use case I would need to be able to a) call a custom function afterwards (deoplete#enable()), and b) would like to limit it to a filetypes also (i.e. #InsertEnter, but only for python filetypes).

@blueyed
Copy link
Contributor

blueyed commented Dec 6, 2016

call a custom function afterwards

That is also useful for lazy-loading Unite, so that you can customize it using call unite#custom#source(…) etc.

@junegunn
Copy link
Owner Author

junegunn commented Dec 8, 2016

@blueyed

call a custom function afterwards

vim-plug currently supports that via User autocmd

" Code to execute when the plugin is lazily loaded on demand
Plug 'junegunn/goyo.vim', { 'for': 'markdown' }
autocmd! User goyo.vim echom 'Goyo is now loaded!'

Have you tried it?

b) would like to limit it to a filetypes also (i.e. #InsertEnter, but only for python filetypes).

Hmm, I certainly wouldn't want to go that far. In my opinion, custom autocmd is the answer to such complex use cases.

@blueyed
Copy link
Contributor

blueyed commented Dec 10, 2016

@junegunn

vim-plug currently supports that via User autocmd

Oh, I missed that, sorry. That is nice.
But I wonder if the autocommand name should not have something like a plug_loaded_ prefix?!
Otherwise it could conflict/overlap with a plugin's own custom User autocommand?!

Thanks!

@jbro
Copy link

jbro commented Mar 9, 2017

I think this is a neat little feature, I'm currently using:

Plug 'vim-syntastic/syntastic', { 'on': [] }
"Delay syntatic load until we aren't doing anything
augroup LazySyntatic
  autocmd!
  autocmd CursorHold * :call plug#load('syntastic')
  autocmd CursorHold * :autocmd! LazySyntatic
augroup END

to delay the loading of syntastic. With deferred autoload that could be hidden away with:

Plug 'vim-syntastic/syntastic', { 'on': '#CursorHold' }

@SwenChan
Copy link

So, can plug support event now? I'm using SpaceVim which using 'dein' as their default plugin manager and I want to switch to plug , which is my favorite vim plugin manager. But I need this feature because so many plugin in SpaceVim need this.
So, anyone can help with this feature? @junegunn @blueyed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants