For the past month or so, I’ve been using the standard editor: ed. It’s standard because it’s old and has outlived everything which came before it. And it’s so old that using it has become a bit of a meme[i], but it has lessons for anyone who wants to take it seriously.

Ken Thompson created ed to run on a typewriter connected to a computer (i.e. a ‘terminal’). He would type out what he wanted, and the typewriter would type any response. But long responses, like DOCUMENT SAVED SUCCESSFULLY or ALTERATIONS ACCEPTED. NEW LINE READS AS FOLLOWS: ... would waste paper. Instead, ed communicated success by staying silent, and communicated errors in your coding by typing ?. If you want to know what that ? means, you can get help by typing h. And if you want to know that typing h will help you then Ken Thompson expects you to read the manual before you start using the thing (it’s only 11,000 words, about the length of a newspaper if you ignore most of it).

Typing in ed won’t teach you much, except that you don’t like ed. But ed is not just made to type, save, and forget - Ken Thompson made it to edit files, and that’s where things get interesting.

Open a file to edit, and you see this:

And that scares people. But don’t be scared. It’s a character-count for the document, so if you print out the document, the typewriter will need to go ‘thwack!’ 9,162 times to type the entire thing out. Sounds expensive!

Unlike Ken, I edit markdown files, which become pages like this thing you’re reading. So I start a session with ed by asking where the headers are in the document.

We can look at the section ‘Generating Content[ii]’ by asking ed to print lines 25 to 96:

It’s a drag, but an interesting one. To move, to think around the document, you must deliberate in the document’s own terms (line-numbers) about which lines to read, and then what to add or change. And you can, of course, change; but again ed demands deliberation. You must specify which word you want to change to what, and the result (in the best case scenario) is nothing, because ed does not show you how the new line looks. The text document must live mostly in your head.

The syntax consists of basic mnemonics. You type s/one/two/ to substitute ‘one’ with ‘two’, or c to change a line. Moving lines uses ‘t’ for ‘to’, as in 37t24: ‘move line 37 to line 24’. The syntax matches sed exactly, which makes sense, since sed is the ‘stream editor, so the early users ofsedwould presumably think 'oh this is easy, it's just likeed'. But we rarely usesedenough to really learn it; or I never do. I look up a command when I need it, can't figure out *why* the command works like that, then forget the command immediately. Working a week withedhas made it easy to parse/^#/s/Ed/ed` (meaning ‘find the next line starting with “#” and substitute ‘Ed’ with ‘ed’).

Some of these substitution commands can look verbose, but ed comes with a rare feature; something present but mostly forgotten in vim, and entirely lost to modern editors like VS Code. You can script ed. Just like sed and awk, you can use this tool to work on a document until you feel sure you know what you’re doing, and a little bored. Once bored and certain, you can place your command in a script and make the computer do the work for you. I don’t use this feature much, just like I never used to imagine changing metadata with sed. Perhaps if I use it for another month it’ll become second nature. Some[iii] just find it easier to use than sed.

Whatever its direct uses on a document, it will always retain a similar benefit to using a paper-and-pen: it demands deliberation. No hopping around the document like a drunk hummingbird. No colour syntax or spellchecker. Just a blank page, and the question of what exactly you want to do in order to get your ideas pressed into the disk.

[i]

[ii]

[iii]