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

From: Alexander Krotov <ilabdsf_AT_gmail.com>
Date: Tue, 28 Mar 2017 00:52:03 +0300

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 <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?

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.
Received on Mon Mar 27 2017 - 23:52:03 CEST