Path: utzoo!attcan!uunet!husc6!mailrus!utah-gr!utah-cs!cs.utexas.edu!sm.unisys.com!ism780c!mikep
From: mikep@ism780c.isc.com (Michael A. Petonic)
Newsgroups: comp.unix.wizards
Subject: Re: Input Line Editing
Message-ID: <12184@ism780c.isc.com>
Date: 21 Jul 88 01:03:25 GMT
References: <16541@brl-adm.ARPA>
Reply-To: mikep@ism780c.UUCP (Michael A. Petonic)
Organization: Interactive Systems Corp., Santa Monica CA
Lines: 32

In article <16541@brl-adm.ARPA> rbj@nav.icst.nbs.gov (Root Boy Jim) writes:
 >? From: Guy Harris <guy@gorodish.sun.com>
 >? > As for editors, I'd love to see one included in the terminal driver.
 >? One advantage of *NOT* doing it in the kernel is that, as you
 >? pointed out, not everybody *does* want the same editor; if you put
 >? it in the kernel, users can't generally just replace it easily.
 >
 >One way arount that is via the bind command. Make the editing primitives
 >`suffifiently general', and let the user bind funtion keys to the appropriate
 >funtions. Command files to bind commonly used editing sets could be placed
 >in /usr/pub (it's about time something else was put there :-).
 >
 >I don't know much about streams, but perhaps that's the way to go.

Yeah, I'd have to agree.  Perhaps there could be a general streams
module for general editing functions that you could pop on top of
a (streams, of course) tty driver.  And if Emacs and Vi are popular,
have two dedicated streams modules for those editors.  The general editing
function editor could be used for all other editors, with an IOCTL required
to set up the bindings, before you use it.

One disadvantage is having the streams tty driver.  There are a couple
of stream modules ("ntty" and "ld0") that implement network tty
and line discipline 0, but it's really slow compared to the standard
tty driver.  Plus, I think the ld0 module isn't quite as stable
as the stardard tty driver.  

Speed isn't much of a consideration in data comming from the
tty to the process, but the other way around, speed becomes very
important.

-MikeP