Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!ll-xn!mit-eddie!wonko.mit.edu!nessus From: nessus@wonko.MIT.EDU (Doug Alan) Newsgroups: comp.unix.wizards Subject: Re: Input Line Editing Message-ID: <9671@eddie.MIT.EDU> Date: 13 Jul 88 19:08:32 GMT References: <16456@brl-adm.ARPA> <9666@eddie.MIT.EDU> <10443@ulysses.homer.nj.att.com> Sender: uucp@eddie.MIT.EDU Reply-To: nessus@wonko.MIT.EDU (Doug Alan) Organization: Kate Bush and Butthole Surfers Fandom Center Lines: 60 In article <10443@ulysses.homer.nj.att.com> cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) writes: > In article <9666@eddie.MIT.EDU>, nessus@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