bug#43830: keyboard layout handling incompatible with rest of the OS

[Paul Pogonyshev <pogonyshev@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2383 bytes --]

> 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@gnu.org> wrote:

> > From: Paul Pogonyshev <pogonyshev@gmail.com>
> > Date: Wed, 28 Oct 2020 01:43:04 +0100
> > Cc: Juri Linkov <juri@linkov.net>, 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.
>

[-- Attachment #2: Type: text/html, Size: 3295 bytes --]