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

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 <john_AT_yates-sheets.org> wrote:
> 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:45:01 UTC