Re: [dev] [st] a real (I think) feature request

From: John Yates <john_AT_yates-sheets.org>
Date: Sun, 1 Nov 2009 14:01:06 -0500

On Sat, Oct 31, 2009 at 4:52 AM, John A. Grahor <jag_AT_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
Received on Sun Nov 01 2009 - 19:01:06 UTC

This archive was generated by hypermail 2.2.0 : Sun Nov 01 2009 - 19:12:02 UTC