Re: [dev] Scrollback utility for use with st

From: Laslo Hunhold <dev_AT_frign.de>
Date: Sun, 5 Apr 2020 23:45:19 +0200

On Sun, 05 Apr 2020 16:52:15 +0200
"Silvan Jegen" <s.jegen_AT_gmail.com> wrote:

Dear Silvan,

> Yes, the scrollback buffer can be implemented by a different tool like
> tmux for example. That's why this functionality is not implemented in
> st from what I understand. Separation of concerns and so on.
>
> I can see why it is inconvenient but personally I have never applied
> the scrollback patch to st and I have been using st for years. If the
> patch would be added to mainline, I would definitely use the
> scrollback buffer, though it would also increase the SLOC count for
> functionality that arguably should be handled elsewhere.

I'm all for the Unix principle, but scrollback really doesn't add any
overhead when comparing it to a separate program running on top of it.
What is often forgotten is that software like tmux/dvtm/scroll end up
almost recreating a terminal emulator themselves, and this is pretty
sucky in my opinion.
Sure, go ahead and run it, but this is neither efficient nor
straight-forward. One might think about auto-launching tmux/dvtm/scroll
in st every time it starts, but then you just have one smart and one
"dumb" terminal emulator stacked upon each other.

Let's ask ourselves this: Is there any reason to run st without a
scrollback buffer? I see none, to be honest, because the additional
memory usage is miniscule. More specifically, I see no reason to abide
the UNIX-principle and modularize things when the modularization
provides no benefit. You can still run tmux and others just fine when
the terminal has a scrollback buffer and even set the buffer-length to
0 if you're really puristic and want no extra memory-overhead.

Now think of the disadvantages: A terminal emulator has one job:
Interface between the tty and the user. If you have to run additional
software to make this terminal emulator fully usable, then this terminal
emulator is flawed.
Two things really annoy me about "vanilla" st, which is sad, because
it's a really really good terminal emulator apart from that:

 1) No scrollback buffer: Of course, I could use tmux/dvtm/..., but
    I see it as unnecessary overhead. I want to open a terminal and
    expect full functionality; terminal-tabbing should be the job of
    the wm, not some software running within the terminal
    I know many here have a fluid tmux workflow, I don't and have never
    gotten used to it.

 2) st-window-resizing is not idempotent: It cuts lines off, which is
    a huge problem in my opinion, especially in the context of dwm.
    tmux et. al. fix this, but I'm talking about vanilla-st here.

Keep in mind, there is miniscule overhead to support both in st.
Sure, it adds 50-80 LOC, but that would be worth it in my opinion. The
Unix principle mandates flexibility, but it should not swing the other
way that a tool becomes so "flexible" that you need to, by hand, create
an ecosystem around it so it works as expected.

This is just my personal opinion. I know that many others here have
a different perspective on this, but philosophies differ. I would've
probably spent some time to write a patch regarding both aspects, but
I'm almost certain it would never be mainlined. Is there anybody else
interested in this functionality and a patch?

With best regards

Laslo
Received on Sun Apr 05 2020 - 23:45:19 CEST