You seem to be overlooking the fact the modifyOtherKeys is 1) not well designed. 2) And does not solve the problem comprehensively.
1a) try to figure out what the escape code for the play/pause key is
1b) it still suffers from the issue that esc keypresses cannot be distinguished from other escape codes
1c) The keyboard protocol can be turned on/off by user config, so there is no robust way for software running in the terminal to know if it is available or not.
1d) it does not support any modifiers beyond the basic 4
1e) It has no support for lock keys num lock/caps lock
1f) It has no support for alternate keyboard layouts
1g) it has no support for shifted keys
2) How does one represent release events in modifyOtherKeys?
xterm has a long and convoluted history of coming up with poorly designed hacks that the entire ecosystem has to carry around forever afterwards. Not wanting to support these mis-faetures is an entirely reasonable position.
Escape is traditionally distinguished from an escape code by a timeout: if no more characters arrive within some small number of milliseconds, then it was the user pressing escape and not the start of an escape sequence. No new solution to that “problem” is really necessary.
Likewise, programs don’t really need to know if the terminal supports an extended set of key combinations, because they can just react to them if they arrive. If they don’t arrive, then either the terminal doesn’t support that feature or the user didn’t type that key combination; either way the program needs to do nothing.
As for modifiers, good look finding a keyboard that supports more than the basic four. No need for xterm to go out on a limb and support something you can’t use anyway.
And who cares about num lock and caps lock? I’ve never seen any program care what state they were in. Well, GDM does warn you if capslock is on during a password prompt, but that is very niche.
Terminals have never operated on scan codes, so keyboard layouts are irrelevant. The application doesn’t really care what button you pressed to get a Q, just that you typed a Q.
Likewise there has never been support for key release events on terminals. I suppose it’s useful for games, but in most other situations the user will have autorepeat configured and that will handle it.
Why should xterm go out on a limb and invent a scheme that tries to cover every possible future need, even needs that are not in evidence? Better to implement something simpler that just covers what is actually needed. It can always be extended later.
So now everyone on the planet has to suffer from slow response to esc keys because xterm is too lazy to fix it properly. And its not a "few milliseconds". Terminal bytes can come over networks with arbitrary delays, so you either get inaccurate key presses causing potential data corruption/loss or insufferably long delays. It is this kind of lazy thinking that has bedeviled this poor ecosystem.
Yes programs need to know about an extended set of key combinations, because lots of programs just spill escape codes they dont understand to the screen. So you cannot produce such codes arbitrarily, only when a program indicates it wants them. And as is usual with xterm, it didnt bother to think this through. It has a facility for requesting these extended keys, but that facility may or may not work. And there is no way to detect if it has short of waiting for those keys. So if a program wants to say, present a different interface in terminals that support extended keys, it cant do so, because it has no way to know if the terminal does support it.
I dont need a keyboard that supports physical keys. I can repurpose unused physical keys as modifiers.
Its nice you dont care about num lock and caps lock. Its not so nice that you are foisting your lack of care on the rest of us.
Let me paraphrase what you said about keyboard layouts. "Something was not done previously and therefore it should never be done". Support for layouts means pressing ctrl+letter can work even on a cyrillic keyboard, but of course, terminals have never done that, and everyone speaks english anyway. So no one cares.
You suppose its useful for games? Try making a game that uses keys for real time control without release events. Autorepeat my ass. But ofcourse, no one cares. Are you in the habit of assuming that because you dont care about something, everyone else also must not care about it.
xterm absolutely shouldn't. it would make a pigs breakfast of it. I am very happy it didn't. What you should do is stop advocating for a broken, half assed hack.
1a) try to figure out what the escape code for the play/pause key is 1b) it still suffers from the issue that esc keypresses cannot be distinguished from other escape codes 1c) The keyboard protocol can be turned on/off by user config, so there is no robust way for software running in the terminal to know if it is available or not. 1d) it does not support any modifiers beyond the basic 4 1e) It has no support for lock keys num lock/caps lock 1f) It has no support for alternate keyboard layouts 1g) it has no support for shifted keys 2) How does one represent release events in modifyOtherKeys?
xterm has a long and convoluted history of coming up with poorly designed hacks that the entire ecosystem has to carry around forever afterwards. Not wanting to support these mis-faetures is an entirely reasonable position.