Not really, just the way that keyboard input is mapped to a charset (like ANSI or Unicode). A keyboard is not a device that is 100% compatible with any character set (mainly because it is an array of keys that have an arbitrary meaning in a charset).
The current terminal architecture enforces any application to adopt its mapping of key combination to code points, which doesn't really make sense, at least from an input perspective (think of binding C-Tab in Vim to something: You can't, because the terminal knows no representation for it).
What would make sense OTOH is for the translation to happen in the application itself -- and maybe having a common API that makes the default mapping easy to use.
If I read [1] correctly, that's basically the same idea -- introduce a new API with which an application can determine which buttons were actually pressed as opposed to just reacting to an ANSI control signal that could've been produced in multiple ways.
Peripherals have the same problem, by the way: The USB HID for example can't send code points to the computer, but can only produce key codes, which are then interpreted by the keyboard driver. Sadly, this means that I can't tell my Ergodox keyboard to send an `ä` to the computer directly, only the combination that would produce this character if the right language has been selected.
Edit: Also, to quote the Plain White T's: Hate is a
strong word... ¯\_(ツ)_/¯
What you say about keyboards is true for PC keyboards, but was not always, historically, the case. Terminals always sent the ASCII code of the pressed key(s), and especially in early terminals, all CTRL really did was to mask off the highest bits of the transmitted code leaving a value between 0-31 -- the ASCII control range. That's why ^I is TAB and ^[ is escape.
If we implemented what you proposed, terminal emulators wouldn't be terminal emulators anymore -- they'd be some sort of generic input and output framework. While we're at it, why don't we include another API to take advantage of the high-color framebuffer displays most modern computers enjoy rather than just displaying a grid of fixed-width text characters. Oh look, we've just reinvented X11. Again (see: Wayland).
Or how about no, because it's yet another library dependency in what should be a straightforward terminal program, and the whole solution breaks when the program is talking to a real live terminal (as Linux programs can still actually do) because there is no "underlying key event" from a terminal. And if you are assuming an environment like X11 or Wayland, just write an X11 or Wayland program and be done with it. (Both vim and Emacs have taken this approach, and AFAIK support keybindings of the type you describe while running in graphical mode.)
As far as I can see it, we basically agree on everything discussed so far, except for the idea that it might be worth to try and fix some historical shortcomings.
While that's a worthwhile discussion to have and I see the difficulties in maintaining compatibility (see my original post), I'd say that arguing either way goes somewhat against the premise of this thread.
The current terminal architecture enforces any application to adopt its mapping of key combination to code points, which doesn't really make sense, at least from an input perspective (think of binding C-Tab in Vim to something: You can't, because the terminal knows no representation for it).
What would make sense OTOH is for the translation to happen in the application itself -- and maybe having a common API that makes the default mapping easy to use.
If I read [1] correctly, that's basically the same idea -- introduce a new API with which an application can determine which buttons were actually pressed as opposed to just reacting to an ANSI control signal that could've been produced in multiple ways.
Peripherals have the same problem, by the way: The USB HID for example can't send code points to the computer, but can only produce key codes, which are then interpreted by the keyboard driver. Sadly, this means that I can't tell my Ergodox keyboard to send an `ä` to the computer directly, only the combination that would produce this character if the right language has been selected.
Edit: Also, to quote the Plain White T's: Hate is a strong word... ¯\_(ツ)_/¯
[1]: https://news.ycombinator.com/item?id=16015036