aumerle

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.

The kitty protocol not supporting your stupid made up usecase does not make it non-comprehensive, despite your claims.

I didnt do the table go ask the kitty developer why he did that. Or just read the notes under the table where he tells you why he included alacritty+tmux.

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.

As for multiplxers playing along, here you go: https://github.com/tmux/tmux/issues/1391

Complete and utter drag on the ecosystem.

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.

First I dont know what table you are looking at, but its 54MB/s vs 24 MB/s on average across different data types. That's a factor of 2. Aka half the throughput. I dont know what kind of performance engineering you do, but a halving of throughput is a pretty serious performance regression where I come from.

Also, latency is not a direct function of throughput. The two are separate. In this case the latency will come because when you have tmux in the middle it means your command line program writes to a pipe, which is a buffer in the kernel. tmux then has to read from that pipe, then it has to process that byte updating its internal state, then it has to generate the output bytes based on the internal state, those output bytes are written to another pipe, and finally the terminal reads from that second pipe.

There is a whole extra pipe with associated context switches for every byte (or more accurately every packet since reads/writes on a pipe are buffered). This will add latency for example for every keystroke no matter what the throughput numbers are. A pipe operation requires a poll on the pipe fd which is a context switch. Apart from whatever internal processing tmux does, there are four extra context switches added for every keystroke + response.

[flagged]

Keystrokes!! Way to come up with a strawman. Every byte that the program running inside tmux send to the terminal has to be parsed and re-interpreted by tmux first and then the actual terminal. Same for every byte that the terminal sends the program running inside it. These include every byte used to redraw the screen, which with modern full screen applications like editors can be several kilobytes per screen refresh. Keystrokes indeed. This reduces throughput by a factor for 2 at a minimum, reference: https://sw.kovidgoyal.net/kitty/performance/#throughput see the table entries for alacritty vs alacritty+tmux. And that is just throughput, tmux will affect latency as well, though I dont have a reference to measurements handy at the moment.

Nope, that's an update notification not an update. And its opt-in if you use kitty via a distribution package and opt-out if you use the standalone kitty binaries distributed by the developer. See https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.update_check...

> I'm not saying that, it's something you've made up for your inner rofls.

Says you. And as you have abundantly demonstrated, you are a moron.

>No, that's nonsense and factually wrong. Common sense is that a different modifier key is still a different modifier key even if the modification is the same. You have to do some logic twists not to make it so. Also, this is factually wrong: they don't modify the action in exactly the same way, that depends entirely on your config. In mine they act differently

ROFL more idiotic assertions.

> But your overly confident overly broad statements weren't platform limited. So how are your links to the backward platforms / gui frameworks relevant? I've already acknowledged "state of bad defaults"

Nope my perfectly confident assertions were perfectly correct and shared by every framework under the sun. Because they are right. You coming up with nonsense use cases from under your overly small sized hat doesn't change that.

> And if you turn your mental barrier off, it's pretty obvious how to make it work everywhere - you simply flag both left+right on getting the no-side flag info on a backward platform that doesnt differentiate. And only flag either left or right on a platform that does differentiate. Or differentiate it yourself by reading raw codes. So there are no good reasons to create yet another bad keyboard protocol when it works fine without blinders off

The good reason is that modifiers are state. Left and right modifier keys modify that state in exactly the same way. You WANTING them to work differently doesn't make it so. And you bloviating about how it's a bad protocol just makes you look like the moron you are, No terminal emulator developer is going to agree to implement a keyboard protocol that requires bypassing how the platform the terminal emulator runs on handles modifier keys. Because you want it to be so. What a joke. Grow up. Or actually dont, keep on ranting on internet forums about your pet demand, all the grown ups are just going to ignore you and/or laugh at you. Good bye and good luck.

ROFL you are saying that kitty the program that finally broke the keyboard logjam with terminals of preventing you from having nice things!! Good luck to you.

And lets apply some common sense to your common sense, follow up on it a little. If a modifier is defined by the fact that it modifies the actions of other keys, then left and right modifer keys modify the action in exactly the same way and thus are the same modifier. Common sense indeed.

And if you want to reference windows, a platform kitty does not support, here you go: https://developer.apple.com/documentation/appkit/nseventmodi...

no left and right modifier state on macOS. And neither does X11/Wayland have them, though I dont have a link handy, so I will just leave you with a couple of links to the documentation for cross platform toolkits instead:

https://doc.qt.io/qt-6/qt.html#KeyboardModifier-enum https://www.glfw.org/docs/latest/group__mods.html

And in case the common sense didnt make it past your mental barriers, a terminal keyboard protocol has to work on all platforms not just windows. The good lord alone knows what windows does, probably synthesizes that state based on press and release events.

