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

[Paul Pogonyshev]

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.

And then passes on its own KeyEvent object that contains both

the character and the physical typed key, with downstream

code using either of the two, depending on situation (i.e. when

text is being typed, character is used, when bindings like Alt+X

are activated X states for the physical key, which can also e.g.

type Ч in Russian layout).

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. Since this is not OOP, changing anything here would

mean a thousand incompatibilities all over the place, so it's

easier to just give up and live with the non-perfect workaround

of reverse-im as suggested.

Paul

On Thu, 8 Oct 2020 at 15:58, Paul Pogonyshev <pogonyshev@gmail.com> wrote:

> The issue is more general than just a single character with a
> modifier, because key sequences such as "C-x z" will still not
> work: the 'z' will become the corresponding non-ASCII character
> when a non-US keyboard layout is used.  Therefore, the only general
> solution is for Emacs to be aware of the keyboard layout in use,
> and map the characters internally to their ASCII equivalents using
> that layout.

Probably yes, I don't know how other applications do it internally.

As I mentioned, LibreOffice and IDEA (both are probably Java) do

it somehow, so there is a way. Maybe I'll try to dig through it later,

since I'm very familiar with Java.

By the way, what I forgot to mention, is that Emacs input modes

perform exactly like I want (i.e. bind to physical keys, so that C-.

in Russian works as C-/ in English; also e.g. C-ч й is translated to

C-x q, so even non-modified characters inside bindings work), but

they have the advantage of knowing the layout, of course. And,

as I mentioned, there are two problems with them: 1) I have to

use C-\ to switch and 2) configuration of `xkb' is bypassed.

Paul

On Thu, 8 Oct 2020 at 10:49, Eli Zaretskii <eliz@gnu.org> wrote:

> From: Juri Linkov <juri@linkov.net>
> Cc: pogonyshev@gmail.com,  43830@debbugs.gnu.org
> Date: Wed, 07 Oct 2020 22:01:47 +0300
>
> >> We already discussed this 10 years ago, and the conclusion was that
> >> it would require too fundamental changes in how Emacs processes keystrokes.
> >
> > Can you point me to that discussion?
>
> https://lists.gnu.org/archive/html/emacs-devel/2005-11/msg01237.html

Thanks.

My take out of that discussion:

 . There's a patch in
   https://lists.gnu.org/archive/html/emacs-devel/2005-11/msg01384.html
   which seems to allow what Paul wanted with single characters with
   modifiers, such as C-z or M-s.  That patch has a disadvantage that
   it disables AltGr, but if we install that patch as an optional
   feature, perhaps the disadvantage is not so bad?

 . The issue is more general than just a single character with a
   modifier, because key sequences such as "C-x z" will still not
   work: the 'z' will become the corresponding non-ASCII character
   when a non-US keyboard layout is used.  Therefore, the only general
   solution is for Emacs to be aware of the keyboard layout in use,
   and map the characters internally to their ASCII equivalents using
   that layout.

(The discussions also included LEIM features, but I think that is a
separate issue.)