Input Line Editing

Guy Harris guy at gorodish.Sun.COM
Thu Jul 14 03:29:27 AEST 1988


> Putting line editing in the shell is wrong, because it should work in
> all programs and be consistent.  Putting it in the kernal is gross.
> Thus, the right place to put it is precisely where Bob Pendleton wants
> to put it -- in a process which gets input from the user and feeds
> edited input to the user's other programs.  If needed, mods to the
> kernal and convention, however, should be made to make this as easy
> and efficient as possible.

Yes.  You can almost do what you want with EMACS; the problem is that EMACS has
no way of finding out about "ioctl"s done on the tty, so it can't do the moral
equivalent of turning off echoing or canonicalization.

> In fact, X currently does much of this.  It should be made to be more
> well-integrated, however.  Every program should know about X, so no
> program has to worry about managing the screen on its own.  Perhaps X
> should have input line editing added to it.

Huh?  What do you mean by "X"?  If you're referring to the server for the X11
Window System, it should definitely *not* "have line editing added to it."  The
X11 server is supposed to deliver extremely RAW key events to its clients, so
that the clients aren't obliged to undo any "intelligence" that the server
adds.  What if the client *isn't* using the keyboard as a "normal"
terminal-style keyboard?

It would be nice to have, say, an Xt widget that performed the same function as
an EMACS shell window or an Andrew shell window; there may well already be such
a beast.  The underlying editor code used by this could be the same as the
editing code used by other widgets, such as a "text field" widget, or should at
least provide the same general sort of behavior.

As for "every program should know about X", well, "cat" shouldn't know about X;
it should only know about writing output to a file descriptor.  The file
descriptor goes to a pseudo-terminal (or moral equivalent); the output goes to
an X11 client program, which displays it on the screen by sending requests to
the X11 server.  "cat" doesn't know about X; "xterm" does.

> There should also be a version of X that runs in a limitted form, but
> supports the most basic features, on a normal, dumb terminal, so you
> don't *have* to have a workstation to use programs that don't need
> one.

One of the "most basic features" of X11 is the ability to draw things such as
lines, and curves, and so on and so forth, with pixel-level resolution.  I
would be very surprised to hear about *ANY* X11 client that could live with the
minimum set of X11 requests that could be implemented on a "dumb terminal", if
by that you mean a 24x80 ASCII terminal with a positionable cursor.  To be
specific, I doubt you'd be able to run "xterm" - a program that emulates a
"dumb terminal" - on this mythical "X on a VT100" that people periodically
request.

Another way of putting this is that I know of no X11 client program that
"doesn't need a workstation" or, at least, doesn't need a bit-mapped display
terminal with a pointing device.  If there is such a beast, it's an exception.



More information about the Comp.unix.wizards mailing list