nessus@wonko.MIT.EDU (Doug Alan) (07/13/88)
In article <16456@brl-adm.ARPA> rbj@nav.icst.nbs.gov (Root Boy Jim) writes: > I suspect that the real place for line editing is either in the shell > itsef (as in tcsh, ksh, (and brlsh?)) or in the kernel. 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. 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). In fact, X currently does much of this. It should be made to be more well-integrated, however. Every program should know about X, so no program has to worry about managing the screen on its own. Perhaps X should have input line editing added to it. Every window could have an input editing sub-window, where the user would type and edit his input. In fact, this is just what Apollo's do, now that I think of it. Darn, they thought of it first! There should also be a version of X that runs in a limitted form, but supports the most basic features, on a normal, dumb terminal, so you don't *have* to have a workstation to use programs that don't need one. |>oug /\lan
cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) (07/13/88)
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
guy@gorodish.Sun.COM (Guy Harris) (07/14/88)
> 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. Yes. You can almost do what you want with EMACS; the problem is that EMACS has no way of finding out about "ioctl"s done on the tty, so it can't do the moral equivalent of turning off echoing or canonicalization. > In fact, X currently does much of this. It should be made to be more > well-integrated, however. Every program should know about X, so no > program has to worry about managing the screen on its own. Perhaps X > should have input line editing added to it. Huh? What do you mean by "X"? If you're referring to the server for the X11 Window System, it should definitely *not* "have line editing added to it." The X11 server is supposed to deliver extremely RAW key events to its clients, so that the clients aren't obliged to undo any "intelligence" that the server adds. What if the client *isn't* using the keyboard as a "normal" terminal-style keyboard? It would be nice to have, say, an Xt widget that performed the same function as an EMACS shell window or an Andrew shell window; there may well already be such a beast. The underlying editor code used by this could be the same as the editing code used by other widgets, such as a "text field" widget, or should at least provide the same general sort of behavior. As for "every program should know about X", well, "cat" shouldn't know about X; it should only know about writing output to a file descriptor. The file descriptor goes to a pseudo-terminal (or moral equivalent); the output goes to an X11 client program, which displays it on the screen by sending requests to the X11 server. "cat" doesn't know about X; "xterm" does. > There should also be a version of X that runs in a limitted form, but > supports the most basic features, on a normal, dumb terminal, so you > don't *have* to have a workstation to use programs that don't need > one. One of the "most basic features" of X11 is the ability to draw things such as lines, and curves, and so on and so forth, with pixel-level resolution. I would be very surprised to hear about *ANY* X11 client that could live with the minimum set of X11 requests that could be implemented on a "dumb terminal", if by that you mean a 24x80 ASCII terminal with a positionable cursor. To be specific, I doubt you'd be able to run "xterm" - a program that emulates a "dumb terminal" - on this mythical "X on a VT100" that people periodically request. Another way of putting this is that I know of no X11 client program that "doesn't need a workstation" or, at least, doesn't need a bit-mapped display terminal with a pointing device. If there is such a beast, it's an exception.
nessus@wonko.MIT.EDU (Doug Alan) (07/14/88)
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
bzs@bu-cs.BU.EDU (Barry Shein) (07/14/88)
One thing about fancy input line editing: it should probably be either everywhere or nowhere (I distinguish "fancy" only because Unix, particularly BSD, already has some line editing, such as erase-word.) What I don't like about just putting it into a shell is that it then conflicts with habits when using a simple program which just does reads, a human interface issue. I also like the idea that any programmer's program (even a neophyte's own) tends to work more or less as well as the shell on really visible things like input editing. If there's one criticism I have of TOPS-20's fancy input editing it's that it was incredibly baroque for the programmer, and rarely available to the higher level language programmer in any reasonable way (eg. thru the languages' std input methods, like scanf().) It may have been the cat's meow in some's eyes in effects, but it sure wasn't very well thought out in terms of letting (mortal) applications programmers near it, so vanilla applications tended to look kind of klunky and brain-damaged (and that OS had no particular interest in device independance tho one could code anything if they had the patience to run thru enough JSYS's to get the effect they wanted.) I haven't looked at the Unix COMND routines from, I believe, Columbia, perhaps I (we) should. The other question is, if it's done as an intermediate process how does the process know when to step out of the way because a newly started job is doing its own style of input editing? (yes, I'm bracing myself for the answer...) -Barry Shein, Boston University
guy@gorodish.Sun.COM (Guy Harris) (07/14/88)
> > 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 <RETURN>, 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.
tytso@athena.mit.edu (Theodore Y. Ts'o) (07/14/88)
One problem with putting the input line editor (ile) where it is is that you don't always want to be able to step back through ALL the lines that were typed to that tty. For example, if you started editing a file using /bin/ed (or some other interactive program), and typed hundreds of "n", "p", "i", "a", and "s/foo/bar/" commands, when you exited to the shell, do you really want to step through those hundreds of /bin/ed commands? The shell isn't going to do anything useful with them. Want I want to do is step back to the last *shell* commands, not necesarilly the last line I typed. Now, you might say that this is a "inconsistent user interface". But I find that having the shell step through only shell commands is a lot more friendlier to the user. I use a csh with a line editor hacked in, and I've been very satisified with the result. This is the csh which is in use at MIT Project Athena, and our users in general like it a lot. - Ted =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Theodore Ts'o mit-eddie!mit-athena!tytso 3 Ames St., Cambridge, MA 02139 tytso@athena.mit.edu If it's for real, it isn't!
matt@ncr-sd.SanDiego.NCR.COM (Matt Costello) (07/14/88)
As regards the Input Line Editor, and where does it fit ...
Isn't this what STREAMS are for? Since a stream module has access
to the ioctls it should know when it is or is not wanted. It would
replace the standard line discipline available in cooked mode. The
ILE would then be available to all programs doing line mode input
from the user's terminal.
Which brings up the interesting question of where a streams module
would store 'instance' data since it is in the kernel address space.
The only thing I can see is that the streams module could grab a
free disk buffer or two to save the history.
--
Matt Costello <matt.costello@SanDiego.NCR.COM>
+1 619 485 2926 <matt.costello%SanDiego.NCR.COM@Relay.CS.NET>
{ucsd,att,pyramid,nosc.mil}!ncr-sd!mattjbs@fenchurch.MIT.EDU (Jeff Siegal) (07/14/88)
In article <23839@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: >[...]if it's done as an intermediate process how >does the process know when to step out of the way because a newly >started job is doing its own style of input editing? As Doug said, kernel support should be provided as necessary. In this case, provide a way for the intermediate process to determine (or be told) that the terminal (perhaps a pseudo-terminal) has been switched out of cooked mode. As has already been pointed out, Emacs shell buffers could use such a service to improve support for input editing. Perhaps I missed this, but shouldn't the question be "How to provide *better* input editing in Unix?" The kernel already provides limited editing capability in cooked mode, yes? Jeff Siegal
nessus@wonko.MIT.EDU (Doug Alan) (07/14/88)
>> [nessus@eddie.mit.edu:] There should also be a version of X that >> runs in a limitted form, but supports the most basic features, on a >> normal, dumb terminal, so you don't *have* to have a workstation to >> use programs that don't need one. > [guy@gorodish.Sun.COM (Guy Harris):] One of the "most basic > features" of X11 is the ability to draw things such as lines, and > curves, and so on and so forth, with pixel-level resolution. Perhaps you (and perhaps the people who wrote X) consider this one of the most basic features. I don't, however. I consider the most basic features to be those that allow me to manage multiple text windows, not all of which have to be visible, but all of which can contain running programs creating output. In any case, I don't want to get into an argument of what X is and isn't. I just want to say how I think things should be: As I already said (1) I think there should an input preprocessing facility that provides input line editing for all programs that accept their input as lines of text. (2) There should be an output processing facility so that programs like "more" and "less" are not required. All the capabilities of these programs should be in the output processing facility. The output processing facility should also handle doing anything fancy with the display (such as clearing the screen. moving the cursor, etc). (3) The programs which implement these input and output processing facilities should be selectable by the user. (4) There should be a means of and protocol for communication between a program and these input and output processing processes. (5) Some kernal mods may be necessary to make this scheme simple and efficient. For example, the input editor needs to be able to find out the current working directory of the process to which it is sending the input. (6) The X window system already does some of the above stuff, and the rest could be added. (7) There should also be a standard set of programs for normal 24x80 dumb terminals (let's call the programs "X--") that do window management, and input and output processing of the sort talked about above. > If you're referring to the server for the X11 Window System, it > should definitely *not* "have line editing added to it." The X11 > server is supposed to deliver extremely RAW key events to its > clients, so that the clients aren't obliged to undo any > "intelligence" that the server adds. X already has some input editing, and it certainly doesn't deliver "extremely RAW key events" to all of its clients. X allows me to cut text that is on the screen, and paste it into my input. It allows me to remap my keyboard. Is this "raw" key events? And indeed, these input procressing capabilities should be expanded. Full line-editing should be added. For example, at the bottom of every window that accepts input, there could be a little one-line Emacs window (or your choice of editor) that allows you to edit the current line (or recall a previous line and edit it) and send it to the application when you are finished with it. In fact, you can already do something like this with X, but it's a real pain. If you wanted to, you could type all your input into Emacs, and use the cut and paste utilities to get all your keyboard input from Emacs to the program you are using. This isn't worth the bother, however. > What if the client *isn't* using the keyboard as a "normal" > terminal-style keyboard? Then the application should be able to able to tell X, "hey, please give me my input rarer", in a manner similar to that which allows a normal Unix application to request input in "raw" or "cooked" mode. > As for "every program should know about X", well, "cat" shouldn't > know about X; it should only know about writing output to a file > descriptor. The file descriptor goes to a pseudo-terminal (or moral > equivalent); the output goes to an X11 client program, which > displays it on the screen by sending requests to the X11 server. > "cat" doesn't know about X; "xterm" does. Perhaps I worded things a bit poorly. Certainly programs that don't want to do anything fancy with the display, need not know anything about X. I meant to say that any program that wants to do anything fancy with the display (such as clear the screen, move the cursor, etc) should not do it itself. It should know that there is a display manager to do these sorts of things for it, and it should communicate with the display manager using some prescribed protocol. There should not be any programs such as "more" or "less". All the functionality of these programs should be built into the display manager. > From: bzs@bu-cs.BU.EDU (Barry Shein) > [...] The other question is, if [input line editing is] done as an > intermediate process how does the process know when to step out of > the way because a newly started job is doing its own style of input > editing? (yes, I'm bracing myself for the answer...) Well, recently posted to Unix-Wizards was "ile" -- "input line editor". Ile seems to handle this by getting out of the way if any process below it puts the terminal in cbreak or raw mode. This seems to work most of the time, but not all of the time. The right way to do this is to devise and standardize a convention and means for communicating and coordinating this sort of thing between processes. |>oug /\lan (or nessus@athena.mit.edu nessus@mit-eddie.uucp) P.S. While we're on the subject of changing Unix, the system call that opens files should also be changed. It should be changed so that wherever you can specify a file to run, you can also specify a pipeline to run and use as a source of input or output. For example, if a program prompts me like so: Enter output file: I should be able to enter something like: Enter output file: ^(filter1 | justify -80 | tee \ ^(filter2 | justify -40 > output-file2) \ > output-file1) The output would get filtered through filter1, justified to 80 columns, and output to "output-file1". Another copy of the output would get filtered through filter2, justified to 40 colums, and output to "output-file2".
nessus@wonko.MIT.EDU (Doug Alan) (07/14/88)
> From: tytso@athena.mit.edu (Theodore Y. Ts'o) > One problem with putting the input line editor (ile) where it is is > that you don't always want to be able to step back through ALL the > lines that were typed to that tty. For example, if you started > editing a file using /bin/ed (or some other interactive program), > and typed hundreds of "n", "p", "i", "a", and "s/foo/bar/" commands, > when you exited to the shell, do you really want to step through > those hundreds of /bin/ed commands? The shell isn't going to do > anything useful with them. Want I want to do is step back to the > last *shell* commands, not necesarilly the last line I typed. Well, that doesn't mean that "ile" is in the wrong place. "Ile" is in the right place. What it means is that "ile" should be made smarter for your use. It should keep track of what programs you fire up and allow you to keep a seperate history buffer for each program. (If this can't be done efficiently because of the kernal doesn't support this well, then the kernal should be made to support it.) > Now, you might say that this is a "inconsistent user interface". > But I find that having the shell step through only shell commands is > a lot more friendlier to the user. I use a csh with a line editor > hacked in, and I've been very satisified with the result. This is > the csh which is in use at MIT Project Athena, and our users in > general like it a lot. Putting line editing seperately into every program in the world in just plain wrong. Users like the Athena's C-shell because they don't have anything better. I use Athena's C-shell because I don't have anything better. That doesn't mean that it is done right. (I'm considering using "ile" instead, but it has its own problems). > From: henrik@blblbl.UUCP (Larry DeLuca) > While it's not going to help the ile people much, it still seems the > best place for a line editor of some sort is still the tty driver > (ioctl's can be used to set characters or toggle between modes). No, you're wrong. > The most simple line editing commands (rubout, line delete, and co.) > are there already, and it is the only way to guarantee that they > will be uniformly supported. There is another way to guarantee that line editing will be uniformly supported. (1) Provide an alternate, and better method. (See my and some other's previous articles on the issue). (2) Remove line editing completely from the kernal, forcing everyone to use the better method. > The major complication, of course, is that this requires > intelligence in the tty driver about terminal escape sequences. ITS > (Incompatible Time Sharing, developed at MIT) has excellent support > in this regard (the tty driver knows how to do operations like clear > the screen, and is also aware of what's on the screen at any given > time, so can repaint it after a send, for example). The problem with this is that the ITS kernal knows about certain terminal types. If you don't have one of these terminal types, you have to run a program which knows about your terminal type and emulates one of the known terminal types, making your terminal look to every other program like one of the known terminal types. Why not forget the part about the kernal knowing about certain terminal types, and keep the smart and general idea: having a process that makes all terminals look alike to other programs? |>oug /\lan (or nessus@athena.mit.edu nessus@mit-eddie.uucp)
guy@gorodish.Sun.COM (Guy Harris) (07/14/88)
> Isn't this what STREAMS are for? Since a stream module has access > to the ioctls it should know when it is or is not wanted. It would > replace the standard line discipline available in cooked mode. If it *replaces* the standard line discipline, there's nothing particularly streams-specific about it; you could do the same thing on a system with a non-streams tty driver by replacing the line discipline. You might get something more out of streams by sticking it *above* the standard line discipline and running the standard line discipline permanently in non-canonical mode. However, I'm not willing to say, off the top of my head, that the line editor would work sufficiently well without the ability to get at the state of the line discipline. Then again, I don't think this is what streams are for; I'd prefer to use them for things that you can't put in user mode. I'd rather have the input line editor run the real terminal, and emulate a terminal - or terminals, if you want multiple windows on a dumb terminal - via a pseudo-tty or pseudo-ttys. That way I can write my own input line editor if I want to, and not have to get somebody with sufficient privileges to link it into the kernel of every machine I use. Of course, if your OS implements the tty driver in user mode (consider a system - such as Aegis / DOMAIN/OS? - where "read" and "write" are implemented in user mode, along with the moral equivalent of "cdevsw"), you might be able to replace it without sufficient privilege.
guy@gorodish.Sun.COM (Guy Harris) (07/14/88)
> Perhaps you (and perhaps the people who wrote X) consider this one of > the most basic features. I don't, however. I consider the most basic > features to be those that allow me to manage multiple text windows, > not all of which have to be visible, but all of which can contain > running programs creating output. Who said anything about "text windows"? That sounds like a feature of "xterm", not X in its entirety. I very much expect that the people who wrote the X server didn't think of it as something to "manage multiple text windows"; it's the job of X clients to do text windows. X just lets you draw on drawing surfaces, and there are lots of X clients that *don't* just draw text on those drawing surfaces. X is not "xterm". I suspect a lot of the cries for "an X for my VT100" come from people who reall wants multiple text windows, and think of X as "xterm", i.e. something that implements text windows. This means that instead of asking for what they really want - "how can I get multiple text windows on my VT100" - they ask for some particular *mechanism* for getting multiple text windows on their VT100, namely "is there an X server for a VT100?" If they *had* asked for multiple text windows on their VT100, people could point them at the 4.3BSD "window" program or any one of a number of programs that provide what they want, instead of asking for some chimerical "dumb terminal X server". > (1) I think there should an input preprocessing facility that > provides input line editing for all programs that accept their input > as lines of text. (2) There should be an output processing facility > so that programs like "more" and "less" are not required. All the > capabilities of these programs should be in the output processing > facility. The output processing facility should also handle doing > anything fancy with the display (such as clearing the screen. moving > the cursor, etc). What you want here is something that runs off your real terminal, or as a window-system client, and uses one or more pseudo-ttys to emulate one or more virtual terminals. It would also do paging (the Sun "shelltool", for example, can do this) and fancy input line editing (EMACS and the Andrew typescript program can do this). They would also have to be able to run in a mode where they can handle "full-screen" types of things (such as clearing the screen, moving the cursor, etc.); it may be possible to do this in their standard mode. I don't know if there is any program that does *all* of this, but I don't see why one couldn't be written. > (3) The programs which implement these input and output processing > facilities should be selectable by the user. No problem. On a dumb terminal, you start the program up when you log in; it takes over your physical terminal and provides one or more virtual terminals using pseudo-ttys. Under a window system, you just fire up one of these programs when you want a tty window. > (4) There should be a means of and protocol for communication between a > program and these input and output processing processes. Since programs that want these facilities tend to be run from terminals, a pseudo-tty type mechanism provides this. The "protocol" would just be a bi-directional byte stream, similar to the byte stream that runs over the wire between a host and an intelligent terminal. > (5) Some kernal mods may be necessary to make this scheme simple > and efficient. For example, the input editor needs to be able to find out > the current working directory of the process to which it is sending the > input. Maybe. Unfortunately, telling the input editor about the current working directory of the process to which it is sending the input would be unlikely to be simple, although it might conceivably be efficient. (If you think it's simple, show a simple design for it and show that a simple implementation is possible. Note that there may be several processes equipped to read from the terminal, and the input editor will not know to which process it's sending the input until the process actually tries to read its input.) > (6) The X window system already does some of the above stuff, and the > rest could be added. A certain *component* of the X window system, namely "xterm", already does some of the above stuff. It does so because it's a terminal emulator, not because it's a part of X. Therefore, you can do it outside of X about as easily (or maybe even more easily). > (7) There should also be a standard set of programs for normal 24x80 dumb > terminals (let's call the programs "X--") that do window management, and > input and output processing of the sort talked about above. "Let's call the programs 'X--'"? Let's not, and say we did. The program would bear a closer relationship to "xterm" than to the X server; you wouldn't be able to run X programs under it, but you would be able to run the same sorts of programs you run under "xterm" under it as well (unless they use some graphics feature "xterm" provides, but that this windowing program couldn't provide on a dumb terminal, such as Tektronix graphics terminal emulation). > > If you're referring to the server for the X11 Window System, it should > > definitely *not* "have line editing added to it." The X11 server > > is supposed to deliver extremely RAW key events to its clients, so that > > the clients aren't obliged to undo any "intelligence" that the server > > adds. > X already has some input editing, and it certainly doesn't deliver > "extremely RAW key events" to all of its clients. X allows me to cut text > that is on the screen, and paste it into my input. It allows me to remap my > keyboard. Is this "raw" key events? You bet it is! I said that the server *does* deliver extremely RAW key events to its clients, and I stick by that claim 100%. The *clients* handle the cut-and-paste stuff, and the remapping; they interpret the "key 27 went down" events as meaning "the user hit the 'a' key, insert an 'a' into the document at this point" or the "key 13 went down" event as meaning "past the current cut buffer into the input. > And indeed, these input procressing capabilities should be expanded. Full > line-editing should be added. For example, at the bottom of every window > that accepts input, there could be a little one-line Emacs window (or your > choice of editor) that allows you to edit the current line (or recall > a previous line and edit it) and send it to the application when you > are finished with it. What if your window doesn't know anything about lines? What if it just puts up a form you fill in, and buttons you push, and sliders you move, and...? Again, this input editing belongs in the *client*, not the *server*. When I say "client" here, I mean X client, and when I say "server", I mean X server. X consists of several components. The server accepts connections from clients, gets requests to do things such as create windows and paint things in them over those connections, and sends input events from keyboards, mice, etc. back to the clients over those connections. Clients are programs such as "xterm", font editors, spreadsheet programs, drawing programs, etc., etc., etc.. Those programs open a connection to the X server, and create windows and draw things by sending them requests over that connection. They get their "marching orders" from the user over this connection, in the form of very raw keyboard events ("key 27 went down", "key 27 went up", "key 31 went down", etc.) and mouse events. "xterm" is such a client; it might interpret "key 27 went down" as "the user hit the 'a' key" and send an "a" over its pseudo-terminal. It also interprets requests that come over the pseudo-terminal; the request with the byte code octal 141 means "paint an 'a' at the current position on the screen", and sends a request to the X server to do so. In this sense, "xterm" is both a client and a server. It is a client of the X server; it is a server for the programs that are connected to its pseudo-terminal. In the same sense, the microprocessor in a typical "plain" terminal is running a program that's a server, connected to its clients over, say, an RS-232 cable; when you print "a", a byte with the code octal 141 is sent over the cable, and when the program in the terminal receives this code it tells the display hardware to put up an "a" on the screen at the current position. When it is told by the keyboard hardware that key 27 went down, it sends an "a" back over the wire. (Thus, the relationship between the terminal's firmware and its keyboard and display hardware is pretty much the same as the relationship between "xterm" and the X server.) Similarly, you can implement a program that acts as a server in a fashion similar to "xterm" or the firmware in a terminal; it uses pseudo-ttys in the same way "xterm" does, to talk to its clients, and it acts as a client to a "plain" terminal that it has open. In fact, people *have* implemented programs such as this, EMACS being one and the 4.3BSD "window" program being another. Given this model, you can see that "putting line editing in X" should not mean putting it into the X server, it should mean putting it into clients such as "xterm". Furthermore, given that, you can see that the same functionality could be put into a "plain terminal" windowing program - or even into the firmware of a terminal! A block-mode terminal has some of that functionality; a Bell Labs Blit, or any of its successors, has lots more of it, since you can download programs to it. In other words, as I indicated above, there's really nothing particular about X that lets you do line editing in a program of the sort you describe. You can put the line editing into any sort of "terminal firmware" program, regardless of whether the "firmware" is running on a 68000 inside a Blit terminal, on a general-purpose computer as part of a "plain terminal" window program, on a general-purpose computer as part of "xterm" - or any other terminal emulator on any other window system. However, you also notice another thing: if you put line-editing in "xterm", then programs *that read from a terminal, and that are run inside an "xterm"*, could make use of this facility. However, not all programs will be run this way. Some programs will talk directly to the X server; they may not even have the notion that their text input is broken up into lines (which makes doing line-editing a bit tricky...). Now, if you're just a user of X, a lot of the careful distinctions listed above really aren't important. However, if you want to discuss not only what capabilities you want (e.g., line editing), but *how to implement them*, you're no longer just a user and, when discussing implementation issues, can't reasonably think only as a user; you really have to understand some of how it all works.
cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) (07/14/88)
In article <59768@sun.uucp>, guy@gorodish.UUCP writes: > I don't know what "the built-in editor on the NeWS windowing system" is (I > 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 Nope, they're not line editors, but simple cut-and-paste mouse operations which allow the user to cut from anywhere on the screen (from any window) and send that cut segment as a keyboard-like input to any window. Since this type of thing is 90% of what I use Ksh editing for, it is just fine with me. Also, it's real useful when editing multiple files with vi. > > 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, > 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 I would like _vi_ in the kernel, but that's because I like vi. I guess I forgot the :-)'s. -- Christopher J. Calabrese AT&T Bell Laboratories ulysses!cjc
bzs@bu-cs.BU.EDU (Barry Shein) (07/14/88)
I dunno Doug, there's nothing unreasonable about your wish list and I get the feeling it's all been provided (eg. window in 4.3). Perhaps you don't love some of the design choices therein but that's a bit different than saying Unix doesn't have this or that or needs major changes, the particular solutions just don't seem to have caught on universally, something to ponder. Maybe the rest of the world is crazy (my suspicion also, but not based on this particular issue.) >X already has some input editing, and it certainly doesn't deliver >"extremely RAW key events" to all of its clients. Um, it certainly does, it delivers a stream of indices into a key table and nothing more. Hmm, define "RAW". >X allows me to cut >text that is on the screen, and paste it into my input. X has facilities which allows the programmer to implement this kind of thing (a stack of addressable cut and paste buffers, which don't have to contain anything related to key strokes.) >It allows me >to remap my keyboard. It "allows" you (ie. provides the facilities to...) pass the keymap indices through a mapping table (an associative array, basically.) Nothing you couldn't do with a simple case statement other than providing some standard way to set up mappings for largish maps. It's sort of like saying Unix "allows" me to ask for sin(.3456), yeah, so what? >Is this "raw" key events? Yes, I think so, it delivers simple indices to the client and has a facility to optionally pass them through a translation table. Does the fact that Unix has a toupper() macro mean that Unix only supports upper-case? I'm not sure I see your point (or, I think you are confused as to what X "delivers" and what can be further done with some programming.) >And indeed, these >input procressing capabilities should be expanded. Full line-editing >should be added. Have you looked at the text widget in the toolbox? It seems to provide full emacs-like editing (or certainly makes a sincere effort to.) You're not making it clear at what level this should be added. Should it be in the client? The server? The application library? The toolkit? The network protocol? All are possible and various other systems have done this kind of thing at least once, not all have been a raving success tho most are interesting to look at. >For example, at the bottom of every window that >accepts input, there could be a little one-line Emacs window (or your >choice of editor) that allows you to edit the current line (or recall >a previous line and edit it) and send it to the application when you >are finished with it. Ok, fine, there's a design proposal. It wouldn't be very hard to implement in xterm or as a library/toolkit call that xterm could use. Probably an afternoon's programming (actually, probably less, you could just cobble the text widget as a popup or something, and access the scroll history xterm already keeps.) >In fact, you can already do something like this with X, but it's a >real pain. If you wanted to, you could type all your input into >Emacs, and use the cut and paste utilities to get all your keyboard >input from Emacs to the program you are using. This isn't worth the >bother, however. or you could probably add a lisp support routine (18.51 already has X11 support, so this isn't that glib) which allows you to bind a zap-to-cut-buffer to a keystroke or some such, and the other end of that to xterm (which is already there, you just seem to dislike the motions needed from your hands to select it, it probably wouldn't be that hard to eliminate all motions, or check the cut buffer for new input when you hit newline or something like that, you could also have it require no motions on the xterm end although information theory still begs for an answer to what to do when you have more than one xterm running.) >I meant to say that any program that wants to do anything >fancy with the display (such as clear the screen, move the cursor, >etc) should not do it itself. It should know that there is a display >manager to do these sorts of things for it, and it should communicate >with the display manager using some prescribed protocol. What does this mean? Are you proposing prescient software? The application has to do *something* to give the display server a hint that it wants, eg, the screen cleared. In X the basic thing is to call XClearWindow(), or if running in xterm to send a vt100 escape sequence in the ASCII stream. What exactly do you want that this isn't? >There should not be any programs such as "more" or "less". All the >functionality of these programs should be built into the display >manager. Xterm has this more or less (pardon me), or it could be trivially added. Sunview certainly has it, I've found it variously a plus or a minus, fortunately you can turn it on or off at will, I've usually had it off with rare exceptions for some reason. >> From: bzs@bu-cs.BU.EDU (Barry Shein) > >> [...] The other question is, if [input line editing is] done as an >> intermediate process how does the process know when to step out of >> the way because a newly started job is doing its own style of input >> editing? (yes, I'm bracing myself for the answer...) > >Well, recently posted to Unix-Wizards was "ile" -- "input line >editor". Ile seems to handle this by getting out of the way if any >process below it puts the terminal in cbreak or raw mode. This seems >to work most of the time, but not all of the time. The "most of the time" was what I was bracing myself for, as I suspected. >The right way to do this is to devise and standardize a convention and >means for communicating and coordinating this sort of thing between >processes. NO! The RIGHT way to do this is to SOLVE the problem CORRECTLY! That was sarcasm, do you see any more information content in your suggestion than my obnoxious remark? HOW do you "devise and standardize...", you sound like you're running for political office, not proposing designs. -Barry Shein, Boston University >P.S. While we're on the subject of changing Unix, the system call that >opens files should also be changed. It should be changed so that >wherever you can specify a file to run, you can also specify a >pipeline to run and use as a source of input or output. For example, >if a program prompts me like so: > > Enter output file: > >I should be able to enter something like: > > Enter output file: ^(filter1 | justify -80 | tee \ > ^(filter2 | justify -40 > output-file2) \ > > output-file1) No, this doesn't belong in the open call, applications can (and certainly have been know to, see tip for example) implement this easily enough with the existing terrain. If it were an atomic primitive it would cause all sorts of problems and loss of ability to control intervening things (like setting up to handle interrupts and process groups to envelope the subprocesses, and manage errors, what should open() return if one of those commands didn't exist or was typo'd? "EFUKTUP: SOMETHING has gone wrong", the current method would tell the programmer exactly what was wrong trivially. Analyzing the possible errors is a critical part of design.
bzs@bu-cs.BU.EDU (Barry Shein) (07/14/88)
These cries for an X-server for dumb terminals remind me a lot of the days when people always screamed if some screen-oriented program didn't have some mode for people on paper terminals, back then most or many people used paper terminals and CRTs were these rather rare, expensive beasts. It was considered pretty arrogant to write programs which only worked on glass ttys (I got in some trouble at Harvard for doing that once, until I pointed out that we didn't have any paper ttys in the lab the software was designed for, people were still uneasy that we "might" someday...?!) Somehow, it got worked out, and few true screen programs ever really managed to provide much support for paper (although some editors had a limited mode for this, EMACS in paper-tty mode was interesting...) I think the designs will have to assume bit addressable terminals of reasonable resolution and the market will solve the rest of the problem (as it already is doing rapidly.) Like supporting old hardware in general, the day simply comes when you have to pay a lot of $$$ to have your "cheap" hardware supported, there's no other way (other than accepting no support), you won't get creative people terribly interested in writing X servers for KSR-33's, tho you might be able to pay one enough to think about it, false economy I suspect, unless you do succeed in convincing someone to provide a few tens of thousands of dollars of programming for free by screaming loud enough. -Barry Shein, Boston University The future just isn't what it used to be...
gregg@a.cs.okstate.edu (Gregg Wonderly) (07/15/88)
From article <9671@eddie.MIT.EDU>, by nessus@wonko.MIT.EDU (Doug Alan): > 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. I just solved that problem here by writing a KSH style history and command line editor subroutine that is called gets(). Now is just link it into all of my personal tools (including GOSH, my shell) and I have consistant editing. Each application can have it's own history file, or they can share one. This routine knows when stdin is not a TTY and switches to normal gets() operation so that you can still use < redirection and not worry about lots of overhead, or interpretation of input. Is this along the lines of what you want? Gregg Wonderly Department of Computing and Information Sciences Oklahoma State University UUCP: {cbosgd, ihnp4, rutgers}!okstate!gregg Internet: gregg@A.CS.OKSTATE.EDU
jbs@eddie.MIT.EDU (07/15/88)
In article <59697@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes (quoting an article by Doug Alan): >> There should also be a version of X that runs [...] on a normal, >> dumb terminal. >One of the "most basic features" of X11 is the ability to draw things such as >lines, and curves, and so on and so forth, with pixel-level resolution. I >would be very surprised to hear about *ANY* X11 client that could live with the >minimum set of X11 requests that could be implemented on a "dumb >terminal" Consider an 80x24 terminal with a 256 character font. If this is viewed as an 80x24 bitmapped display with 8 bits per pixel, it should be possible to run X on it. To make such a thing useful, you need the server to process fonts as pixmaps (I don't know if there are any servers that currently do this--it would be also be useful for anti-aliased fonts on a normal workstation). The font size would be 1 pixel by 1 pixel. VT100's, which have double-width and double-width, double-height fonts would have 2 by 1 and 2 by 2 fonts as well. The lack of a pointer is another problem that can be dealt with in a variety of creative ways. What is wrong with this scheme? Please omit reasons like "You wouldn't want to do that because character-based terminals are worthless," etc. Jeff Siegal
gregg@a.cs.okstate.edu (Gregg Wonderly) (07/15/88)
From article <3709@okstate.UUCP>, by gregg@a.cs.okstate.edu (Gregg Wonderly): > > I just solved that problem here by writing a KSH style history and > command line editor subroutine that is called gets(). Humm, the editor wars should have reminded me... I should say KSH's VI style history and command line editor. Gregg Wonderly Department of Computing and Information Sciences Oklahoma State University UUCP: {cbosgd, ihnp4, rutgers}!okstate!gregg Internet: gregg@A.CS.OKSTATE.EDU
guy@gorodish.Sun.COM (Guy Harris) (07/15/88)
> Consider an 80x24 terminal with a 256 character font. > > What is wrong with this scheme? 99 44/100% of the terminals out there don't have 256-character fonts, so it won't work on 99 44/100% of the terminals out there. If you need a special terminal for this, you might as well bite the bullet and get one of the X terminals coming out; you won't be able to draw arbitrary pictures on the screen with any sort of reasonable resolution with this hack. If all you want an "X server on a dumb terminal" for is to have multiple *character* windows on a dumb terminal, then as I pointed out there are *FAR* better ways of getting multiple character windows.
henrik@blblbl.UUCP (Larry DeLuca) (07/15/88)
|>oug,
Your observations about ITS are most astute. However, they point out the
critical failing of the whole thing -- they require a specific action on
the part of the end user -- if they forget to run the CRTSTY program their
terminal is not supported.
If you want line editing to be available *all* of the time, no matter what,
automatically, the terminal driver is the place to do it. If the operations
are carefully designed and defined there is no reason that they can't be
mapped to any terminal and any editor the user likes. If one were to write
a supplement to getty(8) that would perform the appropriate ioctl(2)'s (or
have getty do the work based on the TERM and EDITOR environment variables --
note here that while the line-editing itself should be in the kernel ALL
the configuration can be done from user-level programs that work with init(8)
and getty(8) -- a user-level program could look up the terminal in termcap(7)
for Berkeley systems and terminfo(4) for System V derivatives to get the
necessary escape sequences to perform the necessary operations -- an
edicap(7) or similar file could be created to describe various editor keystrokes
such as:
emacs|jmacs|jove|Jove Editor:\
up=\^p:dn=\^n:bk=\^b:fw=\^f:
....
This avoids building excessive intelligence about specific terminals into
the kernel (so that terminals are not uniformly supported, as in the ITS
example) and at the same time avoids redundant information storage (which
can lead to a much harder time tracking down any problems that might arise
-- version skew, broken termcap, and the like).
However, the big win here is that the Operating System and its system
utilities now take care of configuring all this for the user. If they
want to override it, they may reset the appropriate variables and run
the user program that configures the information again.
larry...jbs@fenchurch.MIT.EDU (Jeff Siegal) (07/15/88)
In article <60001@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes (in reply to my article) >> Consider an 80x24 terminal with a 256 character font. >99 44/100% of the terminals out there don't have 256-character fonts, so it >won't work on 99 44/100% of the terminals out there. The 256 character character font example was just for ease of presenting the idea. It would work equally well if the terminal had less characters. The unassigned pixel values would just not be used in the (1 pixel by 1 pixel) X font (the same way conventional X fonts don't use every possibly pixel combination). >If you need a special terminal for this You don't. That's exactly the point. With a server implemented this way, *millions* (tens of millions, etc.) of existing, cursor-addressible, character-based terminals would instantly become X-compatible. >If all you want an "X server on a dumb terminal" for is to have multiple >*character* windows on a dumb terminal, [...]there are *FAR* >better ways [...] The whole point of this was not just to have multiple character windows (although I don't see why this is such a bad way to get them). It was to have a consistent interface to the input and output devices. With a character-based X server, all interactive programs could be written using X facilities. Xterm would no longer be needed, except as a compatibility tool. Termcap would no longer be needed, except as a configuration language for the character-based X server. Jeff Siegal
eirik@tekcrl.TEK.COM (Eirik Fuller) (07/15/88)
In article <9677@eddie.MIT.EDU> nessus@wonko.MIT.EDU (Doug Alan) writes: >> From: tytso@athena.mit.edu (Theodore Y. Ts'o) >> ... > >Well, that doesn't mean that "ile" is in the wrong place. "Ile" is in >the right place. What it means is that "ile" should be made smarter >for your use. It should keep track of what programs you fire up and >allow you to keep a seperate history buffer for each program. (If >this can't be done efficiently because of the kernal doesn't support >this well, then the kernal should be made to support it.) Ok, your line editor is going to know all about execing programs. Swell. In what sense won't it be a shell? It's starting to sound to me like you're really saying that shells that only let you edit their own command history and not the input to the programs they exec don't have full fledged input editing capabilities. I realize that there are wrinkles to be ironed out in building a shell that lets you edit input to the programs it execs. The worst of these wrinkles are not improved by separating the editor from the shell. I presume the best way to build a layer between the shell-editor and its child processes is for it to use a pty for each of them. Gee, this fictional shell-editor is beginning to sound more and more like a window manager. Why not just build an editor into xterm? A knowledgable user would guess which commands need which types of windows; pipelines, background jobs, and generally anything that doesn't need tty input could go into write only windows; editors and such could go into raw-mode windows, and things like debuggers and ftp could go into editor windows. Not that you need workstation graphics to make a shell-editor useful ...
bpendlet@esunix.UUCP (Bob Pendleton) (07/16/88)
From article <23839@bu-cs.BU.EDU>, by bzs@bu-cs.BU.EDU (Barry Shein): > What I don't like about just putting it into a shell is that it then > conflicts with habits when using a simple program which just does > reads, a human interface issue. I also like the idea that any > programmer's program (even a neophyte's own) tends to work more or > less as well as the shell on really visible things like input editing. Which is why I wrote ile. > I haven't looked at the Unix COMND routines from, I believe, Columbia, > perhaps I (we) should. Don't know anything abou them. Hoew about sending me a pointer? > The other question is, if it's done as an intermediate process how > does the process know when to step out of the way because a newly > started job is doing its own style of input editing? (yes, I'm bracing > myself for the answer...) Ile uses a pty to control io to the subprocess. So it just does an ioctl to check the mode at times when the mode could have changed. This works ok for raw and cbreak mode, but because ile wants to echo characters itself it doesn't work very well when a program (like su) just clears echo on the pty. Using this technique means that ile can do an ioctl call for each character it processes. I'm starting to think that the "right" thing would be for the pty to cause an exception every time an ioctl changes the ptys mode. The exception can be handled through code controlled by a select(). It would have to be an exception that could be ignored or else the change will break to much of the world. Everything else I've been able to think of can be handled by machs' concept of an environment server (I think). > -Barry Shein, Boston University 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.
bpendlet@esunix.UUCP (Bob Pendleton) (07/16/88)
From article <6192@bloom-beacon.MIT.EDU>, by tytso@athena.mit.edu (Theodore Y. Ts'o): > One problem with putting the input line editor (ile) where it is is that > you don't always want to be able to step back through ALL the lines that > were typed to that tty. For example, if you started editing a file > using /bin/ed (or some other interactive program), and typed hundreds > of "n", "p", "i", "a", and "s/foo/bar/" commands, when you exited to > the shell, do you really want to step through those hundreds of /bin/ed > commands? The shell isn't going to do anything useful with them. Want > I want to do is step back to the last *shell* commands, not necesarilly > the last line I typed. If ed sets cbreak or raw mode then ile won't record any of the characters going either direction. On the other hand in some programs you might like to have a history and line editing capability but not have that history in your "global" history. So, just invoke "ed" as "ile ed" or even alias "ed" to "ile ed". Then while you are running ed you have a local history that goes away as soon as you exit ed. But, the input line editing stays consistent. I haven't done this yet, but it has been suggested that ile should save and restore its history buffer using a file whose name is derived from the name of the program that was run under ile. That would give you a program specific history the persists from invokation to invocation of a program. > Now, you might say that this is a "inconsistent user interface". But I > find that having the shell step through only shell commands is a lot > more friendlier to the user. I use a csh with a line editor hacked in, > and I've been very satisified with the result. This is the csh which > is in use at MIT Project Athena, and our users in general like it a lot. I can't force my users to use one shell. I don't have time to hack several shells. Especially since I don't think I have source for all of them. And I can't count on having shell source in the future. I can count on having the source to ile. We aren't all still in academia. > - Ted > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Theodore Ts'o mit-eddie!mit-athena!tytso > 3 Ames St., Cambridge, MA 02139 tytso@athena.mit.edu > If it's for real, it isn't! 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.
guy@gorodish.Sun.COM (Guy Harris) (07/16/88)
> However, they point out the critical failing of the whole thing -- they > require a specific action on the part of the end user -- if they forget > to run the CRTSTY program their terminal is not supported. "Critical"? Nope. That's a minor nit at worst; being obliged to run some special program in your ".profile" sure beats the hell out of stuffing more hard-to-replace (and hard-to-page-out, in many implementations) poop into the kernel.
guy@gorodish.Sun.COM (Guy Harris) (07/16/88)
> The 256 character character font example was just for ease of > presenting the idea. It would work equally well if the terminal had > less characters. The unassigned pixel values would just not be used > in the (1 pixel by 1 pixel) X font (the same way conventional X fonts > don't use every possibly pixel combination). OK, so what happens when "xterm" tries to paint a scrollbar? > You don't. That's exactly the point. With a server implemented this > way, *millions* (tens of millions, etc.) of existing, > cursor-addressible, character-based terminals would instantly become > X-compatible. *SORT OF* X-compatible. Boatloads of X applications won't run worth a damn on them. > The whole point of this was not just to have multiple character > windows (although I don't see why this is such a bad way to get them). It's a bad way to get them because: 1) The other ways exist (e.g., 4.3BSD's "windows"), and this doesn't. Until somebody builds this mythical "X on dumb terminals" server, I won't believe it's necessarily even *possible*. 2) It's a lot more work than doing something like "windows", and if only a tiny number of X programs will run under it, it's not clear the extra work is worth it. > It was to have a consistent interface to the input and output devices. > > With a character-based X server, all interactive programs could be > written using X facilities. Xterm would no longer be needed, except > as a compatibility tool. Termcap would no longer be needed, except as > a configuration language for the character-based X server. Again, if by "consistent interface" you just mean an interface that doesn't require programs to know about N different kinds of terminals, something like "windows" gets you this; it emulates a "standard" sort of terminal.
jbs@eddie.MIT.EDU (07/16/88)
In article <60146@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: >OK, so what happens when "xterm" tries to paint a scrollbar? [on a mythical character based X server] You get a character based scrollbar (Microsoft applications, and possibly others, on PC's do this), assuming the user has the following in the Resource Database: *ScrollBar.width: 1 *ScrollBar.borderWidth: 0 *ScrollBar.foreground: [x] *ScrollBar.background: [y] [x] and [y] are the appropriate character name/values/whatever to make the scrollbar look reasonable. Perhaps [x] could be '#' and [y] could be '.' Jeff
tytso@athena.mit.edu (Theodore Y. Ts'o) (07/17/88)
In article <919@esunix.UUCP> bpendlet@esunix.UUCP (Bob Pendleton) writes: >From article <6192@bloom-beacon.MIT.EDU>, by tytso@athena.mit.edu (Theodore Y. Ts'o): >> were typed to that tty. For example, if you started editing a file >> using /bin/ed (or some other interactive program), and typed hundreds >> of "n", "p", "i", "a", and "s/foo/bar/" commands, when you exited to >> the shell, do you really want to step through those hundreds of /bin/ed >> commands? The shell isn't going to do anything useful with them. What > >If ed sets cbreak or raw mode then ile won't record any of the >characters going either direction. That wasn't the point. You know as well as I do that /bin/ed doesn't turn on cbreak or raw mode. The point was that I didn't want /bin/ed's (or any other interactive program) mixing with the history of the shell. The fact that ile does the right thing with emacs is wonderful, but it doesn't obscure the above problem. >On the other hand in some programs you might like to have a history >and line editing capability but not have that history in your "global" >history. So, just invoke "ed" as "ile ed" or even alias "ed" to "ile >ed". Then while you are running ed you have a local history that goes >away as soon as you exit ed. But, the input line editing stays >consistent. That's certainly a solution. One thing I've discovered since my last posting is that ile co-exists quite peacefully with a shell with built-in line editing. This way, you can have the best of both worlds. A hack which I'm thinking about designing for our shell is a builtin which would fork a copy of shell and have it work in the same manner as ile does for a certain command. This way, while you're in the shell, you don't get the efficiency hit of a pty pair, and the user can set up his keybindings and his keymaps at will. Then, when he wants line editing for an interactive program, the line editing environment will be duplicated. This allows a user to modify his line editor on the fly, and have the changes be reflect the next time he wants line editing. >I can't force my users to use one shell. I don't have time to hack several >shells. Especially since I don't think I have source for all of them. >And I can't count on having shell source in the future. I can count on >having the source to ile. We aren't all still in academia. Well, we could induce Berkeley (and other vendors) to put some sort of user-customizable line editior in the next csh. Or, you could just run GNUemacs in shell mode.... you should always have source code for that :-) - Ted =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Theodore Ts'o mit-eddie!mit-athena!tytso 3 Ames St., Cambridge, MA 02139 tytso@athena.mit.edu If it's for real, it isn't!
peter@ficc.UUCP (Peter da Silva) (07/18/88)
In article <9677@eddie.MIT.EDU>, nessus@wonko.MIT.EDU (Doug Alan) writes: > There is another way to guarantee that line editing will be uniformly > supported. (1) Provide an alternate, and better method. (See my and > some other's previous articles on the issue). (2) Remove line editing > completely from the kernal, forcing everyone to use the better method. Here's more or less (modulo problems with my memory) what currently happens when you hit a key: the lower half driver puts it in its raw queue, and also processes it and puts it in the cooked queue. It also puts any echoes back into the output queue for processing (this, by the way, is why writes to terminal devices aren't always atomic). The total cost of this is two context switches for entering and leaving the interrupt. To do it the way you want would basically require all programs to run in raw mode. This means that now you have: you hit a key, the lower half driver puts the key in the raw queue. Two context switches. Then your program wakes up, another context switch. Then it writes the character to the output stream, two more context switches. Finally your program goes away to wait for another key. Six context switches, at the minimum. Plus you execute in user mode. if your program requires swapping or paging to wake up, it's even worse. Not only that, but all your programs now have to check to see if they're in a pipeline and turn this stuff off when they are. this isn't that much compared to what you Athena jockeys already do, but it'll kill us poor folks with "mere" vax-class machines and terminals, shared among a dozen users. Interactive response time will go to hell. -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" (uunet,tness1)!sugar!ficc!peter.
bpendlet@esunix.UUCP (Bob Pendleton) (07/18/88)
From article <2834@tekcrl.CRL.TEK.COM>, by eirik@tekcrl.TEK.COM (Eirik Fuller): > In article <9677@eddie.MIT.EDU> nessus@wonko.MIT.EDU (Doug Alan) writes: >>> From: tytso@athena.mit.edu (Theodore Y. Ts'o) >>> ... >> >>Well, that doesn't mean that "ile" is in the wrong place. "Ile" is in >>the right place. What it means is that "ile" should be made smarter >>for your use. It should keep track of what programs you fire up and >>allow you to keep a seperate history buffer for each program. (If >>this can't be done efficiently because of the kernal doesn't support >>this well, then the kernal should be made to support it.) Ile can already do this, or maybe I should say that the user can already do this with ile. Just execute you programs under ile. You automatically get a new history buffer, its a new copy of ile right? And since ile puts its tty into raw mode the ile that you started out with will get out of the way. So you have a process tree that looks like this. ile some-shell ile your-program > > Ok, your line editor is going to know all about execing programs. > Swell. In what sense won't it be a shell? It's starting to sound to > me like you're really saying that shells that only let you edit their > own command history and not the input to the programs they exec don't > have full fledged input editing capabilities. The idea behind ile is to provide a simple, general purpose, tool. This tool allows me to have a useful and consistent input line editing interface to most every program I use. It also means that people who write programs can stop worrying about providing input line editing in their programs. If people want it, they can just use the ile of their choice. One of the basic concepts of UNIX as I learned it, was to provide tools that could be used together by the user to solve the users problem. Yet, people want to turn ile into a shell. ile offers a technique for REMOVING input editing from most all programs, including shells, thus providing the user more control over their environment, and allowing the programmer to write simpler programs. > I realize that there are wrinkles to be ironed out in building a ... > Gee, this fictional shell-editor is beginning to sound more and more > like a window manager. ... Why not try to avoid the tendency to complicate simple ideas? I've now learned enough about UNIX to believe that I can write a psuedo device driver that will give me the current working directory of a child process. But, I'm not sure I want to mess things up that badly. 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.
rbj@nav.icst.nbs.gov (Root Boy Jim) (07/19/88)
? From: Guy Harris <guy@gorodish.sun.com> ? > 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. One way arount that is via the bind command. Make the editing primitives `suffifiently general', and let the user bind funtion keys to the appropriate funtions. Command files to bind commonly used editing sets could be placed in /usr/pub (it's about time something else was put there :-). I don't know much about streams, but perhaps that's the way to go. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement Careful with that VAX Eugene!
rbj@nav.icst.nbs.gov (Root Boy Jim) (07/20/88)
? From: Gregg Wonderly <gregg@a.cs.okstate.edu>
? I just solved that problem here by writing a KSH style history and
? command line editor subroutine that is called gets().
As you no doubt already know, there is already a function named gets().
How about choosing another name?
? Gregg Wonderly
? Department of Computing and Information Sciences
? Oklahoma State University
? UUCP: {cbosgd, ihnp4, rutgers}!okstate!gregg
? Internet: gregg@A.CS.OKSTATE.EDU
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
The opinions expressed are solely my own
and do not reflect NBS policy or agreement
Careful with that VAX Eugene!gregg@a.cs.okstate.edu (Gregg Wonderly) (07/20/88)
>? From: Gregg Wonderly <gregg@a.cs.okstate.edu> > >? I just solved that problem here by writing a KSH style history and >? command line editor subroutine that is called gets(). > >As you no doubt already know, there is already a function named gets(). >How about choosing another name? By calling it gets(), I can just link it with existing applications. Since it IOCTL's fd 0 to turn on 'cbreak' mode, it can detect non-terminal input streams when the IOCTL fails, and then switch to normal gets() processing. Normally, I refrain from calling functions the same as library routines, but when they mimick them exactly, and there is nothing outwardly visible to the code (i.e. external variables or support function calls) then I see no reason not to. Exactly is, I guess, a sorta relative word, but I just hate to do a bunch of editing that might break a program, or otherwise make it out of sync with source distributions. The tons of different malloc(3)'s are a great example of why someone might name a routine the same as a library routine when it does the same thing, just differently... Gregg Wonderly Department of Computing and Information Sciences Oklahoma State University UUCP: {cbosgd, ihnp4, rutgers}!okstate!gregg Internet: gregg@A.CS.OKSTATE.EDU
mikep@ism780c.isc.com (Michael A. Petonic) (07/21/88)
In article <16541@brl-adm.ARPA> rbj@nav.icst.nbs.gov (Root Boy Jim) writes: >? From: Guy Harris <guy@gorodish.sun.com> >? > As for editors, I'd love to see one included in the terminal driver. >? 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. > >One way arount that is via the bind command. Make the editing primitives >`suffifiently general', and let the user bind funtion keys to the appropriate >funtions. Command files to bind commonly used editing sets could be placed >in /usr/pub (it's about time something else was put there :-). > >I don't know much about streams, but perhaps that's the way to go. Yeah, I'd have to agree. Perhaps there could be a general streams module for general editing functions that you could pop on top of a (streams, of course) tty driver. And if Emacs and Vi are popular, have two dedicated streams modules for those editors. The general editing function editor could be used for all other editors, with an IOCTL required to set up the bindings, before you use it. One disadvantage is having the streams tty driver. There are a couple of stream modules ("ntty" and "ld0") that implement network tty and line discipline 0, but it's really slow compared to the standard tty driver. Plus, I think the ld0 module isn't quite as stable as the stardard tty driver. Speed isn't much of a consideration in data comming from the tty to the process, but the other way around, speed becomes very important. -MikeP
tytso@athena.mit.edu (Theodore Y. Ts'o) (07/21/88)
In article <1112@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: >this isn't that much compared to what you Athena jockeys already do, but >it'll kill us poor folks with "mere" vax-class machines and terminals, shared >among a dozen users. Interactive response time will go to hell. Please note that this is *NOT* what we're running on Athena (although admittedly you have a chance of getting away with it when you give each user all of a microvax to play with.) We have the line editor built into csh. I maintain this is the right thing to do, since so few unix commands are interactive anyway, and the efficiency hit is attrocious. >To do it the way you want would basically require all programs to run in >raw mode. This means that now you have: you hit a key, the lower half >driver puts the key in the raw queue. Two context switches. Then your >program wakes up, another context switch. Then it writes the character >to the output stream, two more context switches. Finally your program >goes away to wait for another key. Six context switches, at the minimum. >Plus you execute in user mode. if your program requires swapping or paging >to wake up, it's even worse. It's worse than that. It does an ioctl every time a key pressed, to see if you've gone into CBREAK mode. And tty output also has to go through the pty pair. Given that over 90% of the line editing is in the shell (given the normal set of command-line format unix commands), putting the line editor in the shell is the right thing to do. (Assuming you have the resources to hack the shell, of course.) - Ted =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Theodore Ts'o mit-eddie!mit-athena!tytso 3 Ames St., Cambridge, MA 02139 tytso@athena.mit.edu If it's for real, it isn't!
guy@gorodish.Sun.COM (Guy Harris) (07/21/88)
> One disadvantage is having the streams tty driver. There are a couple > of stream modules ("ntty" and "ld0") that implement network tty > and line discipline 0, but it's really slow compared to the standard > tty driver. I'm curious why this is. A streams "tty driver" (i.e., a streams module implementing the standard tty functions) can certainly be faster than a tty "driver" implemented as a conventional line discipline using the V7/BSD line discipline interface; in fact, the SunOS 4.0 streams tty driver *is* faster (requires less CPU time) than the pre-4.0 driver when e.g. doing UUCP at high speeds. My suspicion is that this is due to the V7/BSD line discipline interface requiring one procedure call for every character received; I think the S5 line discipline interface may be able to pass blocks of characters across the interface. > Plus, I think the ld0 module isn't quite as stable as the stardard tty > driver. It hasn't been around as long; what do you expect? This is not necessarily caused by streams, although some stuff is more complicated in a streams driver. > Speed isn't much of a consideration in data comming from the > tty to the process, Depends on what you're using the tty for; when a human is typing at it, it's not vital, but when another computer is pumping data at high speed (e.g., UUCP) it can be important. > but the other way around, speed becomes very important. I don't think "ld0", as it stands, is very smart about output processing. If OPOST is clear (and either XCASE or ICANON is also clear - obscure ASR33 feature #101[*]), the driver should spend as little time as possible processing output; it certainly shouldn't either look at or copy the data if it can possibly avoid it. The standard S5 driver bypasses that processing if OPOST is clear; I don't think "ld0" does so. The SunOS streams driver bypasses it; it is faster than the pre-4.0 driver on output, as well as input, in the aforementioned UUCP case. The 4BSD driver used prior to 4.0 also tries to blast characters out without processing if it can, so this can't be chalked off to that. (It does two copies, though - one into a buffer on the stack, and one onto the clist.) If OPOST, or both XCASE and ICANON are set, it also tries to copy things quickly; it uses a routine "movtuc" to move characters that aren't processed (except for possibly mapping lower-case letters to upper-case) until it finds one that needs "special processing". (The "movtuc" routine could be done with a VAX "movtuc" instruction and some glue; see, we didn't even optimize 4.0 for SPARCs - we optimized it for VAXes! :-) :-) :-) :-) :-) :-) :-) :-)) [*] 101 is a Trademark of Peter Honeyman.
bpendlet@esunix.UUCP (Bob Pendleton) (07/21/88)
From article <1112@ficc.UUCP>, by peter@ficc.UUCP (Peter da Silva): > In article <9677@eddie.MIT.EDU>, nessus@wonko.MIT.EDU (Doug Alan) writes: >> There is another way to guarantee that line editing will be uniformly >> supported. (1) Provide an alternate, and better method. (See my and >> some other's previous articles on the issue). (2) Remove line editing >> completely from the kernal, forcing everyone to use the better method. > > ... Six context switches, at the minimum. > Plus you execute in user mode. if your program requires swapping or paging > to wake up, it's even worse. > > Not only that, but all your programs now have to check to see if they're > in a pipeline and turn this stuff off when they are. > > this isn't that much compared to what you Athena jockeys already do, but > it'll kill us poor folks with "mere" vax-class machines and terminals, shared > among a dozen users. Interactive response time will go to hell. > -- > Peter da Silva What Peter says is true. BUT, it is not a reason to stop looking for better ways to do things, or for opposing changes that would make using separate input line editing processes easier. The way things change in this business, by the time all the details are worked out the performance/price ratio will have increased by another factor of 2. Some people will still be stuck on ancient, oeverloaded systems, bot most won't. I use ile every day on a Sun 3/50 and an ULTRIX VAX-750. Sometimes its too slow on the 750. I don't notice it on a the Sun. 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.
henry@utzoo.uucp (Henry Spencer) (07/23/88)
In article <6339@bloom-beacon.MIT.EDU> tytso@athena.mit.edu (Theodore Y. Ts'o) writes: >... We have the line editor built >into csh. I maintain this is the right thing to do... > (Assuming you have the resources to hack the shell, of course.) I trust you have put this into *all* the shells? (Especially since the name of the shell which is closest to being a Unix-wide standard does not begin with "c".) Whatever happened to layers of abstraction?
allbery@ncoast.UUCP (Brandon S. Allbery) (07/23/88)
As quoted from <9666@eddie.MIT.EDU> by nessus@wonko.MIT.EDU (Doug Alan): +--------------- | In article <16456@brl-adm.ARPA> rbj@nav.icst.nbs.gov (Root Boy Jim) writes: | > I suspect that the real place for line editing is either in the shell | > itsef (as in tcsh, ksh, (and brlsh?)) or in the kernel. | | 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. +--------------- ??? Why not just a modified version of gets()? If you're running under SVR3, you can build a new version of the shlib with the new gets() and thereby upgrade every program on the system without recompiling! (NOTE: [1] Using scanf() to do terminal input provides insufficient protection from erroneous input and insufficient user-friendliness; using a loop of getchar()'s is a bit weird. I always use gets(), so all my programs would work first time. Other programs? Dunno, depends on how crazy the programmers were. [2] It would, of course, distinguish between a terminal and a non-terminal (heck, stdio does this now), so gets() used in a filter wouldn't fry sort's (for example) little mind.) I may actually try this, after backing up my system: if it goes wrong I can boot from the floppy and full-restore. . . . ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
blarson@skat.usc.edu (Bob Larson) (07/23/88)
In article <11933@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >??? Why not just a modified version of gets()? Gets has a major bug: it has no way of detecting the end of buffer passed to it. I use fgets(stdin, ... instead. [I expected someone else to mention this earlier.] Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%ais1@ecla.usc.edu oberon!ais1!info-prime-request
tes@pyr.gatech.EDU (TOM SEXTON) (07/24/88)
Posted earlier question about how to customize/change cursor. Please
e-mail responses. I don't know if my .sig is being added (first time posting,
if you couldn't tell) so address is
uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo}!gatech!gitpyr!tes
ARPA: tes@pyr.gatech.edu
Thanks again,
tomplocher@uport.UUCP (John Plocher) (07/24/88)
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. Like most things in the Real World, there isn't always one Right Thing. It is a Good Idea to provide a method, but let someone else provide policy. Library calls (or dynamic linkage or configuration thru ioctl()s...) to set up an editing environment are OK, but don't implement something that could get in the way of a program which didn't need it. -John Plocher
allbery@ncoast.UUCP (Brandon S. Allbery) (07/24/88)
As quoted from <9677@eddie.MIT.EDU> by nessus@wonko.MIT.EDU (Doug Alan): +--------------- | > From: henrik@blblbl.UUCP (Larry DeLuca) | > While it's not going to help the ile people much, it still seems the | > best place for a line editor of some sort is still the tty driver | > (ioctl's can be used to set characters or toggle between modes). | | No, you're wrong. +--------------- Strong disagreement. Given a STREAMS-based tty driver, one could push the following modules: terminfo-like module (or termcap, depending on your prejudices) input line editor module output module -- replaces more, etc. The TLM would be able to accept a term{cap,info} entry by grabbing an ioctl (or whatever; my STREAMS guide is still on order) with the data in it. The user could push their own choice of input and output filters (vi/emacs, more/ less) or leave off either or both. Then programs could do "smart" screen I/O via ioctls or etc. (or even by canonical escape sequences, as with the existing SysV facilities -- not that I've ever seen a SysV kernel with any of the virtual terminals actually compiled in) processed by the TLM. To the person who wants a "dumb X" -- isn't that what "window" is? ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
utashiro@sran84.sra.JUNET (Kazumasa Utashiro) (07/25/88)
In article <9666@eddie.MIT.EDU> nessus@wonko.MIT.EDU (Doug Alan) writes: >> In article <16456@brl-adm.ARPA> rbj@nav.icst.nbs.gov (Root Boy Jim) writes: >> >> > I suspect that the real place for line editing is either in the shell >> > itsef (as in tcsh, ksh, (and brlsh?)) or in the kernel. >> >> 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. I have a program that provide input line editing function for any old fashioned UNIX style commands. It is distributed as a free program in JUNET (UNIX network in Japan), but I'm not sure that it is to be distributed for world. So I include man page of this command and want to hear about its function. It looks almost like newcsh except that it works as a front-end for *any* program (even for vi :-). Note that this command is not based on any great concept like user interface should be something, but just a simple tool. Please don't talk to me about where the line editing should be placed as a comment for this program. If somebody want this program, I can post it to appropriate news group. Thank you for reading my bad English. Kazumasa Kayo Utashiro Software Research Associates, Inc. 1-1-1 Hirakawa-cho, Chiyoda-ku, Tokyo 102, Japan UUCP: kddlab!srava.sra.junet!utashiro ARPA: utashiro%sra.junet@uunet.uu.net JUNET: utashiro@sra.junet NAME fep - general purpose front end processor SYNOPSIS fep [-emacs|-vi] [-h history-length] UNIX-command DESCRIPTION Fep is a general purpose front end processor applicable to most UNIX commands that features vi(1)- or emacs(1)-like line editing and a command history mechanism like that of csh(1). Choice of editing style is made by selecting either the emacs mode or the vi mode (named for the editors they emu- late), specified either by command line option or by setting a variable interactively or in the start-up file or environ- ment EDITMODE (see editmode variable). The default key bindings are shown below for both edit modes. These can be customized using the fep-bind command. Emacs Bindings Here follow the default key bindings for the emacs mode. Each function name should be self-explanatory. The function names are defined as similarly to Gosling's emacs as possi- ble. ... Vi bindings The vi mode has two sub-modes, the command mode and the text insert mode. The commands of vi are emulated as correctly as possible. Here is a list of the default key bindings of the vi mode that differ from normal vi commands. The tty driver control characters are also inherited in this mode. ... Built-in commands Fep has some built-in commands that are not passed to the child process but understood and processed by fep itself. These commands can be issued from the terminal or from the start-up file. fep-bind function-name key-binding Change key bindings. For example, to bind the func- tion list-file-name to the string "^X-^X", type the following: fep-bind list-file-name "\^X\^X" fep-alias fep-alias name fep-alias name string The first form prints all aliases. The second form prints the alias for name. The last form set the alias for name to string. If you use fep without auto-tty-fix, following alias could be usefull. if $command == sh fep-alias more "fep-command more" fep-alias vi "fep-command vi" endif fep-unalias list Remove alias for each name in list. fep-set variable = value Set a variable of fep to some value. fep-unset variable Unset a variable. fep-cd [ directory ] fep-chdir [ directory ] Change directory. It sometimes happens that a child process has changed directory, but fep is still in the old directory. In such a case, neither list- file-name nor expand-file-name will function as expected. This command allows you to change fep's current working directory (default = home direc- tory). fep-pwd Print fep's current working directory. fep-history [ number of line ] Show the history of commands under fep. fep-echo arguments Only print the arguments. Variable names can be used prefixed by the "$" character. fep-source file Read the specified file and execute it. The con- tents of the file are not sent to sub-processes. fep-save-history [ number of lines to save ] file Save the current history buffer in the specified file. fep-read-history [ file ] Read in the command history from the specified file. The default file is the value of the history-file variable. This file name is understood as a path relative to the home directory. If you want to specify the name relative to the current directory instead, prefix the path by "./". fep-command command fep-! command Execute command. fep-exit Kill the sub-process and exit. fep-suspend Suspend fep itself. In the unlikely possibility that fep falls into a dead-lock in which the sub- processes have stopped but fep is still running, use one of these commands to escape from the situation. fep-read-from-file file fep-< file Read data from specified file and send them to sub- process. The sub-process will read the data from the file as if they are typed at the keyboard. fep-read-from-command command fep-<! command Send output of specified command to sub-process. fep-start-script [ script-file ] fep-script [ script-file ] Start to send input and output to a script file. If script-file is specified, it is used. If not the value of the variable script-file will be used. fep-stop-script Stop scripting. fep-show-bind Print current binding information. Control structures fep-if expression fep-elseif expression fep-else fep-endif Only four control structures are supported but that seems enough. Expression allows only the two opera- tors "==" and "!=". Variables can be referenced by prefixing with the "$" character. Note: The "fep-" prefix of the built-in functions and the above operators can be abbreviated in commands that fep executes from a file. Comment Lines starting with the character "#" are ignored by fep. If fep encounters a comment in interaction, it is sent to the sub-process. In reading from a file, comments will merely be ignored. Variables Fep uses some variables. editmode default: emacs This variable defines the mode for command line editing. Key bindings will be set for the appropri- ate defaults when this variable is changed. Fep first looks at the environment variable EDITMODE, then looks at any command line arguments, and finally reads in the .feprc start-up file. expand-tilde default: on Fep expands "~" to the real home directory name by the expand-file-name function when this variable is set. ignore-empty-line default: on If this variable is set, empty command lines are not saved in the history file. ignore-same-line default: on If this variable is set, command lines identical to the previous command line are not saved to the his- tory file. alarm-on-eof default: on If this variable is set AND the function send-eof is not bound to the eof character AND the variable ignore-eof is not set, an alarm message will be displayed once the first time eof is encountered on an empty line. history default: 100 Fep maintains a history file of the length specified by this variable. savehist default: off If savehist is set fep saves the number of history entries specified by value of this variable in the file named in the variable history-file on terminat- ing. history-file default: .fephistory Contains the name of the history file for reading from and writing to. If the file described by this variable exists, fep will read the file into the history buffer on start up and then save the current session's history when it exits. showhist default: 20 This variable specifies the number of history lines to be displayed by the show-history function. ignore-eof default: off Fep never worries about the eof character if this variable is set. noalias default: off If set, command aliasing won't be done. crt default: 24 If set, more message is shown during printing the key bindings on each number of line specified by this variable. command default: command-name Fep set this variable to the command name of the sub-process when it starts up. shell default: /bin/sh Describe the command name to be invoked by invoke- shell. auto-tty-fix default: on If this variable is set, fep looks at the tty mode of the sub-command, and if the tty mode has changed, fep fixes the tty mode of standard out and sets the transparency flag according to the mode. Since this tty mode check is done about a second after the last input, please wait just one second after entering cbreak mode. If this variable is not set, the automatic tty mode check is not done, so you have to change the tty mode and transparency explicitly using the toggle-transparency function. tty-fix-bell default: off If this variable is set, fep rings the bell when the tty mode is changed. script-file default: fepscript This variable is used by the fep-start-script com- mand and by the start-script function. delimiters The contents of this variable are treated as delim- iting characters for file name expantion and file name list. prompt default: see below Fep outputs a prompt after executing built-in func- tions. The default string is set to the NULL string, but there are some default prompt strings for some common commands such as sh, dbx, lpc, mail, sendmail -bt and calc. However, since fep doesn't care about what program is running, the same prompt is still output when you are executing bc from sh. You can change the value of prompt and other vari- ables in the start-up file as follows: if $command == sh set prompt = "$ " endif Start-Up File Fep executes the file ".feprc" in the home directory of the user if it is found there when starting up. It looks for arguments on the command line first, and only then reads the ".feprc" file, so the file has higher priority. Functions abort backward-character backward-word beginning-of-line delete-line delete-next-character delete-next-word delete-previous-character delete-previous-word delete-to-kill-buffer end-of-line end-script expand-file-name forward-character forward-to-end-of-word forward-word ignore invoke-shell insert-and-flush insert-tab kill-to-end-of-line kill-to-top-of-line list-file-name literal-next mark new-line next-history previous-history reprint search-forward search-reverse self-insert send-eof show-bindings show-history start-script terminate toggle-transparency yank-from-kill-buffer vi-c vi-d vi-edit vi-ins-edit vi-motion vi-new-line vi-num Probably only the function name "toggle-transparency" is hard to understand. This function is provided for entering non-line-oriented tools from a line-oriented tool using fep. Assume a situation where you are using sh(1) with fep, and then invoke vi(1). Since fep intercepts all input for edit- ing, vi cannot work correctly. You can escape from this annoying situation using the "toggle-transparency" function which is bound to the Control-^ key by default. Of course it is also necessary to return to the normal mode after exiting vi. This tty mode fix can be done automatically. If the auto- tty-fix variable is set, fep looks at the tty mode of the sub-command and fixes the tty mode of standard in accord- ingly. This fix is done 0.5, 1, 5, 10, 60 seconds after the last input, so if you enter cbreak mode plase wait just one second. Then you can use vi(1) or any other tool using the cbreak or raw mode. OTHERS Fep can bandle SHIFT-JIS kanji code if compiled with the -DKANJI flag. SEE ALSO newcsh(1) AUTHOR K. Utashiro Software Research Associates, Inc., Japan. UUCP: kddlab!srava.sra.junet!utashiro ARPA: utashiro%sra.junet@uunet.uu.net JUNET: utashiro@sra.junet FILES ~/.feprc, ./.feprc start-up file ~/.fephistory default history file BUGS While working on the program the author sometimes lost his mind, whereupon so did the program.
daveb@geac.UUCP (David Collier-Brown) (07/25/88)
From article <11933@ncoast.UUCP>, by allbery@ncoast.UUCP (Brandon S. Allbery): > ??? Why not just a modified version of gets()? If you're running under > SVR3, you can build a new version of the shlib with the new gets() and > thereby upgrade every program on the system without recompiling! > > -- > Brandon S. Allbery, uunet!marque!ncoast!allbery > For comp.sources.misc send mail to ncoast!sources-misc I've been avoiding this discussion up to now, but... AARGHHHHH! (There, I feel much better). Has anyone noticed that the facilities for composing a fairly-arbitrary stack of facilities into a program is starting to appear in Unix? This is one of the big, hard and time-consuming problems which was carefully, consciously and (I think) wisely left out of PDP-11 Unix... Persons interested in the problem of "where do I put what" are cordially invited to look at the dynamic linking facility of Multics[1] and at its search rules hierarchy. --dave (see below) c-b [1] Multics is dead. Unix is catching up. Sorta. Multics is also a trademark of Honeywell-Bull, who don't make it. -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers Ltd., | Computer science loses its 350 Steelcase Road, | memory, if not its mind, Markham, Ontario. | every six months.
peter@ficc.UUCP (Peter da Silva) (07/25/88)
In article <922@esunix.UUCP>, bpendlet@esunix.UUCP (Bob Pendleton) writes: > From article <1112@ficc.UUCP>, by peter@ficc.UUCP (Peter da Silva): [ description of what you put a poor UNIX box through if you use RAW mode ] > What Peter says is true. BUT, it is not a reason to stop looking for > better ways to do things, or for opposing changes that would make > using separate input line editing processes easier. This is true. In System V the place to put this sort of thing, I guess, would be a streams module. In an ideal world, you would put this in a lightweight realtime process in the realtime operating system you're running UNIX on top of. Even if you give everyone a VAX, you still would be far better off with a realtime kernel that is, itself, a seperate process. For more info, see my articles on comp.sys.amiga where I talk about my fantasy of running UNIX under AmigaOS (which *is* a realtime operating system that supports lightweight processes). -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" (uunet,tness1)!sugar!ficc!peter.
utashiro@sran84.sra.JUNET (Kazumasa Utashiro) (07/26/88)
I apology that I didn't know about ile when I posted my last message about my program, fep, and didn't catch up all messages about this article. I canceled my message as soon as I realized that, but it failed (it seems I canceled a message for cancellation only by my fault... ;-). It was canceled below sra hosts in Junet, gomen'ne. The concept of fep is exactly same as the one of ile, and takes a same position for command line editing. It just provides a little more features; emacs and vi default mode, built-in commands an some parameters for customization, script, binding for any length of strings etc. (and Kanji character handling), and a little bit faster. I assume fep invoked for every command for that user want to use command line editing, usually this can be done easily csh aliasing, and not assume one fep for shell and takes care of any commands' input invoked from it. This method works fine, because fep can keep different history by different file for each command, and user want slightly different mapping for each command (e.g., sometime user want control-D sends eof, and sometime delete current character). While my messages was sent on accident, some people wanted my program, so I'm going to post fep to the net after some brushing up (some feature of ile is looks good). I think posting to comp.sources.unix is better because it is a moderated group. Anyway, sorry for any inconvenient for my last message. Kazumasa Kayo Utashiro Software Research Associates, Inc. 1-1-1 Hirakawa-cho, Chiyoda-ku, Tokyo 102, Japan UUCP: kddlab!srava.sra.junet!utashiro ARPA: utashiro%sra.junet@uunet.uu.net JUNET: utashiro@sra.junet
bpendlet@esunix.UUCP (Bob Pendleton) (07/26/88)
>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.
aegl@root.co.uk (Tony Luck) (07/29/88)
In article <1112@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: >To do it the way you want would basically require all programs to run in >raw mode. This means that now you have: you hit a key, the lower half >driver puts the key in the raw queue. Two context switches. Then your >program wakes up, another context switch. Then it writes the character >to the output stream, two more context switches. Finally your program >goes away to wait for another key. Six context switches, at the minimum. >Plus you execute in user mode. if your program requires swapping or paging >to wake up, it's even worse. Just what proportion of characters get into machines while terminals are in 'cooked' mode these days? In all the editor-wars people spend their time declaring why their particular favourite dialect of EMACS is so much better than VI (or DED, or NED) but very few people seem to stand up and say "But I use /bin/ed all the time because I don't want to subject my poor little computer to all those context switches". More and more programs have fancy "user friendly" interfaces that are invariably character orientated (hands up all those people using 'readnews' to read this? Now a vote from those using 'rn', 'vnews', 'gnuemacs', (does 'notes' run in raw mode?)). Take a database package (UNIFY, INFORMIX, INGRES, any package you like) ... look for the fancy forms input - yes its got the terminal in raw mode. Perhaps you have a word processing package ... bet it isn't line orientated. A spreadsheet, oh look it uses curses and takes input one character at a time. How about games (which is what all these computers are really for anyway). Adventure! wow, cooked mode line at a time. But balance it against the fifty versions of rogue, hack & nethack, moria and most of the other cookies that come off comp.sources.games. Me, I haven't typed a cooked mode character since the machine asked me for my password. Everything I type goes though a window manager. Tony Luck <aegl@root.co.uk>
allbery@ncoast.UUCP (Brandon S. Allbery) (07/31/88)
As quoted from <16553@brl-adm.ARPA> by rbj@nav.icst.nbs.gov (Root Boy Jim): +--------------- | ? From: Gregg Wonderly <gregg@a.cs.okstate.edu> | | ? I just solved that problem here by writing a KSH style history and | ? command line editor subroutine that is called gets(). | | As you no doubt already know, there is already a function named gets(). | How about choosing another name? +--------------- Uh, Jim, given that we're talking about retrofitting smart line editing into existing programs, what's easier than replacing libc.a(gets.o)? (Aside from doing so in a shlib so you don't have to recompile every program on the system?) ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
allbery@ncoast.UUCP (Brandon S. Allbery) (07/31/88)
As quoted from <1112@ficc.UUCP> by peter@ficc.UUCP (Peter da Silva): +--------------- | In article <9677@eddie.MIT.EDU>, nessus@wonko.MIT.EDU (Doug Alan) writes: | > There is another way to guarantee that line editing will be uniformly | > supported. (1) Provide an alternate, and better method. (See my and | > some other's previous articles on the issue). (2) Remove line editing | > completely from the kernal, forcing everyone to use the better method. | | (discussion of context switches required for kernel vs. user mode line | editing deleted. ++bsa) | | this isn't that much compared to what you Athena jockeys already do, but | it'll kill us poor folks with "mere" vax-class machines and terminals, shared | among a dozen users. Interactive response time will go to hell. +--------------- When most of the time the users are in raw mode anyway (database forms programs at most of our client sites; on ncoast it's usually nethack, phantasia, and rn ;-) it's not much of a loss to run the other programs in raw mode as well. And no doubt you've seen the resistance to putting it in the kernel (I once looked over the TOPS-20 manuals; I fully understand why the COMND JSYS wasn't used more often). Modulo stuff like streams modules that will probably get me even more flames from kernel purists.... ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/01/88)
In article <11966@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >Uh, Jim, given that we're talking about retrofitting smart line editing into >existing programs, what's easier than replacing libc.a(gets.o)? No useful program that I am aware of uses gets(), for one thing. You would basically need to provide a slew of input routines, and you'd need to kludge up stuff to make sure that this "smart editing" was applied only to the appropriate data. The whole approach is wrong.
rick@seismo.CSS.GOV (Rick Adams) (08/02/88)
In article <8291@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > No useful program that I am aware of uses gets(), for one thing. While I agree gets() should be avoided, I felt obliged to see what the "standard" UNIX does (V.2 is all I have source for). The following programs use "gets": cpio (which I agree is not useful) cu (I prefer tip, but its a matter of taste) cflow spell (the routine that makes the hash tables) (Berkeley UNIX is untainted) --rick
gwyn@smoke.ARPA (Doug Gwyn ) (08/02/88)
In article <44384@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes: -In article <8291@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: -> No useful program that I am aware of uses gets(), for one thing. -While I agree gets() should be avoided, I felt obliged to see what -the "standard" UNIX does (V.2 is all I have source for). - The following programs use "gets": Thanks for the list. I've added those four utilities to my "TO DO" bug list.
mouse@mcgill-vision.UUCP (der Mouse) (08/05/88)
In article <1988Jul22.203037.9092@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > In article <6339@bloom-beacon.MIT.EDU> tytso@athena.mit.edu (Theodore Y. Ts'o) writes: >> ... We have the line editor built into csh. I maintain this is the >> right thing to do... (I didn't write the >> text, but I might have. We, too, have editing built into the csh, and I too maintain this is the right thing to have done. Not that it's the right ultimate solution, but that it's the right thing to have done, given what we had to start with.) > I trust you have put this into *all* the shells? (Especially since > the name of the shell which is closest to being a Unix-wide standard > does not begin with "c".) No, we don't have it in all the shells. So? Suppose I add a verbose flag to, um, dd. Does this now instantly leave me open to criticsm because I didn't add the same flag to all other programs? > Whatever happened to layers of abstraction? Not workable at present. Ideally, input editing should be divorced from the shell. *However*, - The input editor must know whether it's talking to the shell or not. Primarily to keep input histories separate, secondarily to shift command sets (I, for example, want ^P as previous-line-of-history in the shell but SIGTSTP when running a program). - The input editor must go away when the tty is in raw or cbreak mode. This means one ioctl per typed line in cooked mode (bearable) or per typed character in raw or cbreak (possibly bearable, but also possibly not). - When speaking to the shell, the input editor must have access to things only the shell knows. In particular, the shell's current directory, its current set of shell and environment variables and any bind commands that have been issued since the shell started. None of these are insurmountable, given unlimited time to hack the kernel (or extensive hacks to the shell, which amounts to merging the shell and the input editor - see below). However, very few, if any, of us have this luxury. And the only other programs we spend substantial time typing at are editors, for which input line editing is inappropriate (for those (few?) who use ed, there *is* ile). Stop and think about it. Are there any programs, besides the shell and editors, that you spend much time typing to? Of those, are there any that do line-at-a-time input (as opposed to screen-oriented programs like less, rogue, or hack)? There certainly aren't in my case. Now. Tell me again, why was it wrong to put input editing into the csh? It solves the problem in a manageable amount of time, without creating worse problems. The only alternative I see is to build the facilities of ile into the shell, so it is not only a shell but also a full input editor for executed commands. This may be workable, but I suspect the use of a pty when unnecessary (eg, editors) will impose a sometimes-unacceptable performance hit. But if you want to try it, feel free - a good shell rewrite plus general input editor would be a very nice thing to have around. der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu