Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!ulysses!cjc From: cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) Newsgroups: comp.unix.wizards Subject: Re: Input Line Editing Summary: Terminal Religion Message-ID: <10443@ulysses.homer.nj.att.com> Date: 13 Jul 88 16:45:04 GMT References: <16456@brl-adm.ARPA> <9666@eddie.MIT.EDU> Organization: AT&T Bell Laboratories, Murray Hill Lines: 60 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. If needed, mods to the > kernal and convention, however, should be made to make this as easy > and efficient as possible. 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? 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 > The same is true for output. This "termcap" stuff is a crock. There > should be a process which gets the output from programs, processes it, > and displays it. This process should be responsible for managing the > screen, and keeping track of what is on it for an entire login. Every > program having to clear the screen when it is started, so it knows > what state the screen is in, and having to have this big library > compiled in, is bogus. The ITS operating system knew better than this > decades ago. It had a decent virtual terminal system. So did MIT's > version of Tops-20 (it was in the kernal, however). Clearing the screen on every invocation??? What about non-interactive processes??? Or interactive processes getting their input from a redirect/pipe/socket/stream??? O.K., you probably were referring to interactive programs. It is reasonable to have virtural terminal handling done in a seperate process (NeWS, layers, X), or within the process (curses, TAM (developed for the AT&T 3b1 - O.K. it's not made anymore, but with shared memory libraries, TAM _way_ outperforms curses, and is much easier to use)). Either way, however, something like termcap or terminfo will have to be used, even if the programmer doesn't have to know about it. Actually, if you use curses, the programmer doesn't have to know about it, and there's no reason not to use shared libraries for sane performance. > In fact, X currently does much of this. It should be made to be more 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. :-) :-). As for editors, I'd love to see one included in the terminal driver. Shouldn't be too difficult, the code's already there for ksh - of course, if it's used only people with AT&T source licences will be able to make use of the mods, but then, only people with this licence will be able to install them, anyway. -- Christopher J. Calabrese AT&T Bell Laboratories ulysses!cjc