In a .vimrc, is `set nocompatible` completely useless?

Vim

Vim Problem Overview


Several users in this epic question put the following in the .vimrc:

" Necesary for lots of cool vim things
set nocompatible

But is it really necessary? From the docs:

'compatible' 'cp'
    boolean (default on, off when a |vimrc| or |gvimrc| file is found)

If set nocompatible is going in a .vimrc, that means that a .vimrc file exists, seemingly making it pointless.

Vim Solutions


Solution 1 - Vim

If it is the system-wide vimrc, this option won't be off. So, if you're changing the system-wide vimrc and you want it, you need to set it.

From the documentation section *compatible-default* (emphasis mine):

> When Vim starts, the 'compatible' > option is on. This will be used when > Vim starts its initializations. But > as soon as a user vimrc file is found, > or a vimrc file in the current > directory, or the "VIMINIT" > environment variable is set, it will > be set to 'nocompatible'.

Another difference is that explicitly setting 'nocompatible' overrules calling vim with the -C flag.

In any other scenario, yes, setting 'nocompatible' in your vimrc is a noop.

In the end I think it's just a matter of "better safe than sorry".

Solution 2 - Vim

Many people share their .vimrc files on GitHub and I sometimes will test out settings without replacing my .vimrc file. vim allows me to do this with the -u flag.

vim -u test_vimrc

From vim ":help nocompatible"

> (Note: This doesn't happen for the system-wide vimrc or gvimrc file, > nor for a file given with the |-u| argument).

This means that if you share your .vimrc with someone and they use -u flag to load your file, vim won't be configured the same as if the file were named .vimrc and located in your home directory.

Solution 3 - Vim

I was using vim in Cygwin on a Windows VM and every time I was in Insert Mode, pressing arrow keys would result in vim printing "A", "B", "C" or "D" on the screen instead of scrolling. I found a forum that said putting vim in nocompatible mode would fix it. Thankfully, it did.

I put "set nocompatible" in my ~/.vimrc file and the problem remains gone. So perhaps it's not 100% useless.

Solution 4 - Vim

Based on what Johnny pointed out above, I was simply astonished when I just found THIS out:

$ cat /usr/share/vim/vimrc.tiny
" Debian system-wide default configuration Vim
set runtimepath=~/.vim,/var/lib/vim/addons,/usr/share/vim/vimfiles,/usr/share/vim/vim74,/usr/share/vim/vimfiles/after,/var/lib/vim/addons/after,~/.vim/after

set compatible

ARGH!!!

No I did NOT expect that. Debian (or Debian Unstable aka Ubuntu) indeed DOES put up a nightmare to their users by overriding the default setting by set compatible. I hope that you will now know why when you're coming from FreeBSD, the first thing you would have to do is override the system-wide setting by putting a set nocompatible into your own ~/.vimrc. Because otherwise you'd just produce letters instead of being able to move the cursor the way you've been used to.

I think this is a horrid idea. In other words, this set compatible line ought to be removed from the system-wide vimrc.tiny in both Debian and Ubuntu, because it will annoy new users who are not (yet) as smart as knowing how to get the cursor keys working. It's things like these that force them to nano and others because of such entirely pointless blockers!

I would really want to talk with the dude who once propagated this change to the system-wide resource file in Debian. And maybe also to the people who acknowledged his change to the fullest.

Johnny is right: on your private PC, you may remove said line from the system-wide .vimrc (if there), and touch an empty .vimrc on your $HOME. Thanks so much for pointing that out, way less clutter again. Note that you MUST have that ~/.vimrc (even if empty!) as otherwise you will not be able to use the cursors without explicitly putting in set nocompatible.

Solution 5 - Vim

got the same problem on using -u vimrc option, even doing set nocompatible was misbehaving with some of my older setting, after some search i found one compactible version that works for me:

" Avoid side-effects when nocompatible has already been set.
if &compatible
  set nocompatible
endif

this avoid re-setting of nocompatible flag when it is already set.

vim :help nocompatible shows conditions when it set/resets the options value, scroll to that table of options and values, for quick reference, conditions that effect this behaviour are:

> 1. Option is set to the value given in {set value} when 'compatible' is > set. > 2. Option is set to the value given in {set value} when 'compatible' is set AND is set to its Vim default value when 'compatible' is > unset. > 3. Option is NOT changed when setting 'compatible' but IS set to its Vim default when 'compatible' is unset.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionClosureCowboyView Question on Stackoverflow
Solution 1 - VimR. Martinho FernandesView Answer on Stackoverflow
Solution 2 - VimChad SkeetersView Answer on Stackoverflow
Solution 3 - VimretsigamView Answer on Stackoverflow
Solution 4 - VimsyntaxerrorView Answer on Stackoverflow
Solution 5 - Vimdinesh sainiView Answer on Stackoverflow