Input Line Editing

[Barry Shein]

I dunno Doug, there's nothing unreasonable about your wish list and I
get the feeling it's all been provided (eg. window in 4.3). Perhaps
you don't love some of the design choices therein but that's a bit
different than saying Unix doesn't have this or that or needs major
changes, the particular solutions just don't seem to have caught on
universally, something to ponder. Maybe the rest of the world is crazy
(my suspicion also, but not based on this particular issue.)

>X already has some input editing, and it certainly doesn't deliver
>"extremely RAW key events" to all of its clients.

Um, it certainly does, it delivers a stream of indices into a key
table and nothing more. Hmm, define "RAW".

>X allows me to cut
>text that is on the screen, and paste it into my input.

X has facilities which allows the programmer to implement this kind of
thing (a stack of addressable cut and paste buffers, which don't have
to contain anything related to key strokes.)

>It allows me
>to remap my keyboard.

It "allows" you (ie. provides the facilities to...) pass the keymap
indices through a mapping table (an associative array, basically.)
Nothing you couldn't do with a simple case statement other than
providing some standard way to set up mappings for largish maps.  It's
sort of like saying Unix "allows" me to ask for sin(.3456), yeah, so
what?

>Is this "raw" key events?

Yes, I think so, it delivers simple indices to the client and has a
facility to optionally pass them through a translation table. Does the
fact that Unix has a toupper() macro mean that Unix only supports
upper-case? I'm not sure I see your point (or, I think you are
confused as to what X "delivers" and what can be further done with
some programming.)

>And indeed, these
>input procressing capabilities should be expanded.  Full line-editing
>should be added.

Have you looked at the text widget in the toolbox? It seems to provide
full emacs-like editing (or certainly makes a sincere effort to.)

You're not making it clear at what level this should be added. Should
it be in the client? The server? The application library? The toolkit?
The network protocol? All are possible and various other systems have
done this kind of thing at least once, not all have been a raving
success tho most are interesting to look at.

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

Ok, fine, there's a design proposal. It wouldn't be very hard to
implement in xterm or as a library/toolkit call that xterm could use.
Probably an afternoon's programming (actually, probably less, you
could just cobble the text widget as a popup or something, and access
the scroll history xterm already keeps.)

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

or you could probably add a lisp support routine (18.51 already has
X11 support, so this isn't that glib) which allows you to bind a
zap-to-cut-buffer to a keystroke or some such, and the other end of
that to xterm (which is already there, you just seem to dislike the
motions needed from your hands to select it, it probably wouldn't be
that hard to eliminate all motions, or check the cut buffer for new
input when you hit newline or something like that, you could also have
it require no motions on the xterm end although information theory
still begs for an answer to what to do when you have more than one
xterm running.)

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

What does this mean? Are you proposing prescient software? The
application has to do *something* to give the display server a hint
that it wants, eg, the screen cleared. In X the basic thing is to call
XClearWindow(), or if running in xterm to send a vt100 escape sequence
in the ASCII stream. What exactly do you want that this isn't?

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

Xterm has this more or less (pardon me), or it could be trivially
added.  Sunview certainly has it, I've found it variously a plus or a
minus, fortunately you can turn it on or off at will, I've usually had
it off with rare exceptions for some reason.

>> 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 "most of the time" was what I was bracing myself for, as I suspected.

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

NO! The RIGHT way to do this is to SOLVE the problem CORRECTLY!

That was sarcasm, do you see any more information content in your
suggestion than my obnoxious remark? HOW do you "devise and
standardize...", you sound like you're running for political office,
not proposing designs.

	-Barry Shein, Boston University

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

No, this doesn't belong in the open call, applications can (and
certainly have been know to, see tip for example) implement this
easily enough with the existing terrain. If it were an atomic
primitive it would cause all sorts of problems and loss of ability to
control intervening things (like setting up to handle interrupts and
process groups to envelope the subprocesses, and manage errors, what
should open() return if one of those commands didn't exist or was
typo'd? "EFUKTUP: SOMETHING has gone wrong", the current method would
tell the programmer exactly what was wrong trivially. Analyzing the
possible errors is a critical part of design.