Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!nrl-cmf!ames!oliveb!sun!gorodish!guy From: guy@gorodish.Sun.COM (Guy Harris) Newsgroups: comp.unix.wizards Subject: Re: Input Line Editing Message-ID: <59768@sun.uucp> Date: 13 Jul 88 23:29:51 GMT References: <16456@brl-adm.ARPA> <9666@eddie.MIT.EDU> <10443@ulysses.homer.nj.att.com> Sender: news@sun.uucp Lines: 73 > > 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? As I read what he said, he was referring to something such as an EMACS window or an Andrew typescript window. I don't know what "the built-in editor on the NeWS windowing system" is (I haven't seen any such editor); were there such an editor in NeWS, I might expect it to resemble those in an EMACS window or an Andrew typescript window, given who wrote 1) one version of UNIX EMACS, 2) a very large chunk of the original Andrew system, and 3) most of NeWS. I assume that the editor on the "layers" system is similar, in concept, to the one in an EMACS or Andrew typescript window, in that it takes what you type and treats them as text to be typed into an editor buffer or as editor commands, and, when you type a, sends the current line as a pre-canonicalized lump to the application, bypassing any "normal" tty driver stuff. Given that, I see an editor such as the one purported to come with NeWS and the one in layers as being precisely what he wanted. > 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 OK, then the aforementioned built-in editors might lose as well if they can't be made to look like EMACS, "vi", or whatever your favorite editor is. I agree that this is a problem, but unless your editor is sufficiently programmable that it can look like any other editor (EMACS may well be this programmable) about all you can do is try to make it possible to use several different flavors of editor for this. I don't see that he required that only *one* such editor exist. > 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. No, not necessarily. If *all* tty-oriented programs are run inside some "virtual terminal" window, be it a layers window, an "xterm" window, a "shelltool" window, a "psterm" window, an "nterm" window, a BSD "window" window, etc., and all of those windows emulate the exact same terminal, you don't need something like termcap or terminfo, since all "terminals" that a regular program would talk to would be the same - they'd never talk to a real terminal. Now, of course, the dumb-terminal windowing programs such as BSD's "window", which support multiple windows on a cursor-addressible terminal by running programs inside pseudo-ttys, treating output written to those pseudo-ttys as requests to update a virtual screen, and displaying those virtual screens (or parts of them) on the physical screen, would probably need something such as "termcap" or "terminfo" to know how to update the physical screen (if it uses "curses" to handle the screen, "curses" then nees "termcap" or "terminfo"). > As for editors, I'd love to see one included in the terminal driver. Gak. *I*'d* love to see all line editing *removed* from the terminal driver, if by that you mean the thing in the kernel that responds to characters arriving over a serial line or pseudo-tty. I'd like to see it done in a program, just as Doug suggested. One advantage of *NOT* doing it in the kernel is that, as you pointed out, not everybody *does* want the same editor; if you put it in the kernel, users can't generally just replace it easily.