Re: [TUHS] screen editors

[Dan Cross <crossd@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3159 bytes --]

On Tue, Jan 7, 2020 at 11:31 AM <arnold@skeeve.com> wrote:

> Larry McVoy <lm@mcvoy.com> wrote:
>
> > I'm a vi guy to this day.  Love it.
>
> In the summer of '82 I did some contract programming at Southern Bell
> on a PDP-11 running USG Unix 4.0.  It had a screen editor called 'se'
> that I only ever saw there, written somewhere in the Bell System and
> squeezed to run on an -11.  Anyone know anything about it?
>
> Unrelated, Georgia Tech had the 'se' screen editor as part of the
> Software Tools Subsystem, based on the 'ed' in the Software Tools book.
> This was later ported to Unix. I modified that code to use curses/termlib
> and posted it to USENET. It's been updated and is available from
> https://github.com/se-editor/se and http://se-editor.org is the home
> page. (Thomas Cort IIRC did that work.)
>
> What's funny is that in doing the work to get 'se' running on Georgia
> Tech's Vax, I had to learn vi.  By the time I was done, vi had become
> my main editor and had burned itself into my finger's ROMs.
>

Ah, this reminds me of something. I assume you've read, "A Software Tools
Sampler"?

A few months ago, I started looking into screen update algorithms for a
(frivolous) retro-computing time sink, er, I mean project.

Naturally, Gosling's redisplay algorithm figured prominently, as it's
famous and well-known. I looked at the Unix emacs code and it's not that
hard to puzzle through, actually, despite the reputation and the (in)famous
skull and crossbones comment. However, Gosling's code assumes that update
commands all have uniform cost (cost here being proportional to the
command's length) which, on real terminals, just isn't true. Meyers and
Miller came up with several algorithms that take into account editing
command cost, and produce potentially far-better solutions than Gosling's
code, though limited by the inability at the time to quickly build suffix
trees (this was about a decade before Ukkonen's algorithm); it's
interesting that none of these algorithms take into account text
attributes, which on most serial terminals are modal. Anyway, at least one
of these algorithms was implemented in a modified version of `se`, as
described in "A Software Tools Sampler." I guess Webb thought that was
easier to work with than an existing editor? Perhaps these "se"s share a
lineage?

What's interesting to me is that redisplay algorithms were clearly an area
of active research at one time, but  interest seemed to dry up almost over
night. One must presume that this evaporation of research activity had to
do with the en mass migration to graphical workstations where the problems
are different, and possibly with curses being "good enough" in e.g. an
xterm. However, one can see some of the fruits of Miller's research in his
later work in genomics.

        - Dan C.

A few random references:
Gosling, James, "A Redisplay Algorithm."
https://dl.acm.org/doi/10.1145/872730.806463
Meyers, Eugene and Webb Miller, "A Simple Row Replacement Algorithm."
https://dl.acm.org/doi/10.5555/52187.52188
Meyers, Eugene and Webb Miller, "Row Replacement Algorithm for Screen
Editors." https://dl.acm.org/doi/10.1145/59287.59290

[-- Attachment #2: Type: text/html, Size: 4333 bytes --]