Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.emacs
Subject: Re: Wanted: minimal EMACS in C
Message-ID: <1310@auspex.UUCP>
Date: 28 Mar 89 00:50:15 GMT
References: <4822@tekgvs.LABS.TEK.COM> <KGK.89Mar26211458@bimini.cs.brown.edu>
Reply-To: guy@auspex.UUCP (Guy Harris)
Distribution: comp
Organization: Auspex Systems, Santa Clara
Lines: 69

>Version 8 or version 9 Unix is supposed to have had some sort of
>streams mechanism.

Yes, it did - or does (I don't know if the Tenth Edition of the manual
is out yet or not).  So does System V Release 3, although it doesn't use
streams for all its terminals.  SunOS has the S5R3 streams mechanism,
and *does* use it for all its terminals.

>Does anybody know if it's possible to put an input editor filter over a
>terminal I/O stream (or dynamically merge input editor capability into
>an I/O stream, as may be the case)?

Well, it depends.  The standard "tty driver" line disciplines or streams
modules *do* include an input editor; it just happens to be an extremely
*primitive* input editor, that supports only commands such as "delete
last character of line", "delete entire line", and "delete last
space-separated token on the line" in some cases.

Putting a more powerful editor below that module on a stream makes that
editor incapable of using the facilities (input and output mapping of
various sorts, for instance) that the "tty driver" module provides; it
also means that it would have to know about the existing editor on the
module above.  Putting it above the "tty driver" module might work
better, although it'd have to make sure that module stayed in "uncooked"
mode and didn't do its own editing of input. 

Of course, you can, if you really want, put a fancier input editor into
a system that *doesn't* use streams, as long as you have enough
information to enable you to write a line discipline to replace the
standard one.

>I guess a quick answer would be ``Why would they develop ksh if they
>could do that?'',

Because:

	1) there's a lot more to "ksh" than just input line editing;

	2) "ksh" works on systems that *don't* support streams;

and, perhaps most important, or more germane,

	3) putting an editor such as that into the kernel might not be
	   the best idea.

The idea "let's make a streams module that does command-line editing"
seems to occur to a lot of people when they hear about streams.  It
sounds great; the down side is that, since streams modules run in the
kernel, the editor in question would run in kernel mode, which:

	1) puts it in an environment often much less hospitable to it;

	2) often requires root privilege to replace the editor;

	3) often requires a *reboot* to replace the editor;

	4) adds a fair bit of both code and policy to the kernel.

Me, I'd prefer to take the current level of editing *out* of the kernel,
and *out* of the tty driver, and run some more powerful editor such as
EMACS in user mode in its place.  A reasonable pseudo-tty mechanism lets
you do that; you can even do it with a less-than-wonderful pseudo-tty
mechanism such as exists in many contemporary UNIXes - one problem with
the current mechanism is that it can't detect "ioctl"s done on the
pseudo-tty, so that your editor can't figure out that a program running
from the pseudo-tty has turned echoing or input canonicalization off and
act appropriately - some systems sort of let you do this, but the
mechanism isn't reliable.  S5R4's pseudo-tty mechanism will probably fix
this.