Input line editing

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

Quoted drastically out of context (I'm using it as a starting point for
a new thread; that's why I've changed the Subject: and stripped the
References: and In-Reply-To: headers):

> Certainly we can remove command line editing from sh & ksh.

In connection with my recent tech-userlevel note about mail(1), at
least one of the issues raised by which turned out to be because it's
using editline, I was thinking about input line editing.

We've got at least two libraries that do it, each one differently, and
assorted other programs which do it, again, each one differently.  I
was thinking about the possibility of moving all this line editing into
a separate process, which each user could choose (or even write) to
taste and which would handle line editing across all applications,
thereby providing a level of uniformity currently lacking.  I can think
of various potential problems with it; all the ones I've thought of I
believe are solvable, but I haven't thought about it for more than a
few minutes in the foreground plus a few hours in the background.

So - does anyone know of any attempts at something like this?  What
results if so?  If not, does anyone see any problems beyond the ones
below, or see reason to think the ones below aren't as solvable as I
think they are?

* Performance.  Almost by definition, input line editing is for human
input.  Even the slowest NetBSD machine (hp300?) is fast compared to
humans.  (Still, one of the things that would need to be done if this
is looked at for the tree will be performance hit measurements.)

* Per-application differences (perhaps most notably input line
history).  Possible solution: editor process watches the tty process
group.

* Application-specific aspects, such as program- and context-dependent
command/filename completion.  This demands some kind of comm channel
(beyond input lines) between the editor process and the application.
This is easy enough to arrange; the protocol definition will need some
thought and experimentation, but I'm also certain that's not a
showstopper (in technical respects, at least).

* Compatability with existing code, especially third-party code.
Possible solution: stub libraries, which provide the API and ABI of the
existing libraries but are just glue to the new facilities.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B