Quick and Dirty way to manage my VIM config

Not sure about the others, but the obsession to my coding tools is probably more than I would admit. I have just managed to do a dirty quick hack to manage my VIM configuration settings. While I am sure there are other people doing this, I would like to show my reinvented wheels.

Boring background

My last post on this topic was mainly about the discovery of vim-pathogen. While it is great for installation, but it doesn’t offer much in terms of management. Hence there are a couple of plugins available to solve this problem, I don’t find myself liking them (at least for now).

In the post mentioned above, I briefly mentioned the problem of sub-repository of Mercurial. It turns out I am abusing the feature, not using it as designed. Besides that, there was another problem with tracking the entire home directory with Mercurial. It sort of screws up MacHg’s operation as it picks up the .hgignore settings in the home directory whenever I try working with my projects (which resides in $HOME/Projects).

So I stopped checking in my configuration changes to my bitbucket repository for a while.

Then I was trying to change my current colorscheme to one of these (zOMGOMGOMG so colourful). Then I thought of pushing my changes so I can use them on my shared server account, my Ubuntu workstation as well as MacVIM. Got sick of trying to fix these things over and over again, I was contemplating the idea of starting everything from scratch again.

However, after a quick check, I found the repository only holds VIM configuration. Also, most of the plugins are hosted on either github/bitbucket. Therefore, I decided to fix this problem by starting a new project.

My VIM manager

Instead of tracking the real file, I decided to symlink both .vimrc and .vim from another folder. Considering I track only VIM configuration, it feels more manageable this way. At least, I do not have to worried about screwing up repositories stored in the sub-directories.

As this is meant to be a very personal script, I mix both configuration and the scripts together in one huge package. I don’t have much interest in separating them. If I ever feel the need to make it scaleable, I would probably switch to something more tested and reasonable like vundle.

To try using this manager, just clone this repository. Then make sure both configure.sh and generate-make.php executable. Obviously to use this, PHP is needed. Another pre-requisite would be hg-git for mercurial (This is meant to be quick-and-dirty, so I use tools I am familiar with).

Once done, just execute the configure.sh script.

$ cd vim-manager
vim-manager $ ./configure.sh

Then there should be a generated Makefile. Back up the current VIM configuration, and delete them (both .vimrc and .vim). Then, simply run the installation as follows,

vim-manager $ make

If you want to speed up the installation, just use the -j parameter, as follows,

vim-manager $ make all -j4

To remove everything, just issue a clean command,

vim-manager $ make clean

To update all the plugins/bundles (including pathogen), just do

vim-manager $ make update

if you want faster updates. To speed up the operations, just try with a sensible -j parameter. For instance, for faster updating, just do

vim-manager $ make update -j4

Pretty much that’s all for the usage notes.

Customizing

As seen in the repository, the vimrc file is stored in a text file named vim-config. Other bundles that are not easily available through github/bitbucket are stored in default-bundles. I probably shouldn’t be doing it that way, as this might violate the license of the respective code. I would have to find a way to fix that soon.

If one has own personal bundles, and can’t be accessed by mercurial, just put them in the default-bundles folder. For those bundles that are available through services like github/bitbucket, just edit the config.json file. Then regenerate the makefile and make a re-installation/update.

Warning

While the code works for me, YMMV. Please do a backup before attempting to use this script (which I doubt if a sensible person would do). If this indeed screws up your VIM installation, please remember this was written mainly for my own convenience.

TL;DR

I wrote a quick and dirty hack to manage my VIM installation. Get it here and figure out yourself how it is used.