GNU bug report logs - #43830
keyboard layout handling incompatible with rest of the OS

Previous Next

Full log

Message #74 received at 43830 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 43830 <at> debbugs.gnu.org
Subject: Re: bug#43830: keyboard layout handling incompatible with rest of
 the OS
Date: Sun, 01 Nov 2020 09:53:08 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.