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

[Paul Pogonyshev <pogonyshev@gmail.com>]

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

> Could you please give an example how you bind such key sequences as
> 'C-.' and 'C-ч й' in Emacs input modes?  How they do translation
> to physical keys without using xkb?

I don't and that's the whole point. I want that when _any_ keymap
defines `M-q', this keybinding can be activated by typing M-q or M-й,
because this is the same physical key. Automatically.

`reverse-im' achieves this but _only_ for keys that type letters in
the second layout. E.g. M-/ (which I often use) won't work in Russian
layout because that physical letter types '.' in this layout.

> > What about functions like `read-event'? It returns integers if I press
> > M-[letter] or C-[letter].
>
> read-event is also implemented in C.  But maybe I don't understand
> your question.

I mean, what about the cases where it is called from Elisp?  It is
implemented in C, but also is publicly available.

I have come up with two ideas:

1. `read-event' and its internal C implementation grow an optional
parameter that says whether to return character as if being typed (as
now) or for keybinding use (i.e. from physical keys).

2. Alternatively, if this cannot be determined in advance (i.e. before
calling `read-event' etc.), these functions could set variable named sth.
like `last-keybinding-keycode'. Then the caller would use either the
return value (as now) or, if it wants, the value of the variable instead.

Paul

On Sun, 1 Nov 2020 at 09:01, Juri Linkov <juri@linkov.net> wrote:

> >> 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'.
>
> What is worse is that in a writable buffer, typing 'й' should insert
> this character untranslated, but in the same buffer when it's in
> read-only view mode, typing the same 'й' should translate it to 'q'
> and quit the buffer with the View-quit command.  When using reverse-im
> with local-function-key-map, the Help buffer says:
>
>   q (translated from й) runs the command View-quit.
>
> So the question is whether it's possible to do the same using
> XkbTranslateKeyCode?  The local-function-key-map is smart enough
> to not translate self-inserting keys.  Can code for XkbTranslateKeyCode
> use the same condition to detect self-inserting keys?
>

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