----------------------------------------
ed(1), no going back
April 20th, 2025
----------------------------------------


# ed - no going back

Phloggers of the world have intrinsically an afinity for old unix
history and minimalism, else they would be on other parts of the
internet.

It should come as no surprise that most have an acquaintance with
the standard editor ed(1). It is often treated as an elaborate joke
nowadays to be referring to ed as an actually usable editor.

The war vi and emacs has been raging for most of several decades,
but we can say that nobody takes it seriously. Vi has been superseded
by Vim, which is in turn being replaced by Neovim.  Emacs has now
a marketshare reduced to a bunch of old CS majors, and arcane Unix
gurus (or wannabe gurus).  Neovim is all the rage among hip DevOps,
But let's be clear, VSCod(e|ium) is dominant in the tech sector.
Even some emacs and vim aficionados relish their editor of choice
and their precious dotfiles curated with love and tears to an
electron app.

Where are we heading?  Does a choice of editor even matter?  And
what is the place of ed(1) in all of this?  Stop beating around the
bush!

Lets adress the obvious point, ed(1) is a line oriented editor.
Right, that is obvious.

How is that different from other kind of editors?  Modern editors
are screenful oriented, they display screenfuls of text you can
browse.  They have a cursor you can move around to point at text.
You can move that cursor either by point and click with a mouse or
moving around via keyboard input.

Modern workflows generally imply a combination of point-and click
and keyboard input.  Smartphone's touchscreens give yet another
paradigm, but we won't talk about this for now.

ed(1) is different in that regard in the fact that it impels you
to go forward (to Xanadu we go!).  Once you validated a line input,
it is written in the buffer, and another line is open to be prompted.

Of course, ed(1) is not cat(1), you can go back to a previous line
and edit it. But you have to explicitely refer to it, be it by a
line number or a regular expression to access it for editing.
Whereas in screenful oriented editors, you have the possibility to
move the cursor up and down, back and forth, or directly point at
it.  The flow of text is presented as pages in which you navigate
by scrolling.

Most of the hurdle of an editor is to present an efficient way to
move the cursor where it needs to be quickly and with the minimum
amount of overhead to the user.  This moving around the cursor is
almost a non-problem to ed(1); but this comes at the cost of other
problems (which you are free to consider as features).  Why is that?
Well, the cursor edits one line at a time, so you reduce the dimension
of the cursor from two to one.  Even so, ed(1) has some trouble
with going backwards.  Typing your text is fine, editing before
submitting to the editor is not as free as most editor: no arrow
back, no C-a or Esc-0.  The keyboard shortcuts are the standard
one, C-w deletes word backwards, C-u deletes line backwards. This
is pretty much it. There are ways to have a more featureful line
editing in ed, by wrapping the editor in some tool like readline.
Syntax highlighting with hl or pygment and so on.  Purists may
scream.

In a nutshell, a(dd) and i(nsert) do one job and do it well: add
and insert, not finicky edit a line until it's good to be written
into the buffer.  A line editor like this one is the bane and
salvation of perfectionists.  Or maybe it just sets a new set of
problems for perfectionists...  Maybe instead of frantically moving
their cursor around because their eye has catched a wrong formulation,
or some missing punctuation, they will still do that, but the ed(1)
way?

I can only speak from experience here, but line oriented editing
has helped me with that.  Once the friction of moving the cursor
back increases, that energy is directed towards thinking and writing.
And once there is proofreading to make, it is pretty straightforward
to go to the offending words/sentences and edit them with minimal
input.  It is true, you have to think, but it is pretty much like
a human interaction in editing: "Oh well, you know Ed, where you
say so, I'd like it written in this way".  This is what it feels
like to issue a command like '/re/ s/foo/bar'.  And it feels damn
nice.

Further reading: ed man page on BSD systems (GNU has only an info
manual which is not so nice for a small program); edbrowse documentation
at http://edbrowse.org/usersguide.html; ed Mastery by Michael W.
Lukas

See also: Sam(1), regex(7)