Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!bbn!mit-eddie!wonko.mit.edu!nessus From: nessus@wonko.MIT.EDU (Doug Alan) Newsgroups: comp.unix.wizards Subject: Re: Input Line Editing Message-ID: <9675@eddie.MIT.EDU> Date: 14 Jul 88 04:52:38 GMT References: <16456@brl-adm.ARPA> <9666@eddie.MIT.EDU> <59697@sun.uucp> Sender: uucp@eddie.MIT.EDU Reply-To: nessus@athena.MIT.EDU (Doug Alan) Organization: Kate Bush and Butthole Surfers Fandom Center Lines: 127 >> [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".