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.

My adventures started out with vim, which will be the subject of this post. My test document was a mixture of indented Javascript code between paragraphs, motivating the Y-combinator with actual examples and such. A text file deriving the Y-combinator seemed like a nice quick project to jump into any given language: it's not too long; it involves both coding and writing plain text; and so forth.

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?

I think the idea with vim is that if you've been using it for years and flying back and forth between modes is as easy as breathing, it can allow you to do a lot of cool stuff that you'd otherwise have to do manually. It's just that the learning curve is a stone bitch and you don't see any immediate benefit as you're slowly learning to fight your way through the interface.

Just don't ask me what the benefit is of being able to, say, reverse the word order of every two-word line in a file. I'm not a vim user, just the daughter of one.

admittedly I am a vim user. it is definitely not an intuitive editor. I've been using vim for ~6 years, and I still learn new stuff every couple of weeks. but I am much, much faster using vim than anything else I've tried for code editing. that speed up has come in bursts over the years.

some of your complaints can probably be fixed by altering your vim configuration. like having left-arrow go to the end of previous line in insert mode.

vim doesn't purport to be good at general text editing (to my knowledge), just code editing. it'll do plenty of auto formatting for you (like notice that the previous line was indented and the next one should be as well) but it does all of this based on what language it thinks you're writing (based on file type) and a configuration file that tells it about the syntax of that language.

it's not just *a* clipboard that it keeps outside of the system clipboard. vim has lots and lots of buffers, copy/paste just happens by default from one of them.

I look forward to hearing your first impressions of emacs. I don't want to taint your results, but it's basically a terrible operating system that someone decided they could use as a text editor.

I use vim, and an acquaintance pointed me to your blog, and I think I need to comment.

Surely you're aware of the historical reasons the command structure/mode is the way it is, yes? Vi, the vim predecessor, predates mice and other pointing devices, and even predates graphical interfaces. It's designed for efficiency - the kind that comes with practice.

Just as anyone can use a graphical text processor, and it takes effort to learn vim (with much frustration and falls along the way) and be fast and proficient -- so also anyone can use a tricycle, and it takes effort to learn a two-wheeled bike (with much frustration and falls along the way) and be fast and proficient..... Or is it the other way around?

It's designed to be a powerful text editor -- meaning to edit/change/modify, not a text developer.

It's a tool that is exceptionally good and efficient at what it does. I think you may be reviewing it with the thought that it is designed for a different use than you expect.

The weird thing is, I can't put your three different perspectives together at all in my head. I keep trying to extend your arguments into a synthesis, and bizarre things pop out in my head:

"You need to cut the bicycle some slack. It was developed before the time when third wheels existed. We may have better solutions for handling balance today, but we shouldn't judge the bicycle for its failure to stay with the times."

"What, you just expected to jump on a bicycle in the Hague and ride it to your classes in Delft? No wonder you were unsatisfied -- that's not what it was designed for! It was designed to ride down the block to your friend's house, and to otherwise move around in short paths. Of course it seems like quite a waste compared to the trike for going long distances infrequently!"

"Back in the olden days, we didn't really have to write code, we just had to edit short snippets of it. Back then, our programs were basically entirely written for us, and writing whole new programs was unheard of."

Needless to say, none of these really resonates in my head. They all sound bizarre and fundamentally wrong to me. Some parts of it become more synthesizable if we talk about fixed-gear bikes versus gear-shifting bikes, as fixed-gear bikes do indeed predate derailleurs, and lack modern bicycle conveniences like, well, gear-shifting. And coasting. Still, you don't need to consult a manual to find out how to start and/or stop a fixed-gear bike; you just feel uncomfortable on it when you're going over a bump and the bike forces you to keep pedaling.

In any case, the reason why I was writing code with it was because I was told that it was good for writing code -- that it would make me far more productive of a code author in the long run. I've since been told by people such as yourself that no, this was in fact wrong -- vim apparently stinks for code authoring, but is great for code editing. That just seems like a stretch to me.

(Probably the most useful comment was that someone on IRC told me how to get vim to auto-indent like a proper text editor. I don't know why this isn't in the default vim implementations yet.)

First of all. Unless you're only writing view templates the vast majority of any developers time is spent editing code, not writing it.

How often do you create a new object versus editing an old one? Exactly.

Second. RTFM. Multiple generations of developers have found learning vim to be a rewarding activity but not a single one of them has said it was easy. If you're not willing to read the manual fine then, don't use it. But don't then whine about how it doesn't do this or that (when it does).

No, see, if I'm editing code, then that's generally because something has gone wrong, and I have to debug it. In which case, the majority of my time is not spent *editing* the code, but *debugging* it. If I'm writing new code, then I can usually just copy or import my still-functioning old code, so that almost no time is spent editing it. (To be fair, I tend to write generic functions. My Javascript character counter that I use to keep my LiveJournal comments under the 4000 character limit calls a generic Updater() object, I wrote, passing it a reference to the textbox and a function which grabs the text box's length. If I want to write something new, I don't need to change the Updater(); I can just grab it and paste it into a new HTML page, confident that it already works as planned. Thus, I chiefly write new code which imports old code, rather than editing the old code directly.)

In turn, my time is mostly spent on either authoring new code or figuring out where I've written some false assumption into my code. Editing a line of code has never been a painstaking task for me. I have literally *never* even remotely gone, "oh, it's so hard to get to the center of this line and edit the number '2' to the number '4' -- oh life is so tough, oh how will I go on?" Compare this to the frustration I regularly endure when debugging. (For example, in that same Updater() code, it took a long time to find out that I was assuming that the "this" keyword would be a part of a function's closure when it was passed into the window.setTimeout() function, when in fact the "this" keyword works a completely different way than a local variable in that regard. You really should have heard some of the swears coming out of my mouth when I was debugging this particular snippet.)

Of *course* I ended up reading the manual. vim doesn't give you a choice on that matter. You have to google up manuals and tutorials and RTFM before you start using it.

(It's not obvious to me why there should be manuals at all for text editors, though. Let me give you an example: My freshman programming course was taught in Java, and used an IDE called DrJava, which I haven't really used since because, well, I don't really like Java all that much. I didn't require *any* manual to just start using DrJava. The features that it added to my Java programming experience were not only easy-to-understand -- "Oh, this is labeled as a Java Console, presumably, I can type Java code into it and see what it does" -- but it was also obvious that its use would cut down on my code development time -- "Oh, you mean I don't need to point my main method at my latest test method, jump to another console, recompile the program, execute the program, and then try to remember what output I was expecting? Sweet." Same thing when I first got a Linux server: someone mentioned to "nano" this or that configuration file to me, and I immediately grokked how nano works. The fact that a manual should be necessary to learn an editor -- whether a sophisticated IDE or a cheap text editor -- is therefore not obvious to me in the slightest. I've picked up IDEs in the past without manuals. But in this case, yes, I was forced to read manuals and tutorials in order to find out basic questions like, "how do I actually go about *editing text*?" )

And I didn't realise how much I hated CRT screens until I started using LCD. :-)

I can say little more than thousands of developers, some of whom are undoubtedly more proficient than you, have found getting to know their editor to be a worthwhile chore. Assuming you know better without actually giving it a go seems a little off base.