This is a specific case of where such a hook would be useful.
The NERDTree plugin provides an API for advanced usage, such as custom key mappings and menus. When I load the plugin via vim-plug, I'm unable to access these functions for further customisations from within my configuration files.
I think a fix for the issue would be to provide some sort of post-loading hook, analogous to the post-install/upgrade ones that would allow extra code to be executed once the plugin is loaded. This would also allow plugin-specific configuration options to only be run if the plugin is actually loaded.
If adding such a hook is too complex or involves too much of a rewrite, could you suggest some tips as to how I might go about solving this particular use-case?
NVIM v0.2.1-1122-g54b79f19d
Build type: RelWithDebInfo
LuaJIT 2.0.5
Compilation: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -Wconversion -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -O2 -g -DMIN_LOG_LEVEL=3 -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -I/src/mak epkg/neovim-git/src/neovim-git/build/config -I/src/makepkg/neovim-git/src/neovim-git/src -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/src/makepkg/neov im-git/src/neovim-git/build/src/nvim/auto -I/src/makepkg/neovim-git/src/neovim-git/build/include
Features: +acl +iconv +jemalloc +tui
See ":help feature-compile"
system vimrc file: "$VIM/sysinit.vim"
fall-back for $VIM: "/usr/share/nvim"
Run :checkhealth for more info
if the plugin is actually loaded
Are you referring to the cases where deferred loading (on or for option) is used? In that case, vim-plug triggers User autocmd: https://github.com/junegunn/vim-plug#on-demand-loading-of-plugins
When on or for options are not used, there's nothing to do as those plugins will be loaded on startup.
It's related to this, but not quite the same. Basically I'm looking for a way to call additional functions or source additional files after the plugin has been loaded, regardless of whether they have been lazily loaded or not. If the plugin hasn't been loaded, then these commands/functions/whatever won't be executed. That way commands specific to the plugins will only be run if the plugin is loaded and/or active. The User autocmd doesn't seem to work without the on or for options are used, which is the case for the vast majority of my plugins.
Using the NERDTree example, it's possible to add keymappings to NERDTree using the function NERDTreeAddKeyMap which it provides in its API. However, adding these to my init.vim fails because the NERDTree plugin doesn't get registered until after neovim has started.
Yeah, plugins are loaded after init.vim. I still don't think a new option is necessary as you can use VimEnter event: autocmd VimEnter * NERDTreeAddKeyMap
@zoqaeski Even NerdTree's own documentation recommends using a nerdtree_plugin directory, and doesn't provide a way to stick it in your vimrc.
If you rarely change your usage of this api, but want to have it auto installed and run when nerdtree is conditionally loaded, I'd create a plugin at something like 'zoqaeski/nerdtree-mappings' and use something like Plug 'zoqaeski/nerdtree-mappings', { 'dir': 'plugged/nerdtree/nerdtree_plugin/my_mappings', 'on': [] }
Then you can have a default set of changes, you can even enable yourself to override them in your vimrc by setting a variable.
Of course that works in this specific instance. Nerdtree is a little weird in exposing it's prototypes only using function calls.
You can also use the .vim/after/plugin directory in vim, not sure about neovim.
I got it working using the after/plugin directory, which just means I have to put some settings in my init.vim and some in after/plugin/NERDTree.vim. I've already split my init.vim into separate files, so it's only one more step, but it does mean that settings specific to individual plugins get scattered amongst a few files.
Like I said, you can use VimEnter event.
I would like to add some discussion to this issue and potentially re-open it. Perhaps I am in the minority, but I like to keep a separate plugins.vim that contains just the code related to my plugins, and I like to group the plugin settings in an indented block beneath the plugin itself. For example:
Plug 'w0rp/ale'
let g:ale_set_highlights = 0
let g:ale_sign_error = '→'
let g:ale_sign_warning = '→'
let g:ale_sign_info = '→'
let g:ale_set_balloons = 1
let g:ale_linters = {'go': ['revive', 'gopls', 'gofumpt']}
let g:ale_open_list=1
nmap <silent> <leader>aj :ALENext<cr>
nmap <silent> <leader>ak :ALEPrevious<cr>
This allows me to see everything all in one place. This works most of the time for things like globals, but (like the docs mention), there are times like colorschemes and configuration functions where they won't work until after plug#end()
I would love to have a post argument allowing me to do things like
Plug 'flowchartsman/vim-monochrome', { 'post': ':colo monochrome'}
It seems like this functionality already exists with do, is there a reason you're opposed to something like this?
I'm dedicated to keeping the feature set of vim-plug as small as possible, so I would not add any non-crucial features for niche requirements especially when there are obvious workarounds. In this case, I don't see how having to learn to use post option is better than using the standard VimEnter autocmd Vim already provides. do is different because it's not easy to replicate the behavior outside of vim-plug.
Having said that, there are more ambitious plugin managers such as https://github.com/Shougo/dein.vim that give you more options, you might want to check them out if you really think you need the feature.
Thanks for your response! I completely understand.
Isn't this supported by do: function('functionname')?
Most helpful comment
Thanks for your response! I completely understand.