There is no such thing as a left or right modifier STATE in ANY application. All applications, including kitty track only CTRL, SHIFT, ALT, ETC modifier states. left and right alt and control are key events and can be bound in any application supporting the kitty keyboard protocol as key events. If some application tracks a left and right modifier state it has to do so manually using key press and release events, the OS does not supply it any such state.

You seem to be thoroughly confused about what is a modifier and what is a key. Left and right ctrl/alt/shift are KEYS not MODIFIERS. You can track whether they are held down or up by tracking their press and release events just like for any other key.

Yes modifiers are a state, not a key. The kitty keyboard protocol does indeed send events for left and right modifier key press/releas as you can easily see for yourself by running

kitten show-key -m kitty

in a kitty terminal and pressing the left and right modifier keys.

Or just show your matplotlib plots directly in the terminal: https://github.com/jktr/matplotlib-backend-kitty

Yes hence our butts are so much more hygenic than yours.

You must be really hurting. Have a cookie.

At this point, you are the one being the cunt.

Maybe, on the other hand: the link you posted was to a benchmark using kitty 0.31, since then it had an all new escape code parser using SIMD vector CPU instructions that sped it up by 2x. https://sw.kovidgoyal.net/kitty/changelog/#cheetah-speed

They are better in every regard compared to catting a large file, which is what the OP was complaining about.

Certainly if you want to comprehensively understand terminal emulator performance there are multiple axes along which to measur eit and various tradeoffs involved. But I think nowadays we have much better alternatives to catting large files or running find / both of which have been the go to for measuring terminal performance for most people.

And kitty is much faster according to this: https://github.com/kovidgoyal/kitty/issues/2701#issuecomment...

Also typometer based measurements also on Linux. Shrug.

That's because kitty's default settings introduce a few ms of latency deliberately to save energy, see details at: https://sw.kovidgoyal.net/kitty/performance/#keyboard-to-scr...

If you want to do a fair comparison to alacritty you need to set those to the recommended values for best latency.

There is no performance cost, there is a performance gain: https://sw.kovidgoyal.net/kitty/performance/#throughput

You want better benchmarks look at the ones delivered bya ctual terminal developers, for example: https://sw.kovidgoyal.net/kitty/performance/#throughput

or https://github.com/alacritty/vtebench/tree/master

Says you. Hiding behind an alias at that. If you want to attack a real person in public, at least have the courage to use your real name to do it. And add a link to where he "brushed you off" without reasons so the rest of us can see for ourselves. Failing that, I am going with you wanted the project to do something, the maintainer didn't agree. That's his perogative doesn't make him hostile. He is not obligated to entertain your use cases. When you contribute to someone else's project you do so in the understanding that they get to decide whether to accept your contributions or not.

Yup I have been using it for over a decade, and had nothing but pleasant interactions with the maintainer. I am heartily sick of this culture of entitled people that think it is OK to free load on someone else's hard work and then take a public dump on them, that too while hiding behind an alias! And then there are people like you that enable such behavior instead of calling it out.

Mensching, the maintainer here, has been maintaining this free and open source software for twenty years!! A gift to the world. The least he is owed is a little goddamn respect.

Say no, politely, with your reasons. If they continue to argue: 1) Unwatch the issue/block emails realted to the issue (setup tooling for this) 2) If they continue to harass just block them, they are a waste of your precious time and energy

And yes they will go cry on reddit or HN or their own blogs and call you names. Ignore it. Be happy in the knowledge of the thousands or millions of people whose lives you have improved by your labor. Most of them wont bother to say thank you, but a few will, rememebr those. And be happy in the knowledge that the worlds is a better place because you exist in it, in however small a way.

The key is to realize that human psychology is by default not well equipped to deal with the internet. We tend to react much more strongly to criticism than praise. Recognize that in yourself, and gradually change it.

You dont need to wonder. Any long term maintainer of even semi popular open source projects will tell you that engaging with the peanut gallery is completely counter productive.

Engage with people that have earned it in your eyes, whether by contributing to your project via code, assets, bug triage, writing a good and effortful bug report, whatever. Just ignore what the larger internet has to say about you and your creations.

You are of course welcome to use whatever terminal you like, just be aware that speed is not a reason to prefer xterm.

xterm has extremely poor throughput performance. kitty and most other well designed terminals are atleast 2x as fast as xterm. For example: https://sw.kovidgoyal.net/kitty/performance/#throughput

Of all tested terminals xterm is faster only than konsole.

Sigh. So yet another rewrite, which will result in yet another round of regressions. Hopefully, at the end of it we will have something better than yet another unofficial driver with partial functionality that lags behind in support for newer hardware.

It's a real shame that many things in Linux land are so badly designed/maintained that they have to be re-written from scratch every few years. The major exception being the base kernel itself I suppose.