1) There are no standards
2) The problem happens when someone wants to add something new to the terminal ecosystem.
2a) Designing something becomes harder because it has to be designed to work with the horrible hack that is terminal multiplxer. The tty model is dead simple, one tty per child process. When you add a terminal multiplxer it completely confuses this simplicity, making it instead multiple processes per tty and does it in a way that is opaque to both the processes and the host terminal, leading to endless bug and incompatibilities.
2b) Any new feature is now gatekept by the individuals in charge of the multiplexer projects.
I don't agree with this. There are tons of standards (even if it's de-facto) from VTxxx to XTerm's emulation standards. If there were no standards, it wouldn't be possible to talk with a modern system using a real VT320 (Yes, we have these), or with a vintage system with a modern terminal over a TTYUSB device.
> The problem happens when someone wants to add something new to the terminal ecosystem.
I understand, but every decent standard should take what's done before them and be prepared to face with it. Let it be Ethernet, TTY, even something modern like DisplayPort. When people doesn't do their due diligence and spend the time required to handle edge cases, things are bound to break (e.g. Cheap monitors' firmware contains identical serial numbers, causing all types of shenanigans in multi-monitor setups).
> 2a) Designing something becomes harder because it has to be designed to work with the horrible hack that is terminal multiplxer.
For harder part, see the previous paragraph. i.e.: One should do their homework to work with other systems. On the oh gawd horrible hack! part, That "horrible hack" is saving hours of work per month per person who work with remote servers for ~30 years now, and nobody is planning to give them up AFAICS.
> The tty model is dead simple, one tty per child process. When you add a terminal multiplxer it completely confuses this simplicity, making it instead multiple processes per tty and does it in a way that is opaque to both the processes and the host terminal, leading to endless bug and incompatibilities.
Maybe one should draft a new standard about multiplexing terminals persistently without it being a hack? There's a big gap there, as you point out.
> 2b) Any new feature is now gatekept by the individuals in charge of the multiplexer projects.
Both screen and tmux are maintained properly, and they fix the bugs they cause actively. For example, screen was causing a problem in SGR mode, and they fixed it 2 months ago [0].
Oh, on SGR; it's an ECMA Standard. Standard-48 to be more precise [1]. So, again, there are standards, and you can build new ones, and I bet, terminal multiplexers will play along if you don't throw eggs at them.
A de-facto standard is not a standard. It's an opinion.
I suggest you go plug a VGA cable into a DisplayPort and see what happens.
The horrible hack is saving you and the few other very loud people that use it hours of work. I for instance have been using remote servers for 40 years without ever needing a multiplexer. They have always been, and remain, horrible hacks that I rejected when I first came across them and that have been a drag on the entire terminal ecosystem for 30 years. Thankfully they are finally on their way out, thanks to a new generation of terminal emulators and are using the tty the way it was designed to be used.
The new standard is the old one. Use the tty as it was intended and designed without a horrible hack in the middle. And if you really need remote persistence via a multiplexer of all things, then use one provided by the terminal emulator you use so that it integrates natively, seamlessly and correctly with the terminal emulator. Granted currently only WezTerm provides such a multiplexer, kitty for instance instead multiplexes SSH access via SSH control masters. But its developer has indicated he will someday write a tmux replacement that is kitty native.
Oh and on SGR it is an ECMA standard, only in the breach. For example, color support as it is actually used in terminals violates the so called specification.
> A de-facto standard is not a standard. It's an opinion.
OK. Let's look what happened some of these opinions.
- PDF became two different ISO standards.
- USB started as a de facto charging port, became de jure in EU.
- DMX, MIDI, DE-9 RS232 connectors are all de-facto standards, but used as de-jure now.
- Tons of file formats in scientific and engineering computing is in fact de-facto standards, yet they flourish.
So, it's meaningless whether a standard is de-facto or de-jure. If it looks/walks/sounds like a duck, it's a duck.
> I suggest you go plug a VGA cable into a DisplayPort and see what happens.
I use something similar to this [0]. It works.
> The horrible hack is saving you and the few other very loud people that use it hours of work.
I love how you liberally throw the h-word around. Because horrible hacks became conventions over history. Vi's latency hiding can be considered "a horrible hack", or "brilliant" depending on the perspective. Same can be said for HDMI for example. Piggybacking on DVI for video signalization, adding a couple of digital lanes for sound and Ethernet, it can be considered a horrible hack, yet it's a de-jure industry standard. IOW, someone's opinion, just in a written form with some stamps and a logo.
From my vantage point, people not using terminal multiplexers (tmux/screen) are a shrinking minority, yet from your perspective it's the opposite. Considering the oh gawd horrible terminal multiplexers are still maintained, and I still initiate people on screen or show them tmux as a screen alternative, I don't see they're going anywhere. Your perspective may differ. I'm mostly talking about younger generations, I may add.
> I for instance have been using remote servers for 40 years without ever needing a multiplexer.
I think you're lucky for not having to debug things on the go, for days, or managing servers on a responsive and stable network. I sometimes have no luxuries, so I have to use horrible, horrible hacks to get things done. It works brilliantly unfortunately. Shame on me.
> I rejected when I first came across them and that have been a drag on the entire terminal ecosystem for 30 years.
That's a long grudge to hold. I'm sure it's not the only one. Think about your health. No it's not meant to snark. I'm honest.
> Thankfully they are finally on their way out, thanks to a new generation of terminal emulators and are using the tty the way it was designed to be used.
I don't see it's happening, sorry. What I see is more hacks are piled upon hacks. Some might stick and become standards, some might die.
> Granted currently only WezTerm provides such a multiplexer...
Wezterm's multiplexer is a regular old multiplexer which connects to a remote wezterm instance. IOW, just a different transport which encapsulates a WezTerm instance. There's nothing magic here. It's moving the hack to another layer. Now there are two transports, and Wezterm's one is not interoperable with others. So it's a really horrible hack from my perspective. If something is not interoperable with other tools, then it's out for me. I can't be bothered to install Wezterm to all and every server I work with. Which is >1000.
Unfortunately, I have the luxury of choosing the terminal which I want to work with in any circumstance. As long as I can connect to my remote server, my persistent workspace is there. I don't need a local Wezterm to be able to work.
> ...without a horrible hack in the middle.
Wezterm puts the horrible hack on top. Like a cherry. Bright and eye-catching, in a bad way.
I read the bug report. I think the problem is the approach. If somebody is so adamant in a feature, and the maintainer doesn't want to add that feature, a) you can patch it yourself, b) you can fork and patch it yourself. It's free software. The tmux maintainers doesn't owe you anything. I bet, if you send in a nice patch, they won't ghost/reject you.
BTW, a mux is just another terminal emulator inside your terminal. It's not more of an hack compared to an ncurses window, or old graphic interfaces in UNIX systems.
> Oh and on SGR it is an ECMA standard, only in the breach.
Many standards are flexed. Many graphics cards do not fit inside the PCIe mechanical standard, for example, but they work.
> For example, color support as it is actually used in terminals violates the so called specification.
My terminal has fallbacks for a lot of modes. This is what backwards compatibility is for.
> Complete and utter drag on the ecosystem.
Sorry I don't see/feel it for the last 20 years.
So, in short, I agree to disagree, and genuinely wish more power to you in your endeavors. There are no hard feelings here, just tone-matching.
Hope to have a longer chat and have the opportunity to learn from each other.
I'm going to ignore the personal attacks since you seem to want to genuinely learn something.
1) The difference between WezTerm's multiplexing and say tmux, is that wezterm's multiplexing supports all the same features/bugs/syntax and quirks as WezTerm itself. It does not have to translate between what it gets from an unrelated terminal implementation that it has only the most superficial information about to its own internal representation and back, which is what a multiplexer like tmux has to do. Tomorrow if Wez decides to add a new feature to WezTerm, he can add it to his multiplexer at the same time. Thus, the WezTerm multiplexer is a) much more robust than tmux b) not a drag on the entire ecosystem since nothing other than WezTerm itself depends on it implementing anything.
And therefore, unlike tmux, it is not a horrible hack.
To put it another way, tty's are sufficiently complex that multiplexing if needed at all, must be done by the terminal emulator, not an unrelated third party sitting in the middle. You say a multiplexer is another terminal inside the first, I say that is precisely the problem. It is an incompatible terminal emulator.
I wouldn’t call it “breaking standards” as much as “introducing new standards”.
The protocols introduced by Kitty, like the Kitty Graphics Protocol and Kitty Keyboard Protocol, were sufficiently well-documented that other modern terminals (e.g. WezTerm) have adopted them as well. Moreover, both protocols offer advantages cf. the modifyOtherKeys and Sixel standards used by e.g. xterm.
Both are actively maintained and can work with modern terminals, as long as the hosting terminal is standards compliant.
I don't understand why people love to break standards.