[RFC] .config/vim(UNIX), AppData/Roaming/vim(Windows) directory structure

[mattn]

Recently, many application store there configuration files into ~/.config/xxx. This is very useful to take-out configuration files into USB-disk or dropbox. As far as I know, many users make symbolic links into ~/Dropbox/config/vim/vimrc from ~/.vimrc or ~/.vim/vimrc.

ADDITIONAL:

UNIX

$XDG_CONFIG_HOME/vim

Windows

%APPDATA%\Vim

[vyp]

Just a nitpick but should use $XDG_CONFIG_HOME/vim btw. From https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html:

$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

[mattn]

@vyp thanks for the link.

[k-takata]

If we support it on Unix like systems, maybe we should also support using %USERPROFILE%\AppData\Roaming\vim\ (= %APPDATA%\vim\) on Windows.

[chrisbra]

this has been discussed before, e.g. here (which includes a patch, perhaps this can be used as a starting point and cleaned up a bit).

[mattn]

Yes, I could not find the discuss. But I think there are meaning of discussing this on GitHub.

[mvdan]

Copying from my recent dup, #4275:

Right now, the list of paths to search for the user's vimrc on Linux is:

~/.vimrc
~/.vim/vimrc

I propose that we extend it to:

~/.vimrc
~/.vim/vimrc
$XDG_CONFIG_DIR/vim/vimrc (if the env var is unset, its default is ~/.config)

For some further reading on not cluttering $HOME:

https://web.archive.org/web/20190202170417/https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp
https://ploum.net/207-modify-your-application-to-use-xdg-folders/

[brammool]

Copying from my recent dup, #4275: Right now, the list of paths to search for the user's `vimrc` on Linux is: ``` ~/.vimrc ~/.vim/vimrc ``` I propose that we extend it to: ``` ~/.vimrc ~/.vim/vimrc $XDG_CONFIG_DIR/vim/vimrc (if the env var is unset, its default is ~/.config) ```

Does this mean that $XDG_CONFIG_DIR/vim is the replacement for ~/.vim and everything it contains? The XDG spec appears to split things out in different places, but that might just might things more complicated without benefit.

For some further reading on not cluttering $HOME: https://web.archive.org/web/20190202170417/https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp

Interesting, but it doesn't say why dot files are a bad idea. It actually says why people started using them (hiding stuff). XDG doesn't really solve that, just moves it elsewhere. And then there were two solutions...

https://ploum.net/207-modify-your-application-to-use-xdg-folders/

It over-simplifies the issue. For me losing my Vim configuration is like losing an important text file. Like "now I have to reconfigure Vim" is similar to "now I have to rewrite that letter". Anyway, so long as supporting XDG can be done in a backwards-compatible way, that should be fine.

…

-- A successful man is one who makes more money than his wife can spend. A successful woman is one who can find such a man. /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[nuko8]

Recently, many application store there configuration files into ~/.config/xxx. This is very useful to take-out configuration files into USB-disk or dropbox.

I'm afraid the issue is not that simple. For example, let's consider the case where both $XDG_CONFIG_HOME/vim and ~/.config/vim are unreadable for some reason. Then where should we go for fallback? Go to $XDG_CONFIG_DIRS/vim and /etc/xdg/vim in that order, and then ~/.vimrc and ~/.vim? The reversed order also looks plausible. The complexity gets multiplied when we take fallback into account. In addition, if $XDG_CONFIG_HOME/vim (or $HOME/.config/vim) is used, people are likely to think they should have $XDG_CACHE_HOME/vim (or $HOME/.cache/vim) and $XDG_DATA_HOME/vim (or $HOME/.local/share/vim) as well. Should we use those directories when $HOME/.config/vim is used? Which files should we put there, backup, swap, undo, view or viminfo? Should we need to change the behavior of 'directory', 'undodir', 'backupdir', 'viewdir', and 'viminfo-n' in accordance with the XDG specs? Again, fallback is also an issue here. The complexity gets multiplied further. To implement the proposed feature fully, quite a few design considerations and decisions must be discussed and addressed.

[chdiza]

Recently, many application store there configuration files into ~/.config/xxx. This is very useful to take-out configuration files into USB-disk or dropbox.

I solve this problem not by asking applications to look in a special dotfolder (much less a special dotfolder with an enforced name that's longer than is desirable), but by making my own dotfolder (".rc") and symlinking some of the things in it into my $HOME. For example, ~/.vim is a symlink to ~/.rc/vim, and ~/.vimrc is symlink to ~/.rc/vimrc. Then when rsyncing backups I only have to include ~/.rc and not myriad dotfiles.

I do this also for lots of other programs. If I ever end up using something that demands ~/.config, I'll just make a symlink called ~/.config that points to ~/.rc.

It's true that I have to set up the symlinks, but it's trivial to script their creation (and their destruction).

But in many years of using and tweaking this setup, I've found that the benefits of keeping frequently modified dotfiles out of $HOME are pretty overrated. If I want to e.g., edit my vimrc, it's much easier to do :e vimrc than :e ~/.rc/vimrc or make sure to have the right file marks in ~/.viminfo. I'd rather have visual clutter in ls -A than make it a PITA to edit my stuff. So even though I can avoid the ~/.vimrc symlink (since vim will check in ~/.vim), I purposefully don't.

Dotfiles that I almost never modify I keep unsymlinked when possible, by using shellvars to point programs inside ~/.rc. E.g., I do this for npmrc, inputrc, the global gitignore/hgignore, and pip.conf.

[arp242]

Some people seem to make this a bit more complex than it needs to be
(nuko8's comment, the 2014 patch1).

The only behaviour that really needs to change is loading the initial file.
Pretty much everything else can already be configured manually:

set viminfo+=~/.cache/vim/viminfo
set backupdir=$HOME/.cache/vim/backup | call mkdir(&backupdir, 'p', 0700)
set directory=$HOME/.cache/vim/swap   | call mkdir(&directory, 'p', 0700)
set viewdir=$HOME/.cache/vim/view     | call mkdir(&viewdir, 'p', 0700)
set undodir=$HOME/.cache/vim/undo     | call mkdir(&undodir, 'p', 0700)

I also had to link ~/.cache/vim/pack to ~/.vim/pack (setting packpath didn't
seem to work, but perhaps I did it wrong; didn't look too deeply).

I don't think there is a need for complex confusing behaviour changes, much
less new +xdg_basedir compile flags.

I think this should be straightforward and backwards-compatible:

• Add ~/.config/vim/vimrc to the end of the vimrc search order.
• If ~/.config/vim/vimrc exists, use this directory instead of ~/.vim as the default
  for runtimepath, packpath, viewdir, and perhaps some other values?

We could discus whether some of this data should be in ~/.local/share or
~/.cache to no end, or adjust the default behaviour for dir and backupdir,
but that will be backwards-incompatible and won't necessarily make things
easier to understand. If you want it stored somewhere else: just change the
settings.