Input Line Editing

[Doug Alan]

In article <10443 at ulysses.homer.nj.att.com>
cjc at ulysses.homer.nj.att.com (Chris Calabrese[rs]) writes: 

> 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.  [...]

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

I *do* want editing in *every* program (that takes input as command
lines).  If someone else doesn't want editing, they don't have to use
it.  No one is forcing anyone to type the editing control characters.

> 	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

I certainly am not assuming that everyone wants the same line editing.
Anyone should be able to chose whatever program they want to do their
line editing, and the standard program should be configurable.
However, parts of Unix should be redesigned a bit to know that such a
process will be there, and interfaces should be designed and
standardized so that programs that need to, can communicate with the
input editor process, and whatever kernal mods needed should be made
so that the input editor can do things like find out what the current
working directory of the process it's feeding input to is, and
whatever else it needs to do for it to work well.

> 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. :-) :-).

Well, I'm no Xpert, but I believe a lot of the problem with
programming X is that there has not been a standard toolbox.  A lot of
people's experience with programming X has been with the low level
facilities that were initially provided.  I believe that a much higher
level toolbox has or is being standarized that makes it much more of a
pleasure to program.  Regarding performance, I use X for many hours
every day, and its performance is fine.  It's not the fastest thing in
the world, but it is certianly acceptible, and I'm not using an X
whose drivers have been optimized for the hardware.  I've seen
implementations of X that book.  They are running on different
machines, where the drivers have been optimized for the display
hardware.  I don't believe that there is anything inherently
incredibly inefficient in the design of X.  Some implementations just
aren't optimized for their hardware.

Regarding not locking you into X...  Well, then, you better come up
with something better and put it into the public domain.  And you
better do it awfully darn quickly!  Or it will be too late.  Actually,
don't bother -- it's already too late.

|>oug /\lan