Input Line Editing

[Doug Alan]

>> [nessus at eddie.mit.edu:] 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.

> [guy at gorodish.Sun.COM (Guy Harris):] 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.

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.

In any case, I don't want to get into an argument of what X is and
isn't.  I just want to say how I think things should be: As I already
said (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).  (3) The programs which implement these input and
output processing facilities should be selectable by the user.  (4)
There should be a means of and protocol for communication between a
program and these input and output processing processes.  (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. (6)
The X window system already does some of the above stuff, and the rest
could be added.  (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.

> 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?  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.

In fact, you can already do something like this with X, but it's a
real pain.  If you wanted to, you could type all your input into
Emacs, and use the cut and paste utilities to get all your keyboard
input from Emacs to the program you are using.  This isn't worth the
bother, however.

> What if the client *isn't* using the keyboard as a "normal"
> terminal-style keyboard?

Then the application should be able to able to tell X, "hey, please
give me my input rarer", in a manner similar to that which allows a
normal Unix application to request input in "raw" or "cooked" mode.

> 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.

Perhaps I worded things a bit poorly.  Certainly programs that don't
want to do anything fancy with the display, need not know anything
about X.  I meant to say that any program that wants to do anything
fancy with the display (such as clear the screen, move the cursor,
etc) should not do it itself.  It should know that there is a display
manager to do these sorts of things for it, and it should communicate
with the display manager using some prescribed protocol.

There should not be any programs such as "more" or "less".  All the
functionality of these programs should be built into the display
manager.

> From: bzs at bu-cs.BU.EDU (Barry Shein)

> [...] The other question is, if [input line editing is] done as an
> intermediate process how does the process know when to step out of
> the way because a newly started job is doing its own style of input
> editing? (yes, I'm bracing myself for the answer...)

Well, recently posted to Unix-Wizards was "ile" -- "input line
editor".  Ile seems to handle this by getting out of the way if any
process below it puts the terminal in cbreak or raw mode.  This seems
to work most of the time, but not all of the time.

The right way to do this is to devise and standardize a convention and
means for communicating and coordinating this sort of thing between
processes.

|>oug /\lan

   (or nessus at athena.mit.edu
       nessus at mit-eddie.uucp)


P.S. While we're on the subject of changing Unix, the system call that
opens files should also be changed.  It should be changed so that
wherever you can specify a file to run, you can also specify a
pipeline to run and use as a source of input or output.  For example,
if a program prompts me like so:

	Enter output file:

I should be able to enter something like:

	Enter output file: ^(filter1 | justify -80 | tee \
			   ^(filter2 | justify -40 > output-file2) \
			    > output-file1)


The output would get filtered through filter1, justified to 80
columns, and output to "output-file1".  Another copy of the output
would get filtered through filter2, justified to 40 colums, and output
to "output-file2".