12

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
endif

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?

Community
  • 1
Ryan Lue
  • 891
  • 1
  • 6
  • 18

4 Answers4

12

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

poppyschmo
  • 136
  • 3
5

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'

Resources:

:h :let-option
:h split()
:h runtimepath
romainl
  • 40,486
  • 5
  • 85
  • 117
  • 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 '15 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 '15 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 '15 at 18:25
  • @lcd047, I changed the wording of the first sentence as per our conversation. – romainl Jun 27 '15 at 20:40
  • Did it for me, and strikes me as the most elegant solution, given my setup. Thanks!! – Ryan Lue Jun 28 '15 at 05:38
  • Quick update: I ran into an issue where this line ran every time I sourced my .vimrc file. If I sourced .vimrc more than once per session (e.g., when tinkering with .vimrc and trying to test the results), viminfo's location would be set to C:\Users\Ryan\vimfiles\viminfo,nC:\Users\Ryan\vimfiles\viminfo. To resolve this, I wrapped this line in the following if statement: if &viminfo !~ ',n' (which returns 0 if viminfo matches the string ',n'). – Ryan Lue Jul 02 '15 at 02:50
  • Or, you can avoid re-reading the value by setting a global variable and checking that it exists (the same as plugins check to see if they're already loaded or not). E.g. https://github.com/mhinz/vim-randomtag/blob/master/autoload/randomtag.vim#L7, resp. https://github.com/mhinz/vim-randomtag/blob/master/autoload/randomtag.vim#L60 – VanLaser Jul 05 '15 at 22:30
2

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.

user1640896
  • 21
  • 2
0

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.)

Edward
  • 111
  • 2