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

It reminds me of your typical IRC client. transcript above and one line
of command at the bottom.

hiro wrote:
> 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 Mon Nov 02 2009 - 15:15:51 UTC