Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

From: Quentin Rameau <quinq_AT_fifth.space>
Date: Mon, 27 Mar 2017 23:11:05 +0200

> Hi there,

Hi,

> On 27 March 2017 at 12:11, Laslo Hunhold <dev_AT_frign.de> wrote:
> > On Sun, 26 Mar 2017 20:06:57 +0000
> > Cág <ca6c_AT_bitmessage.ch> wrote:
> >> I am genuinely interested why.
> > in my opinion, it's an unnecessary component given I use terminals
> > within dwm 99% of the time. I don't need a terminal multiplexer when
> > dwm multiplexes my terminals for me. I know it's "nice to have" to
> > be able to attach to tmux sessions, even over ssh and such. But to
> > be honest, for my use case (!), I just don't need it. For the rare
> > case I need more than one terminal open, even over ssh, I just open
> > another terminal and fire up ssh a second time in the latter case.
> [..]
> > If we discuss scrollback support in st, we should look at it from
> > another perspective. In the end, st is a window which can be
> > resized, and also the font size can be changed. By the mere
> > definition of that, one should expect the program to behave
> > "isomorphically" under these conditions. Every operation of this
> > nature should be reversible. To be honest, currently it's close to
> > stressful to use st without any terminal multiplexer, because you
> > constantly have to watch out _not_ to resize the master when a
> > certain terminal with important information is present. I am sure
> > everyone knows what I'm talking about, and this is
>
> nevertheless I do think that all this still doesn't justify a
> scrollback buffer built into st itself. Instead of mandating the use
> of tmux et al, I would rather put a helper tool into the st repo, that
> works as a basic shell wrapper process (no detaching). It would
> implement the scrollback buffer only and allow to define its size in a
> more flexible way (possibly via a command line argument) and also the
> control sequences / key combos to actually scroll around. The tool
> name could be stsb or something similar.
>
> What do you think about this compromise?

This is actually something that has been discussed for some time now
and we agreed this is the way to do it (in view of st).

But nobody really took the time to go for it yet, although emg have a
rough one he started working on a few months ago, but I think he didn't
really have time to continue on it.

So if somebody feels up to the task, and done right, it'll be gladly
accepted alongside st.
Received on Mon Mar 27 2017 - 23:11:05 CEST