Hi there, On 27 March 2017 at 12:11, Laslo Hunhold <d...@frign.de> wrote: > On Sun, 26 Mar 2017 20:06:57 +0000 > Cág <c...@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