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

From: Anselm R Garbe <garbeam_AT_gmail.com>
Date: Mon, 27 Mar 2017 22:00:43 +0200

Hi there,

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?

-Anselm
Received on Mon Mar 27 2017 - 22:00:43 CEST

This archive was generated by hypermail 2.3.0 : Mon Mar 27 2017 - 22:12:13 CEST