guido@piring.cwi.nl (Guido van Rossum) (08/03/89)
Doug Gwyn writes: >The terminal shouldn't know what a "command line" is. Therefore it >shouldn't be making this distinction. I snarf&barf text freely between >editor displays, command lines, and other text sources/sinks all the time. I thought we were talking about command line history here, not about general cut&paste (I assume that's what you call "snarf&barf"). Of course, there should be a way to copy&paste anything on the screen (or from the scrollback buffer, for that matter). But command line history is a more specialized feature, which recognized that you are much more likely to type commands that are similar to ones you typed earlier. It therefore remembers previous commands even when they have long disappeared from the screen or scrollback buffers, and offers a specialized interface to access them quickly. The ideal history mechanism sits somewhere between the terminal and the application; it should see lines exactly as they are input by the application. If the application is not reading text on a line-by-line basis, the history mechanism should be clever enough not to store those bits of input; in Unix, cbreak or raw mode would be a reasonable hint. Unfortunately, the best history mechanisms I've seen get their leading edge from knowing the input syntax of the application (usually a shell) and are thus less easily generalized. Come to think about it, the only other type of program for which I still use a command line interface (as opposed to a vi-, Emacs- or X11-style interface) are debuggers. Are command line interfaces going out of style? -- Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam guido@cwi.nl or mcvax!guido or guido%cwi.nl@uunet.uu.net "You're so *digital*, girl!" -- Neneh Cherry
daveh@marob.masa.com (Dave Hammond) (08/12/89)
In article <8307@boring.cwi.nl> guido@piring.cwi.nl (Guido van Rossum) writes: >application; it should see lines exactly as they are input by the >application. If the application is not reading text on a line-by-line >basis, the history mechanism should be clever enough not to store those >bits of input; in Unix, cbreak or raw mode would be a reasonable hint. There was a program previously posted to comp.sources, called ILE (Input Line Editor?), which does just that. As I recall, it sat on A pty (or socket?) line, providing editing/history in cooked tty mode, and keeping out of the way in raw/cbreak mode. -- Dave Hammond daveh@marob.masa.com