Path: utzoo!attcan!uunet!lll-winken!lll-tis!oodis01!uplherc!esunix!bpendlet From: bpendlet@esunix.UUCP (Bob Pendleton) Newsgroups: comp.unix.wizards Subject: Re: Input Line Editing Message-ID: <926@esunix.UUCP> Date: 26 Jul 88 15:19:27 GMT References: <377@uport.UUCP> Organization: Evans & Sutherland, Salt Lake City, Utah Lines: 68 >From article <377@uport.UUCP>, by plocher@uport.UUCP (John Plocher): >> In article <6339@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.