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

Previous Next

Full log

View this message in rfc822 format

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

[Message part 1 (text/plain, inline)]

> No, AFAIR this is all done in C.

What about functions like `read-event'? It returns integers if I press
M-[letter] or C-[letter].

Paul

On Wed, 28 Oct 2020 at 17:31, Eli Zaretskii <eliz <at> gnu.org> wrote:

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

[Message part 2 (text/html, inline)]

Previous Next

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