Input Line Editing

[Doug Alan]

> From: tytso at athena.mit.edu (Theodore Y. Ts'o)

> One problem with putting the input line editor (ile) where it is is
> that you don't always want to be able to step back through ALL the
> lines that were typed to that tty.  For example, if you started
> editing a file using /bin/ed (or some other interactive program),
> and typed hundreds of "n", "p", "i", "a", and "s/foo/bar/" commands,
> when you exited to the shell, do you really want to step through
> those hundreds of /bin/ed commands?  The shell isn't going to do
> anything useful with them.  Want I want to do is step back to the
> last *shell* commands, not necesarilly the last line I typed.

Well, that doesn't mean that "ile" is in the wrong place.  "Ile" is in
the right place.  What it means is that "ile" should be made smarter
for your use.  It should keep track of what programs you fire up and
allow you to keep a seperate history buffer for each program.  (If
this can't be done efficiently because of the kernal doesn't support
this well, then the kernal should be made to support it.)

> Now, you might say that this is a "inconsistent user interface".
> But I find that having the shell step through only shell commands is
> a lot more friendlier to the user.  I use a csh with a line editor
> hacked in, and I've been very satisified with the result.  This is
> the csh which is in use at MIT Project Athena, and our users in
> general like it a lot.

Putting line editing seperately into every program in the world in
just plain wrong.  Users like the Athena's C-shell because they don't
have anything better.  I use Athena's C-shell because I don't have
anything better.  That doesn't mean that it is done right.  (I'm
considering using "ile" instead, but it has its own problems).

> From: henrik at blblbl.UUCP (Larry DeLuca)

> While it's not going to help the ile people much, it still seems the
> best place for a line editor of some sort is still the tty driver
> (ioctl's can be used to set characters or toggle between modes).

No, you're wrong.

> The most simple line editing commands (rubout, line delete, and co.)
> are there already, and it is the only way to guarantee that they
> will be uniformly supported.

There is another way to guarantee that line editing will be uniformly
supported.  (1) Provide an alternate, and better method.  (See my and
some other's previous articles on the issue).  (2) Remove line editing
completely from the kernal, forcing everyone to use the better method.

> The major complication, of course, is that this requires
> intelligence in the tty driver about terminal escape sequences.  ITS
> (Incompatible Time Sharing, developed at MIT) has excellent support
> in this regard (the tty driver knows how to do operations like clear
> the screen, and is also aware of what's on the screen at any given
> time, so can repaint it after a send, for example).

The problem with this is that the ITS kernal knows about certain
terminal types.  If you don't have one of these terminal types, you
have to run a program which knows about your terminal type and
emulates one of the known terminal types, making your terminal look to
every other program like one of the known terminal types.  Why not
forget the part about the kernal knowing about certain terminal types,
and keep the smart and general idea: having a process that makes all
terminals look alike to other programs?

|>oug /\lan

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