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

[Juri Linkov]

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