created 2008 · complexity basic · author Metacosm · version 7.0
- You put that neat new option in your .vimrc, but when you restart Vim, there's no effect! What's up?
- Probably, the .vimrc you are editing is not the one that Vim is loading on startup. Execute the command
:scriptnamesto find out what scripts have been loaded and from where. Make sure the .vimrc appearing there is the one you are changing. For more information on how Vim finds a .vimrc, read :help .vimrc.
- Certain the correct .vimrc is being read, and it still doesn't work?
- For many Vim customizations (eg tabstop setting, BufEnter autocmd) you can do
:verbose set tabstop?or
:verbose autocmd BufEnter) to find the current values and where they were set. Modelines and scripts which run after .vimrc can trip you up in this way.
- You're seeing unexpected maps or abbreviations. Why?
- You can use most define commands (
:autocmd, ...) on their own to list all defined maps, abbreviations, ... Or you can use them with the lhs of the definition to list all matching definitions. Some (like map and abbreviate) will allow partial matches. Add verbose in front and you can see where each item is defined.
If you're encountering something strange, you can try turning off customizations to determine where the strangeness is coming from.
Use default Vim settings
gvim -u NONE -U NONE
Issue still occurs: likely happens in a default Vim install. May be a bug.
Issue is fixed: it's an installed config setting or plugin. Try disabling plugins.
Disable all plugins
Issue still occurs: config setting (vimrc or gvimrc). Try disabling parts of your rc files to see if it still happens. This can be done by commenting out commands, or using a "finish" command in strategic places. Using "finish" allows you to do an easy binary search, letting you narrow down a 2000 line .vimrc in only 10 or so steps. Start by placing a "finish" statement about halfway through your .vimrc. If the problem goes away, it is caused by something in the second half. Otherwise, in the first half. Remove the old "finish" statement, and place a new one halfway through the "bad" half until you find the problematic setting, autocmd, mapping, etc.
A method that can help with this search is to set marks (for example, by pressing "ma" and "mb") at the first and last line of the "bad" region. Then do
:exec (line("'a")+line("'b"))/2 to jump to the halfway point where you can insert your "finish" statement. Update the a or b mark based on the result and continue the process with the same command.
Issue is fixed: it's an installed plugin. Narrow down which one, by disabling individual plugins until it's fixed. This is easiest using a binary search, especially if you are using a plugin manager. Simply remove or disable half your plugins. If the problem is fixed, it's in the half you removed. Otherwise, it's in the half you kept. Continue disabling or removing half of the "bad" group until you find the plugin causing the issue. This lets you search over a hundred plugins in only 7 or so steps.
Alternatively, start Vim with
--noplugin -D to step through all the startup scripts (this can be tedious). If you are running a GUI version, debugging only starts after the GUI is up. Put a
gui command in your .vimrc to fix this; it will start the debugging right after that command, and let you step through .vimrc.
Some Vim distributions may include custom settings for Vim (such as debian.vim or Cream's settings) that may make your results different from others.
You might also get slightly different results if you remove your vimfiles. I'm not sure. You can easily stash up all of your vimfiles:
mkdir ~/bak mv .*vim* ~/bak