Keyboards don't create unicode code points.
You are right, keyval is not always a code point, although often coincidentally the value happens to be the same :smile:. But keyval does use at least 25 bits (see cyrillic or armenian in `gdkkeysyms.h`) so its worse than I thought. Also on some keyboards with "dead" keys GDK maps a multiple key sequences into one key event without IME. And IME still generates a keyevent IIUC with Unicode keyvals.
Most keyboards have fewer than 128 keys.
Not true, some non-asian keyboards have up to 4 values per keycap, see [French](https://en.wikipedia.org/wiki/File:Azerty_NFZ71-300.png) or probably @eht16's German keyboard. And also _which_ values? As you can see in `gdkkeysyms.h` keyval can cover a wide range of values. A simple table of all possible keyvalues from keyval to function address is far too big even if state is handled separately.
Thats why I suggest a hash table (or binary tree), key is combined `keyval` and `state` from the event and value is the function to call, the number of entries is related to the number of active keybindings, not the number of possible key values and the performance is constant for hash and O(ln(entries)) for tree (say 7 compares of a 64 bit value if 128 keybindings are set). Because keyvals from any one keyboard are likely to be close to sequential the combination and hash of `keyval` and `state` needs to ensure that performance does not approach linear worst case if hash is used, probably tree is safer because it doesn't have the bad worst case performance. Don't know which is easier to use/maintain.
Keyboards are a real pain, see also #1368 for another saga.