||[Mar. 22nd, 2009|10:06 am]
The saga of emacs-vs-vim is legendary, and hearing the passionate rhetoric on both sides, you get the impression that you should at least try both out, and see what the fuss is about. Of course, everybody will admit that neither one is for "just trying": vim takes, by various estimates by vim users, weeks-to-months-to-years to learn to use properly; apparently Emacs requires learning a Lisp dialect and building up configuration files. The goal of vim is that you go to any *nix terminal you want and suddenly can edit source code at a high level. The goal of Emacs is the exact opposite: that the text editor should come to fit you like a well-worn glove, to the point where whatever keys are most intuitive to you are bound to whatever actions you use the most.|
Typing "vim ycombinator.text" creates a blank screen with color-coded tildes, which I can immediately understand are "this line is not actually in the file" markers. Good stuff. As I begin to just write out the first word, "function", I quickly notice that absolutely nothing is being written to screen, and the screen spits back some kind of error at me: "E35: No previous regular expression." Wha...?
Okay, so I have to google a tutorial to find out that, in fact, vim doesn't support editing by default. Instead, it dumps you into a command mode, and editing is accomplished by typing the "i" or "a" keys, to get into "insert" mode.
Insert mode is like a very crappy text editor, because it lacks all of the basic amenities you like (which have been moved to the command mode). For example, if you press the left arrow key at a new line, you might have expected to jump to the end of the last line. That doesn't happen. Also, it doesn't auto-indent your text. Word-wrap is enabled, but it's strictly speaking a character wrap: if your word is too long, it gets divided in half across the lines. And the up and down keys don't move within the virtual lines of a word-wrapped line, but instead move to the next physical line up and the next physical line down.
The command mode includes undo commands for anything that happens within command mode. These are vital if you want to waste your time with command mode, which is apparently necessary to be a real Power User of vim. So let's experiment with those. Poring over several web pages, it's a while before I find anything useful. Here's one: I prefer my tabs to be four spaces long. Since vim apparently doesn't grok this by default (i.e. notice that the last line I wrote was tab-indented four spaces, and thus make the next one the same), the command string goes something like this:
0i Esc,j0; ..j0...j0..j0. or so. Since most of these characters are typed with the right hand and they're in wildly different places, this is really inconvenient, but at least you get to see some sort of benefit from the multiple-periods.
Okay, but that doesn't need to be done in command mode. There's a third mode intended for problems just like this, called "Visual Mode" (really meaning "Selection Mode"). You type Ctrl-v, you select a box with your cursor, and then you type
I Esc to indent multiple lines by four spaces. And then you have to do it again for the interior code. And then again for the code inside that.
The rest of command mode strikes me as deliberately inconvenient. Yes, there is a backspace function, no, it isn't accessed by hitting the backspace key (bwuh?!), but rather by hitting Shift-X. Without the shift, the "x" is secretly the "Del" key. Some things are exceptions to this rule: Entire line edits can often be done by repeating a command twice, so ">>" indents a line, "dd" deletes a line, "yy" copies a line onto a clipboard. (Not *the* clipboard -- vim is completely oblivious to your system clipboard. It has its own internal clipboard, though, and you can copy things to it with "y".) The find key ("f", thank God) only works on the current line with a one-character input, and *cannot* be repeated by period -- to make it search backwards, you need to use F instead, to make it search for anything more than one character, you need the / key, which can be repeated (i.e., find the "next" result) with "n", even though the "f" key cannot be repeated with n. Incidentally, this is why I got the previous error, "E35: No previous regular expression."
To summarize: vim's actual text-editing component, insert mode, is a crippled and horrible mess, lacking the most basic of text-editing and code-editing idioms. To rectify this problem, vim includes a separate component, command mode, by default. Everything that you would expect to have a non-text-editor mode (e.g. find/replace, saving to a new filename) is jammed uncomfortably into this one modality, along with many things you would expect to have in text-editor mode (e.g. copying the current line, undo/redo, quit the editor, et cetera). One particular idiom which you'd expect to find in text-editor-mode, namely text selection, is in fact given a third mode completely different from the other two. And, as a bonus, all of the things you might like to do in command mode are based on a single-character language which you'll have to become fluent in before command mode becomes at all useful to you. And if you are generating large amounts of new code, command mode is not the idiom du jour -- command mode mostly suffices to help you search around in a document that's already been created and copy text from point A to point B.
Unless I've missed something.
I don't see why vim devotees claim that vim makes their coding much faster; I haven't seen anything in vim to suggest even a possible ~10% coding speedup waiting around the corner. Rather, since it lacks some basic amenities, it looks like vim would slow me down by ~10-20% even when I learn it fully and can use it at top-speed. It has brace highlighting. That's about it.
I've tried to also play around with emacs, which also isn't pretty. Possibly there's a follow-up post to this one coming?