1

According to :h compatible:

(...) when a |vimrc| or |gvimrc| file exists, Vim will use the Vim defaults, otherwise it will use the Vi defaults.

But when I try:

$ mv ~/.vimrc vimrc
$ vim -c 'set cp?'

Vim tells me:

nocompatible

If I force it by:

$ vim -u NONE -c 'set cp?'

Vim correctly answers me with

compatible

I'm confident I have no ~/.gvimrc, what could cause this vim behaviour?

5

I just tried it, and I think I know what causes this. When I delete my vimrc, start vim, and run :scriptnames it says a default vimrc is loaded from

1: C:\Program Files (x86)\vim\_vimrc

(although this probably depends on what operating system you're on). If you delete this file, vim will start in compatible mode. You can find out where this file is by running :scriptnames, and it should be the first result.

1
  • Thanks, your answer pointed me into the right direction. And :scriptnames helped too. But on a *nix system there appears to be some extra behaviour changes. I'll add a self answer in a moment.
    – grochmal
    Jun 19 '16 at 20:02
3

Thanks to DJ McMayhem pointing me in the right direction I found that Linux distros meddle with the nocompatible behaviour of vim. Since I cannot expect that everyone here know unix jargon, where I use $ I'm working as a normal user and where I use # i do commands as the superuser (root).

1. Vim ignores /etc/vimrc for the purpose of setting nocompatible

With :scriptnames I found vim loads the /etc/vimrc script. I then removed both vimrc scripts and tested:

$ mv ~/.vimrc ~/vimrc.bak
# mv /etc/vimrc /etc/vimrc.bak
$ vim -c 'set cp?'

And got

compatible

That is what we expected, but I tested further. I have created a /etc/vimrc containing set ff=unix (completely unrelated from nocp) and checked:

# echo set ff=unix > /etc/vimrc
$ vim -c 'set cp?'

And surprisingly I got:

compatible

Moreover :scriptnames clearly indicated:

1: /etc/vimrc

Adding a ~/.vimrc on the other hand triggers nocompatible correctly:

$ echo set ff=unix > ~/.vimrc
$ vim -c 'set cp?'
nocompatible

Vim did not understood the existence of /etc/vimrc as a vimrc file for the purpose of setting nocompatible, but it did understood the existence of ~/.vimrc. In unix philosophy that is correct, since it is a multi-user system by default the existence of a global configuration file shall never make a difference for a user.

2. /etc/vimrc is created by the package manager on *nix systems

The suspicion about the strange behaviour I got in the question falls on the contents of the original /etc/vimrc file (currently backed up as /etc/vimrc.bak). Looking through it I found this line:

runtime! archlinux.vim

I'm running vim on archlinux therefore it makes some sense. I found the file at /usr/share/vim/vimfiles/archlinux.vim and it does contain:

set nocompatible

as the first non-comment line! That explains it all.

Conclusion

I then checked on a centos and a debian machines. It turns out that in one way or another (by using runtime or directly in /etc/vimrc) they all perform:

set nocompatible

explicitly, inside the configuration that is maintained by the package manager (yum, apt, pacman). That is bad practice!

Moral of the story: Your Linux distro is likely meddling in the global vim configuration files. Be sure to check these files before arguing about strange behaviour of vim.

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.