Putting .vimrc in vimfiles directory

Question

I want to keep my Vim and Emacs configurations under version control, but I don't want my entire home folder there (or rather, I do, but there should be 3 separate repositories). With Emacs it's easy; if ~/.emacs doesn't exist, then ~/.emacs.d/init.el is used as the init file. So I can have a separate Git repo in ~/.emacs.d/. With Vim, it seems .vimrc can only exist in home folder and not in ~/vimfiles (the equivalent to ~/.emacs.d). Is this the best way to put .vimrc under version control?

Decompound

Answer 1

Perhaps moving your .vimrc to ~/.vim/ and symlinking to home will do?

Other, much more modular approach is to move your startup script to ~/.vim/plugins/, perhaps create a subdirectory there, and single or multiple init scripts: Vim will do a :runtime! plugin/**/*.vim when starting.

Teth

Your second suggestion is precisely what I was asking about. – Decompound

As it happened, I was forced to use the runtime vimrc approach after all, to ensure that my startup script is loaded first and loads Pathogen before Vim gets the chance to do :runtime! plugin/**/*.vim. – Decompound

Oh, these kinds of special conditions may indeed invalidate otherwise such a nice technique. Have you read :help starting.txt for additional tips? The files are sourced in alphabetical order, so renaming your startup script to 00_startup.vim could work? – Teth

Answer 2

Just put a dummy .vimrc in ~ with just a single line:

source ~/path/to/real/vimrc  

Works like a charm

Caespitose

Answer 3

As @Progo suggests in their answer, ~/.vimrc settings can be moved into a "plugin" script within a file like ~/.vim/plugin/00rc.vim.

There are a couple of things to keep in mind when going down this road:

Users and plugins alike expect that the settings in ~/.vimrc have been loaded before plugins are as described in :help startup. ~/.vim is usually first in 'runtimepath', but if the user has other plugins in ~/.vim/plugin, the .vimrc replacement must be lexicographically first to ensure it is loaded first, perhaps ~/.vim/plugin/00rc.vim.

When the vim startup process moves from step 3 'Execute Ex commands' (where .vimrc would have been read; again, see :help startup) to step 4 'Load the plugin scripts', it runs :runtime! plugin/**/*.vim. This command looks through 'runtimepath' for matching files to source and then starts sourcing them. This means that if something in ~/.vim/plugin/00rc.vim modifies 'runtimepath' then it will have been too late to affect which plugins are run. This occurs most commonly with pathogen and in that case it can be worked around by adding the following lines to the end of ~/.vim/plugin/00rc.vim:

" Since this "vimrc" is really run as a plugin, vim has already compiled the
" list of paths/plugins that it wil execute at startup.
" As a result, the pathogen plugins must be run manually.
runtime! bundle/*/plugin/**/*.vim
runtime! bundle/*/after/plugin/**/*.vim

Finally, (again as explained in :help startup), if a ~/.vimrc file isn't present, vim will search for other files like ~/.exrc so it may be necessary to remove them if their contents are unwanted.

Chromophore

Answer 4

Adds a step to the process, but I just have a bash script deploy.sh in my vim settings.

#!/bin/bash

if [ -f ~/.vimrc ] && [ ! -L ~/.vimrc ]
then
    echo "Backing up existing ~/.vimrc to ~/.vimrc.bak"
    mv ~/.vimrc ~/.vimrc.bak
fi
if [ -L ~/.vimrc ]
then
    echo "Already have ~/.vimrc symlink, we're good"
else
    echo "Creating symlink ~/.vimrc, which points to ~/.vim/vimrc"
    ln -s ~/.vim/vimrc ~/.vimrc
fi

git submodule init
git submodule update

Errol

Answer 5

You could just keep a backup in version control and deploy it (i.e. move it) to your home directory when you need it. You could write an easy script to manage all this handling so at least transparently it won't seem like a lot of annoying work to move it back and forth.

Winded