Re: [dev] Scrollback utility for use with st

From: Silvan Jegen <>
Date: Mon, 06 Apr 2020 08:48:38 +0200

Dear Laslo

Laslo Hunhold <> wrote:
> On Sun, 05 Apr 2020 16:52:15 +0200
> "Silvan Jegen" <> 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.

I honestly never use tmux either. If I think I may need the output of
a program, I just redirect it to a file/editor/pager.

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

I have been using st all this time even with those issues that I also
think are annoying. The workaround for the first one is to just redirect
output but I never found a workaround for the second issue. I always have
to remember to not resize the st window (or rather, rearrange it in dwm)
when I may still need the output.

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

Issue 2) I would be glad to have fixed. If a patch to fix both issues
would only cost us 50-80 LOC, I feel it may be worth it. I am quite sure
there will be differing opinions on this...


Received on Mon Apr 06 2020 - 08:48:38 CEST

This archive was generated by hypermail 2.3.0 : Mon Apr 06 2020 - 09:24:09 CEST