On Switching to Ed

2020-09-29

A Viable Alternative?

The text-editor ed, one of the original three Unix programs written by Ken Thompson, is now almost half-a-century old. The world of Computing has changed to a frankly unrecognisable amount since then; we are no longer limited to editing programs from a line-printer, no longer restricted by paltry kilobytes of memory, and have more computing power than ever to make the act of editing text as seamless and feature-full as possible. Yet despite all this, ed is still bundled with almost every Unix-like and many still stand by its tag line of being “the standard text editor”. Why is this, is using ed as your primary text-editor still feasible, and what lessons from ed can we apply today when it comes to modern software-design and usability.

ed (pronounced E-D) is a line-editor from the days of yore; when software was simple, mainframes were at the cutting-edge of Computing, and access to a monitor was a luxury. Intended to be used with a line-printer, a printer that literally prints the output of any command line-by-line, ed emphasises simplicity and efficiency, if it isn’t necessary, it isn’t here. By default, you won’t even get an error message if you make a mistake, just an ambiguous ‘?’.

My decision to try switching to ed came as its almost brutal simplicity seemed alluring in a world of it-does-everything IDEs and 500+Mb Electron-based editors; even my trusty Vim appeared somewhat excessive after I’d installed my supposed ‘mandatory’ plugins. Of course ed having the tag line ‘the standard text editor’ also had an air of confidence that was hard to ignore for a piece of software that may very-well be older than some of its users at this point.

Pure Text Editing

Ed lets you edit text. It’s as simple as that. It does not do formatting, it does not do spell checking, it doesn’t even show the file you’re working on when you open it initially. ed trusts that you know what you’re doing and does everything possible to get out of your way. It is a shining example of the UNIX-philosophy, do one thing and do it well.

This focus on text editing in the purest sense can certainly be off-putting upon first sight. I myself was unsure to begin with why I would bother using such an arcane piece of software when so many other, and apparently better, editors exist? I can edit text at the speed of thought in Vim, do practically any operation under the sun in Emacs, have complete version control functionality in Visual Studio Code; what could ed possibly bring to the table in todays world?

First Impressions

Initially getting usage out of ed was slow however the basic commands were simple enough: Use ‘i’ or ‘a’ to enter edit mode, ‘.’ on a newline to return to command mode, ‘w’ to save etc. These were all pretty straight-forward and were already somewhat familar to me having come from Vim.

An area that was of significant gripe however was moving around; ed does not show the file you are working on as you do so meaning it is up to you to remember what text exists on each and every line. Of course, it’s absolutely possible to print a numbered listing of every line in the file with ‘,n’ (a comma referres to the complete file) or print the contents of a given line with ‘Np’ where ‘N’ corresponds to the line in question. Repeatedly doing this however will pretty quickly grind your speed to a halt which is where I began to realise just what ed was getting at.

ed is here to let you edit text and nothing more; as such it expects that you will remember the text you have actually written. With this piece of information in mind, it started to become more clear of how ed should be used.

Clicking into place

One of eds’ biggest benefits was something I didn’t realise until after I tried to use another editor. I wanted to do some more complicated work on a larger file and, in order to save time, decided to temporarily switch back to Vim.

Having gone from the frankly brutalist ed to my multiline, multicoloured, status-bar-laden Vim, the term sensory-overload comes to mind. Having an entire file visible on screen at once is handy…in theory, however it can quickly lead to confusion and slow productivity as you endlessly scroll through function after function. Instead, ed promotes that you actively remember the structure of the files you’re working on and act accordingly. While using ed, I found it easier to remember the order for passing arguments to a function rather than using multiple tabs in Vim to look at a header file or splitting the window in half with tmux to see both at the same time. This more often than not was because the output from ed is so sparing that I could have printed a line 20 minutes ago and it still be visible on screen because ed had no need to display anything other than the text I had added in that time. In addition, because when programming you’re likely to be jumping between the same sections of code repeatedly such as a functions declaration and where it is called, you’re far more likely to engrain those relevant lines that could pretty easily be forgotten amongst the visual noise of other editors.

Regex

I said earlier that ed lets you edit text and nothing more, that may have been an overstatement. ed allows you to insert or append text and nothing more. As such if you make a mistake on a line there is no way to quickly jump to the incorrect spelling or double spacing and fix it. The only way to do so is with Regular Expressions. Using Regular Expressions effectively has never come easy for me, I’ve often found the syntax confusing and more often than not ended up mistyping an expression and wiping out blocks of text by accident.

With ed, my only option for correcting any mistypes and other errors was to use regex and to use it well (ed only lets you undo one mistake so there’s little room for error). As is a running them at this point, ed supports only the essentials, that is to say only basic regular expression syntax is supported meaning any complex search patterns must be constructed by hand.

Benefits of Learning to Use ed

This focus on the absolute essentials offers a level of speed, once basic competency of eds’ commands has been reached, that could very well rival the supposed ‘flow’ state that many experienced Vim users reach, I myself never being fortunate to join that club. With ed anyone can quickly begin flying around files, making adjustments on the fly and even extending eds’ functionality via pipes and redirects to offer practically limitless possibilities.

Extending on the above, the inclusion of only essential features can also be useful for keeping onself on task as there’s no chance of error popups or automatic code formatting while you’re working meaning you can fully immerse youreself in the task at hand. In addition, I finally learned how to write proper Regular Expressions, a skill that can be transferred to practically anywhere I might be working with text.

My New Text Editor?

Will ed replace Vim for me? Absolutely not. For all its beautiful simplicity, modern programming processes have moved on and just don’t fit well with the kind of workflow ed was designed for. That doesn’t mean ed is not more than a novelty however, using ed forces you write good code lest it become impossible to work on should you get lazy with your structuring.

The return to basics can also be somewhat sobering, Yes it’s ‘cool’ to open up your editor with its multicoloured highlighting, code minimap, and realtime linting but is all of that really necessary when it comes to just writing code?

Don’t learn ed so you can say you use ed, learn ed to make yourself a better programmer.