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

[Paul Pogonyshev <pogonyshev@gmail.com>]

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

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

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