>From the length of your description I would guess this solution would be pretty complicated to implement.
On Sun, Nov 1, 2009 at 8:01 PM, John Yates <j...@yates-sheets.org> wrote: > On Sat, Oct 31, 2009 at 4:52 AM, John A. Grahor <j...@techma.com> wrote: >> I'd like a terminal emulator that has a "dumb" terminal mode, i.e. where >> line editing can happen locally and what one types is only sent to the tty >> when one hits return (or some other key). > > Two decades ago I fell in love with Apollo Computer's solution to this > problem. A terminal window was broken into two "panes": > > 1) an editable input pane > 2) a read-only transcript pane > > The two panes were separated by a full window horizontal line or rule. > The input pane never shrank to less than one line but could also > steal lines from the transcript pane until it grew to a specified > fraction of the input window (typically 1/4). The input pane had two > modes of operation with an icon on the title bar to indicating which > mode was in effect. I cannot recall the actual names so let me just > call them "connected mode" and "disconnected mode". In > > In connected mode type ahead hung around in the input pane until a > program running in under that terminal window issued a read from > stdin. When that happened a single line of input (i.e. up to a > newline) was passed from the input pane to the requesting program. > That input line disappeared from the input pane, the program's prompt > (if any) appeared in the transcript followed by the input line just > delivered. In essence the input pane was simply a visible > representation of unconsumed type-ahead. > > In disconnected mode type ahead input again hung around in the input > pane. This time though when a program running in the terminal window > requested input its prompt would appear in the transcript pane but no > user supplied input would be delivered until the input pane reverted > to connected mode. At that point the oldest input line would > disappear from the input pane and would reappear following the prompt > in the transcript pane. > > What made this mechanism so pleasant to use was that all text areas in > the screen (editing buffers, input panes, and output transcripts) > shared a common set of editing key bindings, similar to vi or emacs. > A very common idiom was to list a directory, switch the input pane to > disconnected mode, copy the directory listing to the input pane, > modify that copy of the listing using some regular expression > substitutions to turn it into one or more commands on each file, and > revert the input pane to connected mode. Obviously in any *nix > environment one can do the same thing by redirecting the output from > ls to a file, open that file in an editor, modifying it, saving it, > and finally sourcing the edited file in one's shell. The input pane > mechanism simply made such operations faster and more intuitive: no > inventing a file name, no opening a separate editor, no issuing a > source command to one's shell. > > /john > >
