bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Pogonyshev
Subject: bug#43830: keyboard layout handling incompatible with rest of the OS
Date: Wed, 28 Oct 2020 17:16:59 +0100

> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]