Re: [dev] TermKit

The input box should handle binary streams, buffered input, file contents and editing line with special program.

All this can be done by running another st with vim f.ex

This sounds to me like replicating work.. A microwm.. 2 terminals.. Keyboard handling for switching modes.. We will make then an extended dmenu with multiline support? This requires a bit of rethink

About the canvas I am also interested as long as its similar to swk. My widgets library

On 20/05/2011, at 16:27, Kurt H Maier <karmaflux_AT_gmail.com> wrote:

> On Fri, May 20, 2011 at 10:19 AM, Connor Lane Smith <cls_AT_lubutu.com> wrote:
>> I just think the stdout and stderr ought to be visible at the same
>> time. Or perhaps it would suffice to show stderr above stdout, or
>> automatically switch, or something.
>
> I agree stderr ought to be visible. I picture either a smaller window
> at the bottom of the terminal for that, or else a keyboard combination
> that switches the output window over to stderr. You could have a
> little dwm microcosm where stdin/stdout/stderr window groups are
> tagged with history entry numbers. Windows could be tagged e.g.
> 104out and 104err... if you wanted to overengineer things. I much
> prefer the idea of one input pane, one output pane, and one error
> pane.
>
>> That sounds good to me. And you could head each 'output box' with the
>> command which produced it. (Though numbering could be useful too.)
>
> My thought is you could type an entire shell script into the input
> box, so heading the output with e.g. a 15-line script would get
> cumbersome. There's no reason not to just save the command in the
> input window and tag the output with its entry number. You could even
> select a history entry to be re-entered into the input buffer for
> further editing, run the new version, and then cause the terminal to
> save both versions of the output so you could diff them.
>
>> I'm considering writing a 'next gen' 9term, if you'll excuse the
>> expression, and these ideas (a terminal 'canvas', and separated
>> streams) sound like they would be a very nice fit.
>
> I've been thinking about a separate-streams terminal for a long time;
> I'd love to see what you come up with.
>
>
> --
> # Kurt H Maier
>
Received on Sat May 21 2011 - 00:55:50 CEST