Shortcuts doesn't work for non-Latin input source

[vstukanov]

Motivation:
As Emacs keymap user I want to be able to use shortcuts even if non-Latin input selected. Examples of use-cases might be writing translations files or personal todo list items.

The issue:
Currently, howl grab keyboard events by itself and translate it to named shortcut regarding keyval property. This field input-source dependent so the same keyboard shortcut produces different shortcut "events" internally. (example: ctlr-a and ctlr-ф for en and ru)

Possible solutions:

• Suggest a user create additional keymaps for each non-Latin input source. (something completely not user-friendly, especially if it's more then one input source)
• Use GTK Accelerator API for handling shortcuts. It's an official way but it might require a significant amount of work. (Is it so?)
• Use the keycode event field which is input-source independent and represents a keyboard button instead. That looks promising but the implementation might look like a dirty hack. GTK doesn't provide any documented way to map keycode to keyval for the Latin keymap, so we would be required to build such hashmap at run-time (or use undocumented GTK API).

As a bonus, this will also solve an option related shortcuts on mac OS for a standard Latin input-source, which is also a big issue for emacs keymaps users.

Addition reading:

• Similar thread in the Eclipse project. (btw 13-years story).
• GTK undocumented fix used in Accelerator API.
• Similar Geany issue

Before I actually start with the fix implementation I would like to hear your opinion about this topic and suggested solutions.

[shalabhc]

Is the keycode based translation stable? E.g. if you press ctrl-a does it always show up as ctrl_97 in 'describe-key'?

[vstukanov]

Sorry, I wasn't precision with naming in a description. In terms of howl codebase key_code is a GtkEventKey.keyval, so my suggestion probably was not clear enough.
The idea is to use GtkEventKey.hardware_keycode and translate it to GtkEventKey.keyval on a US-standard keyboard (QWERTY) regardless of users input source.
One of the possible solution would be to have such mapping directly in lua codebase.

Something like this:

linuxkeymap = {
  10 = {"1", "exclam"}
  ...
  38 = {"a", "A"}
}
-- different for each platform
osxkeymap = {...}

winkeymap = {...}

which is pretty easy to generate from xmodmap -pke

Screenshots to illustrate hardware_keycode: