18

In order to ensure that behaviour is not affected by my personal config, I want to start Vim in a way that ignores all my user-installed config files, as if Vim had just been freshly installed for the first time and the user had run it immediately.

This is addressed in the FAQ which suggests that the answer is to start Vim with the following command:

vim -u NONE -U NONE -N -i NONE

This gets most of the way there, but the runtimepath option still contains ~/.vim and, notably, ~/.vim/after, (so e.g. if I subsequently turn on file type detection and change filetype, code in ~/.vim/after/syntax/the_relevant_filetype.vim will be executed).

I can workaround this specific problem by invoking the following commands on startup*:

:set runtimepath-=~/.vim
:set runtimepath-=~/.vim/after

...but I'm not sure if:

  1. This is a robust solution: Are those the only paths that can cause user-configuration to take effect? Is there anything else I haven't thought of?
  2. There is a better way of achieving the desired result.

* By using --cmd or -u vimrc shell arguments, or simply by typing them manually.

EDIT: Here's one specific example of the sort of problem I'm trying to fix. (Although I'd like the solution to fix any other possible issues I might not yet have encounted.):

  1. Create a file ~/.vim/after/ftplugin/c.vim, containing the content:

    noremap i :echom "This is not default behaviour"<CR>
    

    Now we have some user-installed configuration that we want to ignore. Let's test the solution suggested by the FAQ.

  2. Run Vim with the command:

    vim -u NONE -U NONE -N -i NONE
    
  3. Enter the commands:

    :filetype plugin on
    :set ft=c
    i
    

Desired behaviour: Vim should enter Insert mode. This is what it would do if no user configuration existed.

Observed behaviour: Vim prints out "This is not default behaviour"

  • On a Unix-like system, what if you do: HOME=/dev/null vim -u NONE? – muru Jan 13 '16 at 16:17
  • @muru Nice idea, and probably worth adding as an answer, but it's not perfect. You obviously lose the ability to e.g. :cd ~, but also the default location of the viminfo file is in $HOME, which can cause E138. I guess creating a new, empty directory and using that for $HOME might be the best solution. – Rich Jan 13 '16 at 16:52
  • @muru Just occurred to me that if you're setting $HOME, then presumably you don't also need to specify -u NONE? – Rich Jan 13 '16 at 16:55
  • 1
    in which case /tmp might be better, it was my first thought, but then I chose /dev/null as a black hole. ... Or something like HOME=$(mktemp -d) vim .... – muru Jan 13 '16 at 16:56
  • Won't it read system vimrc if you don't use -u NONE? Depends on what behaviour you need, I suppose. – muru Jan 13 '16 at 16:57
12

As of Vim 8.0.1554 (unfortunately not Neovim yet), you can use vim --clean. This method is recommended by :help bugs.

:help --clean docs:

Similar to "-u DEFAULTS -U NONE -i NONE":
- initializations from files and environment variables is skipped
- 'runtimepath'and 'packpath' are set to exclude home directory entries (does not happen with -u DEFAULTS).
- the |defaults.vim| script is loaded, which implies 'nocompatible': use Vim defaults
- no |gvimrc| script is loaded
- no viminfo file is read or written
- the home directory is excluded from 'runtimepath'

  • 1
    Nice! This is a lot simpler than messing around with the $HOME variable. Goodjob Vim developers. And thanks to you for the answer! – Rich Aug 3 '18 at 8:44
  • --clean also works with neovim on master now (github.com/neovim/neovim/commit/…, to be included in 0.4.0), but does not exclude the home directory. – Christian Clason May 3 at 15:16
  • (yet, that patch is waiting to be ported) – Christian Clason May 3 at 15:26
11

One way to eliminate user-specific files would be to use a different value of $HOME. To allow nothing to be read, or written to (such as viminfo), you could use /dev/null:

HOME=/dev/null vim -u NONE

This will cause errors about viminfo, so, instead you could create a temporary folder, or use an existing one (like /tmp):

HOME=$(mktemp -d) vim -u NONE

With such a $HOME, -u NONE may not be needed, depending on what your administrator has added to the system-wide vimrc. For example, on all lab systems I administer, I added a /etc/vim/vimrc.local (sourced by the packaged Vim's default /etc/vim/vimrc) that has nocompatible, syntax, etc., set, and filetype on as well.

1

I can't answer much of that but one point that I don't see mentioned, and re answering an interpretation of what is in the title

How can I get Vim to ignore all user configuration, as if it were freshly installed?

some have suggested vim -u NONE or vim -u NORC

that's in some ways a bit more barebones than just no vimrc file. When I type 'i', it doesn't say 'insert'. You may want it to still say 'insert'. If you started vim with your vimrc file blank then it would show insert

that's because vim loads a default config first.

You can point vim to that default file to get the effect of your vimrc file being blank. Check that you have /etc/vim/vimrc, and you can do vim -u /etc/vim/vimrc or on osx, the default file is /usr/share/vim/vicmrc

  • I think that's exactly what vim --clean will do for you. – quemeraisc May 3 at 12:18
0

From Vim-FAQ 2.5:

2.5. I have a "xyz" (some) problem with Vim. How do I determine it is a problem with my setup or with Vim? / Have I found a bug in Vim?

First, you need to find out, whether the error is in the actual runtime files or any plugin that is distributed with Vim or whether it is a simple side effect of any configuration option from your .vimrc or .gvimrc. So first, start vim like this:

vim -u NONE -U NONE -N -i NONE

this starts Vim in nocompatible mode (-N), without reading your viminfo file (-i NONE), without reading any configuration file (-u NONE for not reading .vimrc file and -U NONE for not reading a .gvimrc file) or even plugin.

  • 1
    Despite being in the FAQ, this doesn't actually work, for the reasons mentioned in the question. – Rich Jan 13 '16 at 17:57
  • @Rich From your comment on the question: ensure that none of the behaviour I'm seeing is caused by user config -- then it looks like you are trying to do exactly what is being explained in this FAQ. I've re-read your question and still don't understand what are the reasons you mentioned. – mMontu Jan 13 '16 at 18:00
  • I am indeed trying to do exactly what is being explained in the FAQ. But the solution it gives doesn't work, because of the runtimepath setting. – Rich Jan 13 '16 at 18:06
  • What exactly is wrong about the runtimepath? It seems like the default for this option, as explained in :help rtp. How is this value affecting your test? – mMontu Jan 13 '16 at 18:41
  • @Rich I mean, do you see any differences when comparing to a fresh install after you turn on filetype detection? – mMontu Jan 13 '16 at 19:01

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.