> Is XKB universally available? AFAICT, we don't require it, but use it > if available (not for XkbTranslateKeyCode, though). No. E.g. Java has functions to process keystrokes with and without XKB. I have no idea how it works without: I use KDE that internally uses XKB. But AFAIK GNOME (optionally) replaces XKB with something else. > > However, in Elisp this is further complicated by there being no > > real KeyEvent structure, instead it's a single integer as far as I > > can see. > > Why would you need that? If we decide to use XkbTranslateKeyCode, we > could translate the keycode in C, according to some logic that took > into account the modifiers and perhaps also some user options, and > returned the resulting translated character. The point is that the character is not enough, you need to know both the character and the physical key (you cannot reconstruct the key from the character alone). E.g. suppose I type 'й' in Russian layout. If it is a self-inserting command, character 'й' should be added to the active buffer. But if I'm typing a multikey binding, it should be interpreted as 'q' (it's the same physical key), so that e.g. 'C-ч й' is translated to 'C-x q'. Without looking, I'm pretty sure this goes well into Elisp part of Emacs, and changing key events from integers to something else would be a compatibility nightmare. Paul On Wed, 28 Oct 2020 at 16:06, Eli Zaretskii wrote: > > From: Paul Pogonyshev > > Date: Wed, 28 Oct 2020 01:43:04 +0100 > > Cc: Juri Linkov , 43830@debbugs.gnu.org > > > > Apparently what Java does internally is calling function > > XkbTranslateKeyCode() to translate 'keycode' that corresponds > > to a physical key into a character using the current XKB layout. > > Is XKB universally available? AFAICT, we don't require it, but use it > if available (not for XkbTranslateKeyCode, though). > > > However, in Elisp this is further complicated by there being no > > real KeyEvent structure, instead it's a single integer as far as I > > can see. > > Why would you need that? If we decide to use XkbTranslateKeyCode, we > could translate the keycode in C, according to some logic that took > into account the modifiers and perhaps also some user options, and > returned the resulting translated character. >