Dear Laslo Laslo Hunhold <d...@frign.de> wrote: > On Sun, 05 Apr 2020 16:52:15 +0200 > "Silvan Jegen" <s.je...@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.
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... Cheers, Silvan
