Re: Input line editing

["Steven M. Bellovin" <smb%cs.columbia.edu@localhost>]

On Wed, 11 Feb 2009 20:08:36 -0500 (EST)
der Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

> 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.
> 
This was some of Rob Pike's motivation for how the terminal windows
worked on the Blit.  I think there was a Usenix paper on it, but I'd
have to check further on that.


                --Steve Bellovin, http://www.cs.columbia.edu/~smb