Input Line Editing

[Guy Harris]

> > 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.
> 
> You are assuming that
> 	a) _everyone_ wants line editing in _every_ program
> 		what about the built in editors on the
> 		layers and NeWS windowing systems?

As I read what he said, he was referring to something such as an EMACS window
or an Andrew typescript window.

I don't know what "the built-in editor on the NeWS windowing system" is (I
haven't seen any such editor); were there such an editor in NeWS, I might
expect it to resemble those in an EMACS window or an Andrew typescript window,
given who wrote 1) one version of UNIX EMACS, 2) a very large chunk of the
original Andrew system, and 3) most of NeWS.

I assume that the editor on the "layers" system is similar, in concept, to the
one in an EMACS or Andrew typescript window, in that it takes what you type and
treats them as text to be typed into an editor buffer or as editor commands,
and, when you type a <RETURN>, sends the current line as a pre-canonicalized
lump to the application, bypassing any "normal" tty driver stuff.

Given that, I see an editor such as the one purported to come with NeWS and the
one in layers as being precisely what he wanted.

> 	b) _everyone_ wants the same line editing
> 		I use vi, but that's only because I'm used to it
> 		after a few years.  Most people want modeless editing

OK, then the aforementioned built-in editors might lose as well if they can't
be made to look like EMACS, "vi", or whatever your favorite editor is.  I agree
that this is a problem, but unless your editor is sufficiently programmable
that it can look like any other editor (EMACS may well be this programmable)
about all you can do is try to make it possible to use several different
flavors of editor for this.  I don't see that he required that only *one* such
editor exist.

> It is reasonable to have virtural terminal handling
> done in a seperate process (NeWS, layers, X), or within the
> process (curses, TAM (developed for the AT&T 3b1 - O.K. it's not
> made anymore, but with shared memory libraries, TAM _way_ outperforms
> curses, and is much easier to use)).  Either way, however, something
> like termcap or terminfo will have to be used, even if the programmer
> doesn't have to know about it.

No, not necessarily.  If *all* tty-oriented programs are run inside some
"virtual terminal" window, be it a layers window, an "xterm" window, a
"shelltool" window, a "psterm" window, an "nterm" window, a BSD "window"
window, etc., and all of those windows emulate the exact same terminal, you
don't need something like termcap or terminfo, since all "terminals" that a
regular program would talk to would be the same - they'd never talk to a real
terminal.

Now, of course, the dumb-terminal windowing programs such as BSD's "window",
which support multiple windows on a cursor-addressible terminal by running
programs inside pseudo-ttys, treating output written to those pseudo-ttys as
requests to update a virtual screen, and displaying those virtual screens (or
parts of them) on the physical screen, would probably need something such as
"termcap" or "terminfo" to know how to update the physical screen (if it uses
"curses" to handle the screen, "curses" then nees "termcap" or "terminfo").

> As for editors, I'd love to see one included in the terminal driver.

Gak.  *I*'d* love to see all line editing *removed* from the terminal driver,
if by that you mean the thing in the kernel that responds to characters
arriving over a serial line or pseudo-tty.  I'd like to see it done in a
program, just as Doug suggested.

One advantage of *NOT* doing it in the kernel is that, as you pointed out, not
everybody *does* want the same editor; if you put it in the kernel, users can't
generally just replace it easily.