-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
base: master
Are you sure you want to change the base?
Conversation
e.g. Plug 'SirVer/ultisnips', { 'on': '#InsertEnter' } Plug 'junegunn/goyo.vim', { 'on': ['Goyo', '#BufEnter#README'] }
Since which version is the |
It has been quite some time. vim/vim@f4cd3e8 The code in this PR only uses |
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]) |
There was a problem hiding this comment.
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
?!
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
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 ( |
That is also useful for lazy-loading Unite, so that you can customize it using |
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?
Hmm, I certainly wouldn't want to go that far. In my opinion, custom autocmd is the answer to such complex use cases. |
Oh, I missed that, sorry. That is nice. Thanks! |
I think this is a neat little feature, I'm currently using:
to delay the loading of syntastic. With deferred autoload that could be hidden away with:
|
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. |
Does not mean that I'm positive on this. I'm just posting the patch as it was trivial to implement the idea.
(See
:help exists()
for#event#pattern
syntax)