Input Line Editing

[Chris Calabrese[rs]]

In article <9666 at eddie.MIT.EDU>, nessus at wonko.mit.edu.UUCP writes:
> 
> 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.

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

> The same is true for output.  This "termcap" stuff is a crock.  There
> should be a process which gets the output from programs, processes it,
> and displays it.  This process should be responsible for managing the
> screen, and keeping track of what is on it for an entire login.  Every
> program having to clear the screen when it is started, so it knows
> what state the screen is in, and having to have this big library
> compiled in, is bogus.  The ITS operating system knew better than this
> decades ago.  It had a decent virtual terminal system.  So did MIT's
> version of Tops-20 (it was in the kernal, however).

Clearing the screen on every invocation???  What about non-interactive
processes???  Or interactive processes getting their input from a
redirect/pipe/socket/stream???  O.K., you probably were referring to
interactive programs.

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.  Actually, if you use curses, the programmer
doesn't have to know about it, and there's no reason not to use shared libraries
for sane performance.

> In fact, X currently does much of this.  It should be made to be more

I hate X!!!!!!!!!  It's the _biggest_ pain in the butt ever invented
for programmers, and it has the performance of pig.  Please don't
lock me into it!   Just my personal opinions of course, but read
comp.windows.news for more info on X bashing. :-) :-).

As for editors, I'd love to see one included in the terminal driver.
Shouldn't be too difficult, the code's already there for ksh - of course,
if it's used only people with AT&T source licences will be able to make
use of the mods, but then, only people with this licence will be able
to install them, anyway.

-- 
	Christopher J. Calabrese
	AT&T Bell Laboratories
	ulysses!cjc