GNU bug report logs -
#43830
keyboard layout handling incompatible with rest of the OS
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
> 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 <eliz <at> gnu.org> wrote:
> > From: Paul Pogonyshev <pogonyshev <at> gmail.com>
> > Date: Wed, 28 Oct 2020 01:43:04 +0100
> > Cc: Juri Linkov <juri <at> linkov.net>, 43830 <at> 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.
>
[Message part 2 (text/html, inline)]
This bug report was last modified 3 years and 346 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.