While Vim’s core is very stable, problems can come about when extending the editor with plugins, particularly if there are a high number of them or if they’re buggy or not very well written. While Vim offers a number of ways to keep scripts’ behaviours isolated from one another, it may happen that you find Vim behaving in an unexpected way that you can’t quite pin down. There are a few very good approaches to figuring this out.
List your scripts
First of all, it helps to get a handle on what exactly you’ve got loaded during
your Vim sessions. You can do this with the
:scriptnames 1: /usr/share/vim/vimrc 2: /usr/share/vim/vim73/debian.vim 3: ~/.vimrc 4: ~/.dotfiles/vim/autoload/pathogen.vim ...
This list appears in the order in which the files were loaded, which might give you a starting point for figuring out where the problem lies.
Update your plugins
Check the documentation, release logs, known problems, and in particular the website of your chosen plugins to see if there are any recent updates to them. If they’re hosted on GitHub, pull down the most recent versions.
Start with no plugins
You can start Vim with no plugins, in a pristine state that doesn’t source any
vimrc files from your system or home directories, to figure out if the
behaviour you’re observing still occurs with no plugins at all installed. This
is done by calling Vim with the
-U options, which normally specify
the path to a custom location for
gvimrc files respectively, with
the special parameter of
$ vim -u NONE -U NONE
Vim will open and you’ll see the usual blue tildes for opening a line and Vim’s opening splash screen, having completely ignored your laborious setup.
This done, you can source plugins individually until you notice the problem starts happening, by a process of elimination:
:so plugin/fugitive.vim :so plugin/unimpaired.vim :so plugin/badplugin.vim
Profile startup time
If Vim was compiled with the
+startuptime feature, you can also pass the
--startuptime flag to it with a filename argument, and it will save a verbose
log of its startup procedure to that file for you to inspect:
$ vim +q --startuptime startuptime.txt $ vim startuptime.txt
There’s way more information in here than you’re ever likely to need, but in the case of a buggy setup or unacceptably slow startup time, it’s very useful for diagnosing the bottleneck in your setup.