Re: [dev] tmux/screen alternative

From: Raphaël Proust <raphlalou_AT_gmail.com>
Date: Sun, 23 Feb 2014 12:13:01 +0000

On Sat, Feb 22, 2014 at 1:49 PM, Anselm R Garbe <garbeam_AT_gmail.com> wrote:
> On 22 February 2014 14:42, Anselm R Garbe <garbeam_AT_gmail.com> wrote:
>> On 22 February 2014 14:37, Markus Teich <markus.teich_AT_stusta.mhn.de> wrote:
>>> Anselm R Garbe wrote:
>>>> All I want is to have full logging of all output when building various stuff,
>>>> now stali related stuff.
>>>
>>> I would just pipe it to less.
>>
>> I rather want persistent logs. And I want it implicit. Sometimes I
>> realize, oh dang, what was printed before and then it's too late
>> already to launch less ;) Actually this is the main reason for a
>> scrollback buffer IMO, it'll be only used if you forgot to pipe the
>> output somewhere...
>>
>> Back in the older days, I actually intended towards a totally
>> different st design as it is today. Originally it was planned to
>> define a new client/server model, where st would've been just a client
>> with an own formatting language to a st server. The st server was
>> intended to provide full persistent logging and filter programs for
>> the different terms that it would have translated into the st
>> formatting instead.
>>
>> Nowadays st is just a simpler terminal ;)
>
> Having said this, when I discussed with uriel about it several years
> back in time, we really thought it to allow attaching to the same
> terminal from various st clients, so taking terminal multiplexing a
> bit further. We also envisioned that it could replace ssh and remote
> shell hacks at some point, as an st client would define a saner
> interface than escape sequences and termcaps/terminfos. All the ugly
> task would have been down to the filter in between which must be aware
> of the actual escapes and translating them into the st formatting
> language.

This is very interesting. The main complaint I have towards dtach(1)
(I have the same complaint about screen(1) and tmux(1), but for those
it's not the *main* complaint) is the need to first ssh into an
interactive session. I'd like to do `dtach -a
<user>_AT_<remote>:<path-to-session>`.


>
> Perhaps this will be achieved in the future. The st formatting was
> also thought to provide a "text mode" like interface, but a
> *graphical* one. As most people do use graphical environments these
> days...
>
> I hope this sheds some light into the direction I'm looking when
> asking those really basic questions ;)

Relevant to this discussion: http://lubutu.com/idea/ivo


Cheers,
-- 
______________
Raphaël Proust
Received on Sun Feb 23 2014 - 13:13:01 CET

This archive was generated by hypermail 2.3.0 : Sun Feb 23 2014 - 13:24:06 CET