After trying out Vim for about two months now, I gave a summary of what I like and dislike about it in the thread on the Arch linux forums I was talking about in an earlier post. As this thread still isn’t viewable for unregistered users, I’ll do my summary here as well.
What I like about Vim
The C++ auto-completion (omnicomplete) is not only much easier to install and set up than anything I’ve found for emacs, it also actually works. The closest comparable thing for Emacs is Cedet, which not only bloats emacs’ gui and makes it take even longer to start, it also relies on etags. etags is an emacs version of ctags, the latter of which creates tags files needed for Vim’s omnicomplete to work. Why the developers of emacs chose a different (to me seemingly non-standard) tool for is really a mystery to me.
Moreover, Vim supports a drop-down completion menu out of the box! I know there are scripts for Emacs which do the same, but again, these are difficult to install and also don’t work when using Emacs on the command-line. In Vim, this works exactly the same, be it in gvim or the console Vim.
Finally, Vim supports completion for different types of objects: You can have Vim complete words from open buffers, words from dictionaries, words from omnicomplete or filenames, just by pressing a different key combination. This works, and it works great!
Some of Vim’s movement commands are just incredibly awesome! I can’t sum them all up, but just to give you an example, the “cib” command – standing for “change inner block” – deletes the contents of the innermost ()-block the cursor is in and positions the cursor so that you can replace it. This is such a time-saver that I hardly believe I’ll ever want to live without it.
These movements become even more powerful when it comes to scripting (see next item), where you can use them to step over text objects generically.
Emacs uses the extremely powerful lisp dialect elisp for scripting and extending Emacs functionality. The downside is that to use it, you obviously need to know lisp, which certainly not everyone does. I learned some Common Lisp, but as interesting as it was, I didn’t know where I could actually utilize it and so I never got to train it and kept but the mere concepts of functional programming in mind.
Vim’s scripting language on the other hand is relatively easy to learn, as it much resembles other scripting languages such as perl or python. Even after this short time, I’ve managed to write my first few short scripts which help me in everyday programming. For instance, I wrote a function which generically converts a C++ function declaration to a function implementation body.
- Getting help
Both Emacs and Vim do have a vivid user base who you can contact if you have questions. But often, you just don’t have the time to search the web or hang around in an irc chat. I found that practically all questions I had about Vim could be answered by visiting www.vim.org or using the superb builtin help functionality. I never found Emacs’ help to be even half as helpful.
What I dislike about Vim
- Inconsistent movement
Once you got used to Emacs’ movement keys (e.g. C-n for down, C-p for up, etc), you use those everywhere, no matter what you’re currently doing. This enables you to keep your hands on the main key field of the keyboard, greatly increasing your typing speed while programming.
In Vim, the cursor movement highly depends on the mode you’re in. When in normal mode, you use the hjkl keys to move the cursor around, but in insert mode, these of course produce the respective letters, forcing you to use the cursor keys if you need to correct a mistake.
There are some alternatives for solving this problem, none of which I find very attractive. The first was suggested by a fellow Arch user, alterecco: He has defined a key mapping, in which the hjkl keys are bound to the respective cursor keys and a key to switch between this and the standard mapping. This has the advantage that you can use the hjkl keys as cursor keys in every application, but you need to find a well-reachable key (or combination therof) to switch the mappings. This key of course must not be used by other applications and porting this behaviour to the different environments you’re working on might prove difficult.
The other alternative is presumably the classical Vim way: If you make a mistake, you don’t go back to correct it right away as that would break your workflow, but continue typing until you’re done with that sentence/paragraph/block/whatever. Afterwards, you go back to the error in normal mode and correct it. This is the way I’m currently trying to get used to, but for now, it just doesn’t “feel right”…
Vim has pretty many options for configuring C++ indentation rules. But it still is a limited set of options and as far as I see it, if you want something that is not covered by this set, you got a problem.
Emacs syntactically analyses your code and thus it is easy to configure another indentation behaviour for any place in your code. I find this to be superior to the way Vim handles this, although it covers most of what I need.
- Shell mode
Bash, the default shell of most linux distributions, uses emacs key combinations out of the box, but can also be configured to use Vi ones. I’m still trying out the latter ones, but until now, it seems to me that a) the emacs feature set is much more complete and it b) feels much more “natural”.
I know this isn’t a problem of Vi(m) (if at all), but to me, it belongs to the same topic, as I don’t want to switch editing modes in my mind when switching from editor to shell.
This concludes my preliminary observations of Emacs versus Vim. I hope there are some people out there who might find this helpful. Me, I’m going to continue using Vim until I find a real reason to switch back. Until now, the advantages outweigh the disadvantages by far.