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

i remember that scrollz was implemented in this way. splitting the logic
of the
interface (prompt+readonly scrollable text area) in a separate program
managing the stdio/out/err of another application.

i would love to see this usable for ii or many other shell applications

Robert C Corsaro wrote:
> 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:23:47 UTC