The Cadence and Flow of Editing Programs

I figured out why my trists with other editors often end up back at TextMate. It sounds a bit like this:

Tap-tap-tap-tap-tap-tap; TAP; tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap; TAP; TAP; tap-tap-tap-tap-tap-tap; TAP.

When I’ve used vi and its descendants, it sounds like this:

Tap-tap-tap-tap-tap-tap; taptaptap; tap-tap-tap-tap-tap-tap; tapTAP TAP! tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap-tap. tapTAPTAPtapTAP TAP!

And Emacs sounds like this:

Tap-tap-tap-tap-tap-tap; tapTAPtapTAP. tap-tap-tap-tap-tap-tap;tap-tap-tap-tap-tap-tap;tap-tap-tap-tap-tap-tap; tapTAP TAP; TAP TAPtapTAPtapTAPTAP. tapTAPtapTAP!

Lest you fear I’ve created some Ook-like language for describing shortcuts in any known editor, let me explain what’s going on here.


Emacs is, at it’s core, a Lisp machine with a text editing language wrapped around it. Every interaction with Emacs invokes a function. Handily enough, the function that adds an “a” to the file you’re editing is bound to the a key on your keyboard. Oddly enough, the function that writes the file you’re editing out to disk is bound to the combination of hitting control and x at the same time, followed by control and s at the same time. Getting them out of order matters. Control-s followed by Control-x does something entirely different.

So when you use Emacs, you type a bit, and then you run some command. Maybe you save the file, or switch to editing another file, or go to peruse a directory. So you tap for a while and then you stop tapping, move your hands every so slightly to mash the control, or alt keys and then tap some other key, usually emphatically. The most commonly used key combinations end up being hit even more emphatically. Sit in a room full of developers using Emacs, listen closely; every once in a while, you’ll here everyone save almost simultaneously and go back to a furry of lower-case tapping.

Vi is slightly different from Emacs in that it is built up from two Unix commands: one for editing single lines of text, and another for moving between said lines of text. Thus, the cadence of a vi user is slightly different. Staccato taps followed by a bang as they switch from line editing to line navigation; more staccato taps, this time oddly spaced as they move between lines and place the cursor to begin their next fury of editing; another burst of staccato text entry; a quick and emphatic tap to take them out of editing mode and then a quick but punctuated trio of taps as they invoke the command that saves the file out, a sequence of finger movements so ingrained in the vi users brain that it appears as more of a gesture than a triplet of discrete key presses.

Here’s a project idea for pranksters: stand in a room full of people using vi and Emacs, listen for the really emphatic taps, and trip the room’s breaker right before they all finish their emphatic save commands. Cackle as chaos ensues.

The space between the taps

A roomful of vi-users, Emacs-users, and TextMate users is a homogeneous mess of clackity-clackity to the untrained ear. Most accomplished programmers are touch typists, so what you’re likely to hear is an undifferentiated stream of rapid-fire tapping. But if you’ve used these editors enough, and wasted enough time thinking about the aesthetics they represent, you can hear the differences in the punctuation as commands are invoked by arcane combinations and sequences of keystrokes.

In Vi and Emacs, there is a concise sequence of keys you can mash to do a regular expression search, move down three lines, go to the second sentence on that line, and replace the word under the cursor with “bad-ass text editing programmer, do not offend”. It is, in part, this power that attracts, fascinates, and empowers their users.

TextMate can do this, sure. But there is very little in the way of support from the editor to do it. You mostly have to put your eye on the piece of text you wish to edit and use some primitive motion keystrokes to get the cursor where you want it. Then you use those same keystrokes to highlight the text to replace, this time holding down a modifier key, then you type in the text you want. TextMate, compared to its programmers editor brethren, is a language of grunts and chuffs next to the sophisticated Latin or French of vi and Emacs.


TextMate is unsophisticated next to the extensibility and conceptual unity of Emacs, or the pure practicality of vim. So why do I keep coming back to it?

It keeps me in flow.

This is a very personal answer. I’m not saying you can’t achieve a flow-state with vi or Emacs. I’m saying that while I like the idea of those editors, understand the aesthetic, and enjoy watching skilled operators using them, I get lost in the punctuation when I use them. I either forget what punctuation I should use in some text editing scenario, or I have a nagging doubt that there is some better punctuation I could be using instead.

