Comment by tombh
3 days ago
Yes, every GUI terminal manages its own scrollback buffer. The reason that Tattoy and tmux have their own buffers is because they are essentially terminal emulators themselves. For instance a terminal emulator may have 10 tmux panes and it should of course be possible to view the history of each one. Tattoy manages its own scrollback because that's the only way to make the scrollback available programatically to other processes, like the minimap for example.
Interestingly Alacritty in the beginning didn't natively support scrollback because it wanted to hand-off that concern to multiplexers like tmux. So there's precedent for terminals emulators not having to support scrollback.
tmux should work fine in Tattoy, the only thing to be aware of is that Tattoy would then handle input, like for scrolling etc, so some events may not reach tmux, in which case you could make some custom tmux keybindings that Tattoy doesn't recognise. It's also worth noting that Tattoy recognises the so-called "alternate screen" state that tmux controls its host with. And in such cases Tattoy forwards scrolling events to the underlying process, like say the mouse scroll wheel.
I don't have any light theme examples yet. It should mostly just work though.
my first attempt at using a light theme with gnome-terminal gets me white on white either in the prompt or on the commandline itself. don't have time to debug that now though.
what i was wondering is how the scrollback of tattoy and tmux would interact. normally when you use tmux the terminals scrollback remains unused (which is why alacritty devs thought they don't need their own). but from how tattoy uses the scrollback, i feared that tmux would actually interfere with some tattoy functionality. that's what i am curious about.
Oh white on white isn't good, sorry about that, I'll look into it.
I also have some ideas to make Tattoy into a multiplexer. I really like the idea of desaturating and fading unfocussed panes.