Vim

07 November 2013
I first heard of Vim (vi-improved) from a classmate back in my first-semester undergrad days, but to my lasting knowledge I don't think I ever gave it a serious look. Over the years the only time I really came across vi/vim was when using CVS/Svn/Hg having forgotten to setup my config file to use Pico. My usual response being Ctrl-C, killall vi, or closing the xterm window. Recent experience and circumstances has motivated me to give it a proper try-out, and I am starting to warm to it, at least for editing files.The main driver is me being an xemacs user who got a little fed up with its somewhat fading-star support.

Historical XEmacs usage

Historically I have used XEmacs because sometime around 1999 or 2000 I managed to configure it to automatically indent source code to my preferred style, which was a subtle variant of Whitesmiths, and I have since copied the resulting config file everywhere ever since. Over the years I tried other editors, but all seemed primitive in comparison. The one thing I always missed the most from emacs/xemacs is the indentation engine, in particular the c-indent-command, which is typically bound to the tab key. At any time you can hit the tab key and indentation is automatically set based on context, whereas most other editors only handle indentation on starting a new line. For Python, repeatedly pressing the tab key toggles between all the meaningful indentation levels (e.g. whether the line is part of the previous if statement, or follows it).

When I started at my current company, which uses the RedHat-based Scientific Linux, the standard XEmacs package was (and still is) a beta version that is broken in subtle ways, especially with regards to folding-mode. I tried building the stable stable version from source tarballs, but this in itself was a headache, and in any case the resulting binaries had less than desirable results. As for GNU emacs, which on the whole seems to have better support, there was the lack of decent tabbed windows (tabbar.el is a mission to install and even then looks ugly, and I couldn't get the Gtk-Tabs branch working as intended), and folding support lacked highlighting.

Why vim

Vim seems to have wide favour with people at my company, so I decided to give it a fresh try, but what made this a serious effort was having to edit files in a console, and because it was a testing virtual machine running RHEL, installing software for X-forwarding (or anything else) was out the window. Normally I would use pico/nano in these circumstances, but those editors are not exactly geared towards editing source code, and I am not even sure if they are installed as standard.

The thing that really grabbed me with vim was the relative ease in finding out how to do various customisations, so I was able to easily sweep away most of what I considered annoyances, which was in contrast to the complete mission xemacs can be to configure. On the downside, vim very annoyingly hard-wires some keystrokes to send the same signal as individual buttons, such as Ctrl-[ and the Escape key. I suspect this is for ~~hysterical~~historical reasons.

All about keystrokes

While both vim and emacs have lots of archaic keyboard short-cuts, they take very different tacks, which manifests itself as the use of modifier keys versus having different editor modes. Vim's insert/normal/visual modes is pretty unique, and is a royal pain coming from just about any other editor background, with mouse+keyboard cutting'n'pasting being a notable bugbear. However picking up Vim keystrokes is a lot easier than picking up emacs ones, and it makes Vim subtly addictive.

Needless to say, switching between insert and normal mode is still a royal pain, but the edge can be taken off it by making some keys implicitly switch into insert mode. Yes this is much against the spirit of vi/vim, but I don't care about fanboystuff like that:

nnoremap <Return> i<Return> nnoremap <BS> i<BS> nnoremap <Del> i<Del> nnoremap <Space> i<Space>

Idea here is that a significant portion of the time you click to put the cursor somewhere, it is to delete something before typing something else. It is surprising how little tweaks make something so much nicer, though it does need a fair amount of experimentation. Initially I rigged the keys to toggle between insert and normal modes, but found that causing more problems than it solved.

Overall

Vim strikes me as the type of editor that is intended for editing rather than writing from afresh, but so far in my line of work I have mostly been making additions to an existing code-base rather than writing entire blocks of code from scratch. If I was to go back to writing C code on a platform that was not a horribly broken RedHat derivative I would not think twice about reverting to xemacs, but given my current circumstances adapting to vim has been relatively painless.