Input Line Editing

[Guy Harris]

> Perhaps you (and perhaps the people who wrote X) consider this one of
> the most basic features.  I don't, however.  I consider the most basic
> features to be those that allow me to manage multiple text windows,
> not all of which have to be visible, but all of which can contain
> running programs creating output.

Who said anything about "text windows"?  That sounds like a feature of "xterm",
not X in its entirety.  I very much expect that the people who wrote the X
server didn't think of it as something to "manage multiple text windows"; it's
the job of X clients to do text windows.  X just lets you draw on drawing
surfaces, and there are lots of X clients that *don't* just draw text on those
drawing surfaces.

X is not "xterm".  I suspect a lot of the cries for "an X for my VT100" come
from people who reall wants multiple text windows, and think of X as "xterm",
i.e.  something that implements text windows.  This means that instead of
asking for what they really want - "how can I get multiple text windows on my
VT100" - they ask for some particular *mechanism* for getting multiple text
windows on their VT100, namely "is there an X server for a VT100?"

If they *had* asked for multiple text windows on their VT100, people could
point them at the 4.3BSD "window" program or any one of a number of programs
that provide what they want, instead of asking for some chimerical "dumb
terminal X server".

> (1) I think there should an input preprocessing facility that
> provides input line editing for all programs that accept their input
> as lines of text.  (2) There should be an output processing facility
> so that programs like "more" and "less" are not required.  All the
> capabilities of these programs should be in the output processing
> facility.  The output processing facility should also handle doing
> anything fancy with the display (such as clearing the screen. moving
> the cursor, etc).

What you want here is something that runs off your real terminal, or as a
window-system client, and uses one or more pseudo-ttys to emulate one or more
virtual terminals.  It would also do paging (the Sun "shelltool", for example,
can do this) and fancy input line editing (EMACS and the Andrew typescript
program can do this).  They would also have to be able to run in a mode where
they can handle "full-screen" types of things (such as clearing the screen,
moving the cursor, etc.); it may be possible to do this in their standard mode.

I don't know if there is any program that does *all* of this, but I don't see
why one couldn't be written.

> (3) The programs which implement these input and output processing
> facilities should be selectable by the user.

No problem.  On a dumb terminal, you start the program up when you log in; it
takes over your physical terminal and provides one or more virtual terminals
using pseudo-ttys.  Under a window system, you just fire up one of these
programs when you want a tty window.

> (4) There should be a means of and protocol for communication between a
> program and these input and output processing processes.

Since programs that want these facilities tend to be run from terminals, a
pseudo-tty type mechanism provides this.  The "protocol" would just be a
bi-directional byte stream, similar to the byte stream that runs over the wire
between a host and an intelligent terminal.

> (5) Some kernal mods may be necessary to make this scheme simple
> and efficient.  For example, the input editor needs to be able to find out
> the current working directory of the process to which it is sending the
> input.

Maybe.  Unfortunately, telling the input editor about the current working
directory of the process to which it is sending the input would be unlikely to
be simple, although it might conceivably be efficient.  (If you think it's
simple, show a simple design for it and show that a simple implementation is
possible.  Note that there may be several processes equipped to read from
the terminal, and the input editor will not know to which process it's sending
the input until the process actually tries to read its input.)

> (6) The X window system already does some of the above stuff, and the
> rest could be added.

A certain *component* of the X window system, namely "xterm", already does some
of the above stuff.  It does so because it's a terminal emulator, not because
it's a part of X.  Therefore, you can do it outside of X about as easily (or
maybe even more easily).

