Input Line Editing

[Larry DeLuca]

|>oug, 

Your observations about ITS are most astute.  However, they point out the
critical failing of the whole thing -- they require a specific action on
the part of the end user -- if they forget to run the CRTSTY program their
terminal is not supported.

If you want line editing to be available *all* of the time, no matter what,
automatically, the terminal driver is the place to do it.  If the operations
are carefully designed and defined there is no reason that they can't be
mapped to any terminal and any editor the user likes.  If one were to write 
a supplement to getty(8) that would perform the appropriate ioctl(2)'s (or
have getty do the work based on the TERM and EDITOR environment variables --
note here that while the line-editing itself should be in the kernel ALL
the configuration can be done from user-level programs that work with init(8)
and getty(8) -- a user-level program could look up the terminal in termcap(7)
for Berkeley systems and terminfo(4) for System V derivatives to get the 
necessary escape sequences to perform the necessary operations -- an
edicap(7) or similar file could be created to describe various editor keystrokes
such as:

	emacs|jmacs|jove|Jove Editor:\
		up=\^p:dn=\^n:bk=\^b:fw=\^f:

			....

This avoids building excessive intelligence about specific terminals into
the kernel (so that terminals are not uniformly supported, as in the ITS
example) and at the same time avoids redundant information storage (which
can lead to a much harder time tracking down any problems that might arise
-- version skew, broken termcap, and the like).

However, the big win here is that the Operating System and its system
utilities now take care of configuring all this for the user.  If they
want to override it, they may reset the appropriate variables and run
the user program that configures the information again.

					larry...