7

I recall (perhaps in the early 2000's) having set nocompatible as the first line of my vimrc and most Vim guides and tutorials recommending that practice.

Some examples I could easily find online:

set nocompatible " Use VIM settings rather than Vi settings; this *must* be
                 " first in .vimrc 

Before doing anything else, make sure you have the following line in your .vimrc file:

" This must be first, because it changes other options as side effect
set nocompatible

However, that advice doesn't seem to make much sense these days, since nocompatible is automatically used whenever a user .vimrc file is found, so there doesn't seem to be any compelling reason to use set nocompatible in your user .vimrc file.

When was this practice necessary? Was the default to nocompatible when user vimrc is found changed in a specific version of Vim, such that setting nocompatible was necessary in previous versions of Vim? Is there any advantages or side-effects of an explicit set nocompatible that I'm perhaps missing?

While researching this subject, I found:

  • References to this being necessary if you wanted to use that as a system vimrc. But that doesn't seem to be the case in most places, since the links above clearly talk about the user .vimrc file.
  • Mentions of a specific Linux distribution (Debian) explicitly including a set compatible in the system vimrc file, which would require an explicit set nocompatible to counter the distro defaults. (Not sure if that makes sense.)

Is there some truth or merits to these points above? Or was set nocompatible in large part cargo culting?

  • 1
    The help file options.txt was added to git at 2004-06-13 (the 7th commit). It already describes that cp is off when a vimrc was found. That was v7.0001. – Ralf May 7 at 6:06
  • 2
    BTW: I was convinced to remove the set nocompatible from my vimrc by this answer. – Ralf May 7 at 6:13
8

Is there any advantages or side-effects of an explicit set nocompatible that I'm perhaps missing?

Actually, there are many side-effects. Every time compatible is set or reset Vim rescans all options (except "terminal") and switches defaults when necessary. After that it rebuilds quite a few internal tables for iskeyword, spelling, vartabs etc. (see didset_options() and did_setoptions2() in src/option.c).

So bare set nocompatible in user vimrc is rather undesirable (even though the difference could be negligible nowadays), and, if not dropped completely, it should probably be guarded with if &compatible / endif as in $VIMRUNTIME/defaults.vim.

When was this practice necessary? Was the default to nocompatible when user vimrc is found changed in a specific version of Vim, such that setting nocompatible was necessary in previous versions of Vim?

I found the code to switch to nocompatible in v5.0 but not in v4.6. So I assume it's here starting from Vim5 (early 1998).

Also note that &compatible could also be set explicitly in the command-line (like vim -C), but I doubt it makes any sense to fight against user's will inside his own vimrc. Maybe just do finish then.

| improve this answer | |
  • Thanks for digging this up all the way to Vim 4.6! After 22 years I think it's pretty safe for us to move on! 😁 – filbranden May 8 at 3:44
6

One reason you might want to include a guarded set nocompatible in your .vimrc is that compatible will not be automatically unset if you specify the vimrc with the -u flag:

Using the "-u" argument with another argument than DEFAULTS has the side effect that the 'compatible' option will be on by default.

It's for this reason that I have this version* in my .vimrc:

if &compatible
  " Vim defaults to `compatible` when selecting a vimrc with the command-line
  " `-u` argument. Override this.
  set nocompatible
endif

However, I have literally never specified my regular .vimrc via a -u flag, and bearing in mind Matt's note about the date in which this switch was introduced, I think it's fair to say this is almost entirely a case of cargo culting**: I suspect it would take you a while to find a blog post stating this is necessary that predates Vim 5.

* As Matt also points out, an unguarded version is actively bad, because it has many side effects which you probably don't want in the situation where you re-source your vimrc in an already running copy of vim.
** And, being a pedant, I frequently do!

| improve this answer | |
  • The argument of -u is indeed a good one. I, at least, try to always pair -u with -N though, which ensures nocompatible will be set together with the custom vimrc. – filbranden May 8 at 3:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.