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.
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:
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.
" 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
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...