> Kovid Goyal, developer of the ePub powerhouse calibre and my current teminal emulator of choice Kitty, has gone on record a number of times saying he is not a fan of tmux. He has a whole section in his FAQ about it:
>> [T]erminal multiplexers are a bad idea, do not use them, if at all possible. kitty contains features that do all of what tmux does, but better, with the exception of remote persistence.
Bit funny, most of the time I’m running tmux in kitty (or ssh in kitty to a server with tmux).
Remote persistence is a pretty massive deal, though.
In general, I don’t like getting attached to a terminal emulator, and mostly just try to avoid using any unique features they’ve got. If a terminal emulator and a command line program are competing for doing a task, the terminal emulator in some sense has an unfairly high hurdle to pass: if I become dependent on the terminal emulator to do it, then I can’t replace the terminal emulator without also getting a new muscle memory for that task, if I ever want to switch terminal emulators.
Which means it has to do that task so much better than the command line program that the delta is worth more than any possible improvements from switching terminal emulators. Kitty is a great terminal emulator but this is an absurd and basically unfair bar that it could never pass.
In this case, though, it is actually worse than tmux because it can’t offer the best thing terminal multiplexers do: remote persistence, which is the killer feature.
kitty seems to be a relatively more opinionated terminal compared to other terminals. The first time I heard about kitty was via a comment about not implementing Sixel support:
"Terminal multiplexers are a bad idea" sounds just like Sixel being "an inferior graphics protocol", and Sixel is probably another example of "worse is better".
I have trouble laying that at the feet of Goyal, who was not really interested in the feature, but who was willing to provide feedback and appeared willing to accept a patch.
The person working on the patch decided that they didn’t think the sixel library (which they were the maintainer of, so they presumably had a well informed opinion) was up to the task.
The description of sixels as inferior also came from the person working on the patch.
You can add this to the enormous pile of open source forks that didn't survive long enough to have any real value to the industry.
I respect that Goyal has been bitten by this dynamic before and said this back in April 2020:
> That said, I wont refuse a patch to implement it on top of the existing graphics support, provided I was reasonabl confident the person implementing it would stick around to maintain it as well.
It's not like Goyal doesn't accept any patches [1].
I don't use kitty myself, but many people who do seem to love it. I've come around to feel that this is truly a maintainer's judgment call. After all, they are almost always stuck maintaining the code no matter who wrote it initially, and they know better than anyone else what code they're personally comfortable maintaining.
More generally, if you like a piece of software enough, you're implicitly trusting the maintainers' judgment. You're certainly not reviewing every single line of code they write to see if you agree with it. If they betray your trust enough then you move on, but if you keep using the program then the maintainers' judgment was right enough.
The miserable survival rate of hostile forks also demonstrates that even if people care enough to fork over one issue, they rarely care enough to maintain the overall project long-term, despite implicitly asking the original maintainers to do the exact same thing.
to be fair, sixel is definitely worse than Kitty Graphics Protocol by literally every metric and sixel has 1/10th of the capability (like z-index, gif/video support, transparency, speed, color depth, X-Y placement, etc...)
I wouldn't say sixel is worse is better, since that would imply it had general success. Drawing with block characters/braille characters is worse is better.
>> [T]erminal multiplexers are a bad idea, do not use them, if at all possible. kitty contains features that do all of what tmux does, but better, with the exception of remote persistence.
Bit funny, most of the time I’m running tmux in kitty (or ssh in kitty to a server with tmux).
Remote persistence is a pretty massive deal, though.
In general, I don’t like getting attached to a terminal emulator, and mostly just try to avoid using any unique features they’ve got. If a terminal emulator and a command line program are competing for doing a task, the terminal emulator in some sense has an unfairly high hurdle to pass: if I become dependent on the terminal emulator to do it, then I can’t replace the terminal emulator without also getting a new muscle memory for that task, if I ever want to switch terminal emulators.
Which means it has to do that task so much better than the command line program that the delta is worth more than any possible improvements from switching terminal emulators. Kitty is a great terminal emulator but this is an absurd and basically unfair bar that it could never pass.
In this case, though, it is actually worse than tmux because it can’t offer the best thing terminal multiplexers do: remote persistence, which is the killer feature.