Input Line Editing

[Eirik Fuller]

In article <9677 at eddie.MIT.EDU> nessus at wonko.MIT.EDU (Doug Alan) writes:
>> From: tytso at athena.mit.edu (Theodore Y. Ts'o)
>> ...
>
>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.)

Ok, your line editor is going to know all about execing programs.
Swell.  In what sense won't it be a shell?  It's starting to sound to
me like you're really saying that shells that only let you edit their
own command history and not the input to the programs they exec don't
have full fledged input editing capabilities.

I realize that there are wrinkles to be ironed out in building a
shell that lets you edit input to the programs it execs.  The worst
of these wrinkles are not improved by separating the editor from the
shell.  I presume the best way to build a layer between the
shell-editor and its child processes is for it to use a pty for each
of them.

Gee, this fictional shell-editor is beginning to sound more and more
like a window manager.  Why not just build an editor into xterm?  A
knowledgable user would guess which commands need which types of
windows; pipelines, background jobs, and generally anything that
doesn't need tty input could go into write only windows; editors and
such could go into raw-mode windows, and things like debuggers and
ftp could go into editor windows.  Not that you need workstation
graphics to make a shell-editor useful ...