[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Input line editing
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
> 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
> * 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
Main Index |
Thread Index |