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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: 43830 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#43830: keyboard layout handling incompatible with rest of the
 OS
Date: Wed, 28 Oct 2020 18:31:37 +0200

> From: Paul Pogonyshev <pogonyshev <at> gmail.com>
> Date: Wed, 28 Oct 2020 17:16:59 +0100
> Cc: Juri Linkov <juri <at> linkov.net>, 43830 <at> debbugs.gnu.org
> 
> > > 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.
> > 
> > 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'. Without looking, I'm pretty sure this goes well
> into Elisp part of Emacs

No, AFAIR this is all done in C.

Previous Next

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