These lines define special remappings, so I think it makes sense that they are called on startup time and not via an autocmd.
Note that there's a specific autocmd event which is essentially for "startup time", but after plugins were loaded and executed, which is the VimEnter event.
From :help VimEnter
:
VimEnter
: After doing all the startup stuff, including loading .vimrc files, executing the -c cmd
arguments, creating all windows and loading the buffers in them.
Defining a function and having that executed in VimEnter would be an appropriate solution.
My current workaround is just to explicitly source the plugin file: source $HOME/.vim/bundle/vimtk/plugin/vimtk.vim
before calling these commands
Slightly better would be:
runtime! plugin/vimtk.vim
Since that doesn't depend on the specific directory used by your plugin manager to store the vimtk plugin, it only depends on the specific name of the *.vim
file inside it. It matches what Vim does when it loads plugins after the vimrc file is processed.
But it's still not very satisfying.
One issue with this approach is that the plugin file will be executed again when Vim loads all plugins. So it works better if the plugin file detects whether it was already sourced (for example, by setting a global variable) and skips execution if it was previously loaded.
and I would like to call the lines:
" Make default vimtk remaps.
:call VimTK_default_remap()
" Swap colon and semicolon
:call vimtk#swap_keys(':', ';')
Note that it should be possible to call the latter type of functions vimtk#...
from your vimrc. These are autoloaded functions and as long as rhe plugins have been registered into 'runtimepath'
(which happens early on, when you configure your plugin manager), Vim should be able to load them just fine.
Only issue is when those functions depend on some initialization that happens or is triggered from one of the plugin/*.vim
files, as that's the step that will happen after vimrc is processed.
In this particular case, it's clear that global function VimTK_default_remap()
is not autoloaded, so it must be registered by the plugin/vimtk.vim
script and will only be accessible after its execution. (That's also often the case when plugins register new Vim user commands, that you might want to use during initialization, but using them from the vimrc file is problematic.)
One more option to consider is to write your late initialization commands into a separate file under ~/.vim/after/plugin/*.vim
. This file will be executed at the same stage when the Vim plugins are loaded, but being on an after/
directory ensures it will be at the end of 'runtimepath'
, which means it will be executed after all plugins have been loaded and initialized.
For the specific case of your vimtk initialization, it turns out you don't really need to configure it by calling these functions.
Instead, as @Matt pointed out, you can do let g:vimtk_default_mappings = 1
and postpone that call until the plugin is sourced normally. And the swapkeys
and quickopen
can use a g:vimtk_extra_mappings
dict specifying your custom mappings.
Since the initialization ordering of Vim plugins is very well known to plugin authors, they will usually (or often) export enough knobs through global variables that can be easily set from the vimrc file before plugin initialization happens.
So look for those first, as they'll often be able to solve what you're trying to configure without having to resort to using a VimEnter autocmd, or a vim script under ~/.vim/after
, or a hack sourcing the plugin script from inside the vimrc file...
call VimTK_default_remap()
in your vimrc? As it turns out, you have a "hook" in your plugin, so you can dolet g:vimtk_default_mappings = 1
and postpone that call until the plugin is sourced normally. Also theseswapkeys
andquickopen
look like an attempt to do easy things in a hard way. Just a couple of usual maps (or maybe special parameters to process indefault_remap()
, sort oflet g:vimtk_extra_mappings = {':': ';'}
, if you really like it this way), and you're done.xxx#swapkeys()
and such seem pretty much useless everywhere except vimrc. So why then to have them in a plugin?noremap
is equivalent ofnnoremap
andvnoremap
andonoremap
;vnoremap
already stands forsnoremap
andxnoremap
. Whyinoremap
andcnoremap
at all? Etc. etc. It looks like a total mess for me. At the very most, it's four commands (twonoremap
and twonoremap!
) instead of twenty.