On Mon, Mar 27, 2017 at 10:00:43PM +0200, Anselm R Garbe wrote: > 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?
As Laslo Hunhold suggests down the thread, this solution is likely to be more complex. To implement it properly, you have to implement a whole VT inside of stsb, because it has to pass mouse events down and keep track of character attributes. ncurses programs will output all kinds of "move cursor here" and "change color" control sequences, but you can't just pass them again to st when you need to scroll around. You have to take your virtual state of the screen and render it in your own way, adapting it to current viewport. Well, you can delegate rendering to ncurses, but state machine which tracks screen state will just replicate terminal emulator functions. In the end, you will have a stripped down dvtm, with vt but without multiplexing. Before we discuss scrollback, I suggest to decide on maxcol patch (and apply comment fix btw). After that, I can proceed with implementation of scrollback based on ring buffer. If it makes code simpler (by removing line shuffling, allocation and deallocation in tresize), it may be integrated into st. If not, it will be just another patch.