I did and I comprehended that you want left and right modifiers to be different. The rest of the world disagrees with you. That does not give you the license to go around maligning other people's work.
You're too limited in your perspective to speak for the rest of the world, for example, you had no clue that the bigger part of the OS world - Windows - doesn't disagree (though that failed to become a learning opportunity).
So there is enough better design in the world to call out lack of comprehension in both other people's work and other people
Name one windows application used by more than 10 people that supports independent left and right modifier keys used as modifiers. One application. Just because the windows API for some inexplicable reason exposes those states. Meanwhile let me name some of the most popular applications in the world on Windows that explicitly dont support this.
1) Chrome
2) Edge
3) Microsoft Word
4) Windows Explorer
5) Windows command prompt and windows terminal
6) VLC
7) LibreOffice
8) Every terminal emulator under the sun
9) Firefox
10) Pick any windows application at random
Just because you WANT left and right modifiers to be different doesnt make it a good idea. Learn that.
> Name one windows application used by more than 10 people
Even though you've tried to limit yourself to basically 3 apps by different vendors (what a shallow view of the app world), and even though you've included some awful browsers that don't even allow users to rebind default(!) keybinds (are you going to argue now that this is also good and just because I WANT to change keybindings, it's not a good idea and your imaginary world disagrees?), and the platform so bad at keybinding support that it requires a whole new pseudo-comprehensive keyboard handling protocol, you've still managed to step on a huge ignorance landmine - Chrome, on Windows, supports differentiating left vs right modifiers via a browser extension!!!
There are others, but let that sink in - your #1 example fails you...
> Just because you WANT left and right modifiers to be different doesnt make it a good idea. Learn that.
It's an excellent idea for other reasons, but you're not capable of engaging in a substantive discussion, so you instead make up arguments and insults
Sure I can patch any software to do anything I want. Which is what an extension is doing. I can patch any software I want to treat the A key as a modifier too. Still doesnt make it a good idea. And my point remains, Chrome, unpatched, does not support left and right modifier keys as modifiers. Not to mention I dont actually believe you. Post a link to this supposed extension of yours. I am guessing you wrote it and only you use it. And if you want to call the browsers used by 99.9999% of the population terrible in favor of some shit you cooked up yourself just to try to rescue your ridiculous point, good luck to you.
I'll just leave you with this promise, anytime you try to denigrate the kitty keyboard protocol I will be right there calling you out.
Extension isn't a patch, and it wasn't your point, you're just making you new conditions up because your previous attempts to build a safe condition box failed to save you
But if you want to find out the extension you'd have to search in that other thing available in a browser 99.9999% are using, it sometimes helps even the most ignorant of those!
So I'll leave you with that and ignore your future trollish defenses of a "cross-platform" terminal not working on the biggest platform and "comprehensive" protocols excluding Japanese modifiers and sides
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.
Oh man, you are back repeating these lies after I corrected you the last time. Let me repeat it for any poor victims of your propaganda. You don't need to update calibre for news recipe updates. You never have needed it, and the developer of calibre goes to great lengths to make sure that is the case. calibre loads the updated version of a recipe automatically on every use. Indeed it does so for all code that faces the web including metadata scrapers, get books stores, news recipes and so on.
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.
Just off the wall crazy shit dealing with absolutists like this.
Yes efficiency is good. But... Damnit man! The performance numbers shown for this low power processor are 43MB/s without tmux vs 30MB/s with tmux. It's likely going to take a lot of activity for that to aggregate into even a decent fraction of a ms of latency.
Beware extremists. Some people will never be pleased, will accept nothing. The only answer is to cut cut cut forever. There's a cult of people out there that idolize performance above any practical use like a god & will destroy & savage anything else. Deny this falsity. Respect performance, but also allow other factors to balance in.
(Side note: I'd love to know how dtach performs. It has the key advantage to me of tmux, which is detachability, but no virtualization. Great for running a vim session! And by design is a very pure simple pass through.)
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.
The table you linked is chopped off on mobile. So you are looking at the last column and the person above is looking at the first column.
Also, why have you done an “alacritty” vs “alacritty+tmux” benchmark yet have not done a “kitty+tmux” benchmark on this same table? That’s a big omission. The entire conversation is about the effects of adding a multiplexer on top of a terminal.
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.
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...
Funny, I always use the binaries distributed by the developers whenever I can thinking that the less intermediaries the better. Maybe I need to revise that position.
Malicious distro packagers are virtually unheard of, and another set of eyes on the software is generally better. For instance, if the developer sells out the packager can save your bacon. This is especially true on Android where selling out is more common (see: the Simple Apps situation and F-Droid) but also a valid consideration on desktop Linux.
I wouldn't assume anything about distro packages really. It's a higher bar in some systems (like Debian), lower in some (like nixpkgs), but the time investment to be in a position to sabotage something is quite low overall and requires little skill. Then there are not-distro packages that they easily abused over time. For example sourceforge was a respected distributor of software for a long time and they moved to adware installers.
I stick to official distro packages from distros I like, mainly Debian and OpenSUSE. Community packages are too sketchy for me, and I consider downloading packages from sourceforge/etc to be a Windowism. And while it's possible for a malicious entity to infiltrate the ranks of distro packagers, I think the threat of the developer selling out has proven to be more likely.
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.
So why are you talking about a key then??? Kitty doesn't support left/right modifiers unlike proper keybinding handling apps, the left/right presses for non-modifier keys aren't relevant
How would you bind LeftAlt-A to something different from RightAlt-A in Kitty?
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.
This rigid simplistic attitude is precisely why we can't have nice keyboard things and have been stuck in the same state of bad defaults for decades
The only differentiator for a modifier state is that it... modifies! Here is a wiki common sense definition
> In computing, a modifier key is a special key (or combination) on a computer keyboard that temporarily modifies the normal action of another key when pressed together
So your limitations don't make conceptual sense, not only can you have LShift vs RShift modifier state, but also you can have an F modifier state when you hold down the F key to modify the behavior of other keys
> OS does not supply it
Unless it does?
> VK_LSHIFT VK_RSHIFT VK_LCONTROL VK_RCONTROL VK_LMENU VK_RMENU These left- and right-distinguishing constants are available to an application only through the GetKeyboardState, SetKeyboardState, GetAsyncKeyState, GetKeyState, and MapVirtualKey functions.
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.
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:
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.
I'm not saying that, it's something you've made up for your inner rofls.
> 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.
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
> And if you want to reference windows, a platform kitty does not support, here you go:
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"
> a terminal keyboard protocol has to work on all platforms not just windows.
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 lord alone knows what windows does, probably synthesizes that state based on press and release events.
Do tell me, what is the alternative magic of how Mac/Linux synthesize Shift state without press/release events?
> 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.
> Nope my perfectly confident assertions were perfectly correct and shared by every framework under the sun.
Except for the most popular OS in the world and the frameworks that support it (including those you linked, QT has a way to query Windows and get Right Shift key state)
> You WANTING them to work differently doesn't make it so.
Except it does, and your childish trolling and insults can't change this simple FACT that they DO work differntly precisely because I WANT that and I've set it up to work like that, not all software is as narrow-minded as you are. Live with it.
Also not really cross-platform, contrary to what's indicated in the first word of its github description, and the owner is kind of an ass about it https://github.com/kovidgoyal/kitty/issues/6481.
But it should support at least more than one platform. And it's disputable what exactly one considers as a platform, or just a flavor of some platform.
As said, it depends on the definition of platform for this case. All I see is support of a bunch of flavors of one platform, namely POSIX, unixoids, or how you want to call it. Yes, they are different desktop-platforms, but the purpose of this software is still limited to one specific environment. Or to give a different perspective, nobody would call it cross-platform, just because it can run with Gnome and KDE, under X11 and Wayland.
And I'm curious how much adaption happens for each OS really. Are there specific changes for MacOS and BSD, outside of some paths for configurations?
The entire point of POSIX is that, if you only use what it defines, your program automatically becomes cross-platform, because it will run on several Unices, as well as other systems (like Haiku).
It's probably fair to say that an application with native Wayland and X11 support is multiplatform. I can understand somebody disputing that, but certainly Linux and MacOS are different platforms. They don't even share executable formats.
The author replied with the same effort as the person who reported the issue. You kinda need to do this as a maintainer if you don't want to drawn under low quality reports and burn all your energy. I'm sure lucasjinreal would have gotten a kinder answer if they took time to phrase their issue ("demand", at this point, also misguided) nicely.
It's not really, I just remembered wanting to try out this terminal emulator and being quite surprised that something actively advertised as cross-platform didn't support Windows.
I agree that the person posting the issue wasn't really doing it in a diplomatic way, but in the end, the result is the same. I think it's disingenuous to actively advertise something as cross-platform, without even specifying which platforms are actually supported (even if yes, technically it's cross-platform)
> without even specifying which platforms are actually supported
The first line of the README (ok, second line if you include the title) is "See the kitty website" with a link, and on the site the top menu has a "cross platform" entry which then lists "Linux, MacOS, Various BSDs".
It seems like a stretch to classify that as disingenuous.
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
Those tend to say things like "This benchmark is not sufficient to get a general understanding of the performance of a terminal emulator. It lacks support for critical factors like frame rate or latency. The only factor this benchmark stresses is the speed at which a terminal reads from the PTY."
So although those tests may be more extensive, they're not "better" in every regard.
Of course it's perfectly reasonable to want a benchmark that people can run without needing to build any custom hardware.
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.
