Input Line Editing

[Bob Pendleton]

>From article <377 at uport.UUCP>, by plocher at uport.UUCP (John Plocher):
>> In article <6339 at bloom-beacon.MIT.EDU> Theodore Y. Ts'o writes:
>>> putting the line editor in the shell is the right thing to do.
>> 
>> I've found all three methods (in shell, in kernel, in program) to
>> be useful at different times.  For the *few* programs that need
>> special editing (pre-selected defaults, interactive command driven things,
>> etc) a simple library call to an edit_gets() solves many problems
>> without making anyone else's programs pay for the feature.
>> 
>> For most of the other interactive editing I do, the shell (ksh) editing
>> features meet my needs.  If you think about it, the shell has its own set
>> of library calls to do line editing, so there are only 2 methods :-)
>> 
>> The normal editing that the tty driver does is often enough for
>> the programs which don't need the complex editing features outlined
>> by other posters here.

The idea is to provide the USER with a consistent interface. I
personally could care less about the needs of a program. I don't want
my fingers to have to remember which program I'm running when I want
to delete a word or whatever from the line I've just typed. Postnews
doesn't NEED a delete previous word editing command, but it is sure
nice to have from my point of view.

I don't want to have to learn the intricacies of the configuration
file formats of a dozen different programs. I would like to be able to
define my key bindings in one place and have every program give me
some reasonable approximation of the bindings I've specified.

I will admit that ile uses a lot of machine resourses, but it saves me
a lot of time and frustration every day of my life. If you haven't tried
it, you don't know what you are missing. It means that there is one
less thing that I have to keep in mind when I'm using programs that
don't give distinct visual ques about the kind of input that is
expected. One less thing to distract me from what I'm really trying to do.

>> Like most things in the Real World, there isn't always one Right Thing.

Absolutely! And I don't think we are anywhere near even identifying
what the right thing is. Where is the right place to put input line
editing? So far I've heard only a few proposals, most of them being
the way its always been done.

1) in the shell. 
2) in an input editing library.
3) in a separate process.
4) in a streams module. (equivalent to 3?)
5) in a terminal emulator.
6) in the kernel (device driver or line discipline).

What about

7) in a window manager.
8) in a window server (add it into X). Similar to 2 but consistent
across applications.

Where else can you put it? It would seem that it has to be done
somewhere in the path that leads from the keyboard to the program. What
are the advantages/disadvantages of putting it in each of these
places? If it should be a separate process, where in the path should
that process be placed?

		Bob P.
-- 
Bob Pendleton @ Evans & Sutherland
UUCP Address:  {decvax,ucbvax,allegra}!decwrl!esunix!bpendlet
Alternate:     utah-cs!esunix!bpendlet
        I am solely responsible for what I say.