Pros and cons for each vimrc cross-platform solution?

When dealing with .vimrc configuration files in Linux and Windows (two systems I've been using so far) and trying to keep configurations cross-platform, I've found mainly two sol开发者_开发问答utions:

1. Create a new folder for vim files in /home/user, so both systems have the same vim dirname (instead of default .vim in linux and vimfiles in Windows), and use set runtimepath to get this new folder;

   set runtimepath=~/vim_local,$VIMRUNTIME source ~/vim_local/vimrc

   Source

2. Create a bunch of os conditions (like has("32")) in .vimrc when needed, based on platform or capabilities, but keeping the original unix names and creating symlinks in Windows home folder to the original files (vimfiles to .vim somewhere, maybe a .vim dir in Windows home, or even a dropbox folder). (I haven't tested this approach in older Windows versions like XP).

Which solution do you prefer, and why? What are the disadvantages from each solution? Which other solutions do you have? (You can post your own .vimrc here as well to discuss.)

If you use some source control in your .vimrc configuration files, do you version your plugin files as well (so when "deploying" your config across computers, you only do a checkout/clone from your repository)? A lot of people are using pathogen and keeping each plugin inside it's own folder (usually a git repo from github). Does it make sense to version control a plugin that is already a repository from elsewhere?

I use something approximating option 2, but probably considered option 3. I keep everything in a single folder called either ~/.vim or c:\vim\vimfiles. These are version controlled with Bazaar and held on a server with sftp access. When installing vim on a new Windows machine (with Bazaar), I put it in c:\vim\vim73 and do:

bzr co sftp://<username>@<server>/path/to/vimfiles
copy vimfiles\vimrc_linker.vim _vimrc

On Linux machines I do:

cd
bzr co sftp://<username>@<server>/path/to/vimfiles .vim
ln -s .vim/vimrc_linker.vim .vimrc

vimrc_linker.vim contains one line:

runtime vimrc

which opens up the file called vimrc which is stored in .vim (or vimfiles on Windows). This allows me to keep my vimrc under the same version control as the rest of the .vim directory. Since I use cygwin Bazaar on Windows usually, I keep all of the plugins with unix line endings to avoid compatibility issues (both Windows & Linux vims cope with unix line endings in plugins, but the Linux one doesn't like Windows line endings).

The use of version control allows me to keep all the PCs that I use in sync very easily and if I install a plugin and don't like it, I can very easily revert the change without having to think about which files were installed by that plugin (the VCS tells me).

As for the os conditions, I use has("win32") etc to differentiate. However, there are very few situations that require this differentiation, so it's a minor inconvenience. My vimrc is 1000 lines long (it has quite a few functions that I've never got round to splitting out into plugins) and only about 10-15 are inside the has blocks:

• Font configuration
• Path to ctags/cscope as I have a Windows executable in vimfiles for ease of getting it working on multiple PCs without lots of installing
• Undo dir location
• A mapping (,x) for maximising the GVim window: this is done differently in Windows & Linux
• On Windows, some mappings for vimtweak.dll to go completely full screen (no title bar or anything). Haven't found an equivalent for Linux.

I put this in my .vimrc:

set runtimepath^=~/.vim  "Use instead of "vimfiles" on windows

so the .vim directory name stays on both platforms. I could use an os condition to only run this on windows.

I've found that it's best to be as unixy as possible, even on windows. I use unix line-endings by default (you don't want a CR in the vim config, especially):

set fileformats=unix,dos,mac

And platform-specific fonts:

set guifont=Consolas:h12,Monaco:h15,Inconsolata:h12

I'm also using version control (git/github) for the dotfiles/config/etc in my home directory, and it works great. The only trick was setting up the ignored files correctly so that I'm not constantly told about all the files in there I don't want to version (I had to use .git/info/exclude because .gitignore in the home folder has a special meaning).