> (7) There should also be a standard set of programs for normal 24x80 dumb
> terminals (let's call the programs "X--") that do window management, and
> input and output processing of the sort talked about above.

"Let's call the programs 'X--'"?  Let's not, and say we did.  The program would
bear a closer relationship to "xterm" than to the X server; you wouldn't be
able to run X programs under it, but you would be able to run the same sorts
of programs you run under "xterm" under it as well (unless they use some
graphics feature "xterm" provides, but that this windowing program couldn't
provide on a dumb terminal, such as Tektronix graphics terminal emulation).

> > 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.
> X already has some input editing, and it certainly doesn't deliver
> "extremely RAW key events" to all of its clients.  X allows me to cut text
> that is on the screen, and paste it into my input.  It allows me to remap my
> keyboard.  Is this "raw" key events?

You bet it is!  I said that the server *does* deliver extremely RAW key events
to its clients, and I stick by that claim 100%.  The *clients* handle the
cut-and-paste stuff, and the remapping; they interpret the "key 27 went down"
events as meaning "the user hit the 'a' key, insert an 'a' into the document at
this point" or the "key 13 went down" event as meaning "past the current cut
buffer into the input.

> And indeed, these input procressing capabilities should be expanded.  Full
> line-editing should be added.  For example, at the bottom of every window
> that accepts input, there could be a little one-line Emacs window (or your
> choice of editor) that allows you to edit the current line (or recall
> a previous line and edit it) and send it to the application when you
> are finished with it.

What if your window doesn't know anything about lines?  What if it just puts up
a form you fill in, and buttons you push, and sliders you move, and...?

Again, this input editing belongs in the *client*, not the *server*.  When I
say "client" here, I mean X client, and when I say "server", I mean X server.
X consists of several components.  The server accepts connections from
clients, gets requests to do things such as create windows and paint things in
them over those connections, and sends input events from keyboards, mice, etc.
back to the clients over those connections.

Clients are programs such as "xterm", font editors, spreadsheet programs,
drawing programs, etc., etc., etc..  Those programs open a connection to the X
server, and create windows and draw things by sending them requests over that
connection.  They get their "marching orders" from the user over this
connection, in the form of very raw keyboard events ("key 27 went down", "key
27 went up", "key 31 went down", etc.) and mouse events.

"xterm" is such a client; it might interpret "key 27 went down" as "the user
hit the 'a' key" and send an "a" over its pseudo-terminal.  It also interprets
requests that come over the pseudo-terminal; the request with the byte code
octal 141 means "paint an 'a' at the current position on the screen", and sends
a request to the X server to do so.

In this sense, "xterm" is both a client and a server.  It is a client of the
X server; it is a server for the programs that are connected to its
pseudo-terminal.

In the same sense, the microprocessor in a typical "plain" terminal is running
a program that's a server, connected to its clients over, say, an RS-232 cable;
when you print "a", a byte with the code octal 141 is sent over the cable, and
when the program in the terminal receives this code it tells the display
hardware to put up an "a" on the screen at the current position.  When it is
told by the keyboard hardware that key 27 went down, it sends an "a" back over
the wire.  (Thus, the relationship between the terminal's firmware and its
keyboard and display hardware is pretty much the same as the relationship
between "xterm" and the X server.)

Similarly, you can implement a program that acts as a server in a fashion
similar to "xterm" or the firmware in a terminal; it uses pseudo-ttys in the
same way "xterm" does, to talk to its clients, and it acts as a client to a
"plain" terminal that it has open.  In fact, people *have* implemented
programs such as this, EMACS being one and the 4.3BSD "window" program being
another.

Given this model, you can see that "putting line editing in X" should not mean
putting it into the X server, it should mean putting it into clients such as
"xterm".  Furthermore, given that, you can see that the same functionality
could be put into a "plain terminal" windowing program - or even into the
firmware of a terminal!  A block-mode terminal has some of that functionality;
a Bell Labs Blit, or any of its successors, has lots more of it, since you can
download programs to it.

In other words, as I indicated above, there's really nothing particular about X
that lets you do line editing in a program of the sort you describe.  You can
put the line editing into any sort of "terminal firmware" program, regardless
of whether the "firmware" is running on a 68000 inside a Blit terminal, on a
general-purpose computer as part of a "plain terminal" window program, on a
general-purpose computer as part of "xterm" - or any other terminal emulator on
any other window system.

However, you also notice another thing:  if you put line-editing in "xterm",
then programs *that read from a terminal, and that are run inside an "xterm"*,
could make use of this facility.  However, not all programs will be run this
way.  Some programs will talk directly to the X server; they may not even have
the notion that their text input is broken up into lines (which makes doing
line-editing a bit tricky...).

Now, if you're just a user of X, a lot of the careful distinctions listed above
really aren't important.  However, if you want to discuss not only what
capabilities you want (e.g., line editing), but *how to implement them*, you're
no longer just a user and, when discussing implementation issues, can't
reasonably think only as a user; you really have to understand some of how it
all works.