I'm trying to move my .viminfo file into my .vim/ folder for cleaner syncing across multiple machines. (I have my .vim stored on Dropbox, and then create symlinks to it from my home directory.)

So this morning, I found this answer on how to do just that. Great! Unfortunately, I use Windows at work and Mac at home, so ~/.vim is actually sometimes ~/vimfiles. As a result, a one-line solution

set viminfo+=n~/.vim/viminfo

has now become a 5-line solution

if has('unix')
  set viminfo+=n~/.vim/viminfo
elseif has('win32')
  set viminfo+=n~/vimfiles/viminfo

which just feels clumsy to me.

Is there some kind of default environment variable I can use to access the user-specific runtime path, à la $VIMRUNTIME or $MYVIMRC? Or is this something I just have to dance around?

4 Answers 4


This should work and is platform/plugin agnostic: fnamemodify(expand("$MYVIMRC"), ":p:h")

  • You people are geniuses.
    – Ryan Lue
    Jul 7, 2015 at 6:47

Assuming you didn't change it, the first item in &runtimepath is your runtime directory by default:

$HOME/.vim        on unix-like systems
$HOME\vimfiles    on windows

You can use that value to tell Vim where to put your viminfo file with this platform-agnostic one liner:

let &viminfo .= ',n' . split(&rtp, ',')[0] . '/viminfo'


:h :let-option
:h split()
:h runtimepath
  • 1
    Sadly this is not true. &runtimepath is manipulated by plugin managers, there is absolutely no reason for it to start with $HOME/.vim or with $HOME\vimfiles.
    – lcd047
    Jun 27, 2015 at 16:34
  • @lcd047, in its default state, &runtimepath always start with the default user-level runtime directory for the current platform. Now, it is obviously possible for the user to butcher his 'rtp' beyond recognition but AFAIK pathogen, vundle, plug, VAM and neobundle all leave ~/.vim (or similar) at the beginning.
    – romainl
    Jun 27, 2015 at 17:19
  • Only with the default configuration. For a long time I used something like this: pathogen#infect("$VIM/local/bundle/{}"), to allow me to (1) have bundles available to all users, (2) keep them separate from Vim's main runtime, and (3) allow me to upgrade them automatically. ~/.vim ends up in the middle of the bunch with that setup.
    – lcd047
    Jun 27, 2015 at 18:25
  • @lcd047, I changed the wording of the first sentence as per our conversation.
    – romainl
    Jun 27, 2015 at 20:40
  • Did it for me, and strikes me as the most elegant solution, given my setup. Thanks!!
    – Ryan Lue
    Jun 28, 2015 at 5:38

First mistake I see time and again in relation to Windows is always attempting to solve the problem by using $HOME, don't.

Using $HOME will eventually cause problems, especially if you use any Unix-like environments (Cygwin, git bash, etc.). Don't use it in scripts, don't set it as an environment variable. In fact, setting $HOME will cause Cygwin to stop working correctly, and git bash to do similar. The more you play with $HOME the worse the bugs get, and tracing them down gets harder. Just don't use it.

Windows builds the $HOME on the fly and behind the scenes with %HOMEDRIVE%%HOMEPATH%. Simply use this inside your _vimrc or vimrc (without dot):

set viminfo+=n%HOMEDRIVE%/%HOMEPATH%/vimfiles/viminfo

This should solve the problem. If you changed vimfiles to .vim adjust accordingly.


What I did was rename Windows' viminfo folder to .vim (or copy the former's contents into the latter and then delete the former) and then symlink them with mklink /d viminfo .vim. (Note that mklink takes its arguments in the opposite order from Unix' ln command.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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