If vi is about navigating lines and editing those lines; Emacs is about invoking Lisp functions on files containing text, then TextMate is about primitive but direct manipulation of the text in a file. There’s very little conceptual overhead. You don’t need to know how the editor is enhanced in order to understand how to operate it. You don’t need to know when to put yourself in different modes of operation to make things happen. You just think of what you want the text to look like, you move the cursor around and you type on the keyboard.

It ain’t much, but I (often) call it home.

8 thoughts on “The Cadence and Flow of Editing Programs

  1. I wrote something related recently,

    (the context is helpful excitement, not anger…) “If you really can’t stand the key combinations then change them! I’ve set my Emacs up with a very OS X muscle-memory friendly configuration, Command-S,C,X,Z,F,G,W,Q all do what you’d expect. This isn’t a sin against Emacs, this is Emacs.”

    What I like about Emacs is that I was able to implement (err, configure, I still hardly know Elisp) pretty much everything Textmate offers within a couple days. From there on you’re able to extend and customize things you don’t like (such as a better equivalent to Textmate’s crappy Go To File that I’d mentioned before). Of course, whether or not it’s worth the time investment to you is subjective.

  2. FWIW, I’ve been using Aquamacs with Chris Wansrath’s dotfiles for the past month or so. I’m finding it much less of a cognitive cost than using Carbon Emacs with the Emacs Starter Kit. The ESK is great stuff, but I am possibly too big of a weenie to use something so idiomatic.

    The main reason for this switch? I found that the aforementioned Go To File was knocking me out of flow. I was having to think too much about how to switch to a file, and wanted to get back to a one window, multiple buffers world.

    As ever, we’ll see how long this tryst with Emacs lasts. ;)

  3. Never thought about the different typing sounds from the different editors. I 100% agree with the point about the editor keeping you in the flow state. For me Emacs does this better than the others and I feel Emacs is the “primitive but direct manipulation of the text in a file”. Maybe once each person learns their editor, it just comes down to text manipulation?

    I think you dodged a major question though: if a programmer edits text in a forest and no one is around to hear it, are they really editing? I think we need a real world experiment to test this theory.

  4. If you type more than two lines of text at a time while programming, you’re not thinking hard enough. Either that, or you haven’t learned how to cut and paste in your editor of choice.

  5. I like the way you’re looking at editor workflow as a rhythm. I think it also highlights the difference between an IDE and a text editor. Most IDEs add features for everything but text editing (such as build customization). Text editors focus on the process of entering text and editing it.

    My personal editor customization style is “steal from everyone.”

    I’ve taken Vim’s “scroll the current line almost to the top” and TextMate’s “Command-Enter for a newline below and Ctrl-Enter for a newline above” back to Emacs. And like Brett, I use meta key combos for my most common tasks (instead of combinations like C-x C-s).

    TextMate has many Emacs and Vim features baked in, but people rarely use them (e.g. quick interactive search with “Ctrl-s”).

    The nice thing about TextMate is that individual customizations are self-contained. It’s easy to make an unbootable Emacs by writing incorrect Elisp, but it’s hard to break TextMate.

    On the other hand, the UI of TextMate can be thoroughly customized with Objective-C plugins, yet people have yet to take full advantage of those capabilities.

  6. Mr. Funky,

    Steal from everyone is a great idea. I’m going to borrow that one from you.

    It’s all about flow for me, lately. As I noted earlier, I got to a point where TextMate’s “buffer switching”, or lack thereof, was making me think too much. I’m finding Aquamacs to be a nice compromise between an idiomatic editor like TextMate and something more flexible like Emacs.

    That said, there are still a number of things I have to do on occasion that are bad-to-atrocious in Emacs. Editing any kind of template in a Rails app is tops. Working with Markdown is also up there. For these tasks, I’m happily falling back to TextMate and brushing off the mild guilt of not using one editor to rule them all.

    When it comes down to it, I rule these editors. I’ve gone too long letting them push me around. It’s time to show these guys who holds the keyboard, here.

  7. I have no problem with using multiple text editors for different purposes. I do admit that it’s sometimes hard to switch muscle memory between completely different styles of editors.

    I think the TextMate buffer issue is something that could be solved with a native plugin.

  8. Like you said, TextMate has borrowed enough from Emacs, and OS X is Emacs-y enough in its text motion keybindings, that switching back and forth is not horribly jarring. An investment in Emacs muscle memory is a good investment indeed.

    I’d love to see push what can be done with improving TextMate from the inside via Cocoa plugins. However, these seem like a long-term risk, in the event that TextMate 2 ever comes out. That said, I would admit that going ahead and building them is a good risk to take at this point.

Comments are closed.