Chocolate and Peanut Butter, Vim and Emacs

Years ago, as I stumbled through my first real programming job, I started paying attention to my text editor. You can run through a haze of text editors before you get Serious About a Text Editor.

I had tried nano, kate, and a whole bunch of others that I can’t recall the names of anymore, but my first Serious Text Editor where I actually read the manual was Gedit.

Now, how do you guess I came upon Gedit? Was there extensive research into the pros and cons? Nope, it was the standard Gnome editor, and I liked using Gnome (think Gnome 2, AKA ’the good days’). Was I happy with it? You bet. It used Python for its API, and I was on a hard Python kick at the time. When your baseline for a text editor is syntax highlighting, the selection is great.

So for several hours a day I would be busting out some hot new code with Gedit, and when I had to do something quick in the terminal, I’d open nano. At some point, I learned just enough vi (save, quit, insert mode, escape key), as a matter of necessity since nano wasn’t always on the machines I’d SSH into.

But one day, I looked over at my co-worker Brian who was cutting up his terminal like he was using a razor. I saw slice up text in ways that just weren’t (and probably still aren’t) possible with Gedit. He was using Vim and Tmux, and that was a revelation. Seeing is believing, and until you’ve seen a master Vim hacker at work, you would not believe the economy of movement.

Migrating from Gedit to Vim was like having my whole workflow kicked down. As painful as the transition was, I saw what Vim could do, and I knew that sticking with Gedit was not a wise 30-year decision.

As my experience with Vim increased, I found I could now go hours without touching the mouse, and with just a few keystrokes I could do things that were formerly time-consuming drudgery. By simply running ‘c i b’ I could eliminate everything between a set of brackets, and be ready to type in something new. With real regular expressions, I could quickly rip though configuration files. Deleting to the end of a file was just putting your pointer in the right spot, ‘v G d’. When it comes to text-editing, Vim keystrokes are still incredibly concise. And while the learning curve was high, I can already say I’ve recouped the time it took to learn and more.

Things were great. I could edit text with ease, and my Vim-fu had given me appreciation for mode-based text editing. But some Clojure work brought me back to Lisp (which I dabbled with in university), and of course you can’t read stuff on Lisp without seeing mentions of Emacs.

What I use today is a Vim emulation layer called ‘Evil’ within Emacs. I’m able to have the text editing ass-kickery of Vim, with the neat extensibility of Emacs. It’s chocolate and peanut-butter, taking the best from both editors.

So, if you’re still with me all the way down here, you’ve probably had the same sorts of experiences I’ve had. I can be sure of that, because no non-IT person would read this much about a text editor. And boy, do we hold our opinions about our tools. In fact, I’m sure Emacs users will say my Vim-time was wasted and I should’ve gone straight into Emacs, and Vim users will say I could’ve accomplished much of the same stuff with Vimscript.

One way you could look at text editors is like looking at cheese or wine. Kraft Singles and Two-Buck Chuck will certainly get the job done, but they aren’t exactly subtle in flavour. But hey, people know that Two-Buck Chuck is wine and Kraft Singles are cheese (in a sense, anyway). So for a non-technical person to pop open Notepad to jot a quick note, good on ya’! Notepad is excellent for that. In fact, Emacs and Vim are terrible choices in that situation. Notepad has no learning curve beyond clicking the mouse button to save and exit. Vim mocks the entry level user, but is a faithful servant to those who know how to dance on the keyboard.

Okay, maybe wine and cheese is a bad example. And it also doesn’t explain why I’m not using an IDE. If I was a less lazy person I would probably make some pretty charts showing knowledge/experience vs. editing power. Maybe they already exist? Point is, Vim and Emacs both reward you for the time you put into it, whereas the person who uses notepad for 20 years will be as effective with it as the person who’s spent 20 minutes.

“But Dave, how do you know you’ve picked the ultimate Serious Text Editor this time?” Unlike my usual arbitrary software selection, this time I actually did an analysis of what I needed from my text editor.

First I would need to take a look at what my needs are for my job:

I need to edit text files containing code and configuration. This eliminates using Microsoft Word, OpenOffice - while these can save in plain-text, they’re far too resource-heavy, and aren’t really built for it as much as rich-text editing. (by the way, if you’re a programmer using Word for programming, please email me and tell me why. I’m really curious if you actually exist.)

Now after that need, I’m left with a list of wants. Working with text for :

Syntax highlighting. It’s so common in text editors that we take it for granted. But it is a strong want - if you choose not to use syntax highlighting (or are colour-blind), you miss out on more visually digestible code, and the bonus of occasional highlighting of incorrect code. This knocks out notepad and other older/lightweight editors.
Keyboard-based navigation and editing. I’ve found it preferable to shun the mouse when doing text editing, and anyone who’s ever used a laptop with a dodgy trackpad knows why. In fact, now that I think of it, has anyone ever made a trackpad that’s accurate? Anyway, keyboard-editing narrows the field even more, and the keyboard shortcuts typically fall into two camps - Emacs and Vim. The Emacs shortcuts require a little more finger dexterity than Vim (I’ve already had to reassign my caps lock key to control), and you can hop on any Vim and be productive, whereas hopping on another person’s Emacs could be a total crapshoot. I’ve been using Emacs for a few months, and I can already tell it will be indecipherable to anyone but myself in a few years.
Language-agnostic. There should be few/no languages that are second-class citizens in the editor, and adding support for them should be simple (as in, I could do it over a couple hours while drinking wine). This is what knocks out IDE’s like Eclipse.
Fast startup. As in under 2 seconds. If I’ve got an idea, I don’t want to wait for my editor to start up. Imagine you’ve got a terrible case of diarrhea, and you had to wait several minutes for the bathroom stall door to open. This is why I tend to stay away from bloated IDE’s - they’re a bit much when I just want to dump my brain into a file before lunch.
Automatic indenting. Once you’ve had automatic indenting, you kind of wonder how you lived without it for all those years. It seems so obvious (like syntax highlighting), but again, it disqualifies several editors.
Keyboard macros. Think of them like a VCR (remember those?) for your keystrokes. Record yourself jumping 8 characters, typing ‘foo’, jumping another 4 words, then typing ‘bar’. Now imagine having to do that over 50 lines - you do not want to do that manually.
Extensibility. This is what’s got me into Emacs for now. Yes, Vim has it’s own scripting language called Vimscript. But I’m lazy, and learning yet another single-purpose programming language really doesn’t appeal to me (at least Gedit did Python). With Emacs Lisp, it’s a lisp variant close enough to the others that it’s still useful to learn. And yes, I’m aware of TimL, which compiles Clojure-ish code down to Vimscript, but if it breaks, I’m still having to learn Vimscript. Emacs is (for the most part) a Lisp interpreter with an editor built in Lisp on top.

Based on those criteria, Emacs looks like my best option for now. But hey, things can change. You never want to be married to your tools -you want to select them based on your needs (and justifiable wants). Brand loyalty is for suckers. So much technology is chosen in this industry is based on well-drawn mascots and slick demos. Do you really want to choose your primary tools because ’they looked neat’? Or do you want tools that reliably get the job done quickly?