From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.bugs Subject: bug#43830: keyboard layout handling incompatible with rest of the OS Date: Wed, 28 Oct 2020 17:16:59 +0100 Message-ID: References: <87h7r78a5y.fsf@mail.linkov.net> <87imbn2iwm.fsf@mail.linkov.net> <87y2kisawy.fsf@mail.linkov.net> <83362qa073.fsf@gnu.org> <87blhdrhww.fsf@mail.linkov.net> <83362p85l3.fsf@gnu.org> <83y2jqcrvn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000ea4bd705b2bd7eac" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23818"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43830@debbugs.gnu.org, Juri Linkov To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 28 17:18:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kXo9L-00064u-A2 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Oct 2020 17:18:11 +0100 Original-Received: from localhost ([::1]:45704 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kXo9K-0004NL-04 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Oct 2020 12:18:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59714) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kXo9C-0004Mw-Rf for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2020 12:18:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38699) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kXo9C-00062d-Hd for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2020 12:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kXo9C-00042j-9P for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2020 12:18:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Pogonyshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 28 Oct 2020 16:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43830 X-GNU-PR-Package: emacs Original-Received: via spool by 43830-submit@debbugs.gnu.org id=B43830.160390184015488 (code B ref 43830); Wed, 28 Oct 2020 16:18:02 +0000 Original-Received: (at 43830) by debbugs.gnu.org; 28 Oct 2020 16:17:20 +0000 Original-Received: from localhost ([127.0.0.1]:50245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXo8V-00041k-LJ for submit@debbugs.gnu.org; Wed, 28 Oct 2020 12:17:20 -0400 Original-Received: from mail-wr1-f50.google.com ([209.85.221.50]:34428) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXo8T-00041W-6p for 43830@debbugs.gnu.org; Wed, 28 Oct 2020 12:17:17 -0400 Original-Received: by mail-wr1-f50.google.com with SMTP id i1so6372536wro.1 for <43830@debbugs.gnu.org>; Wed, 28 Oct 2020 09:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FjW88cAvov8c+FplXx7QZsBcfT1QDCWuk6Q68HvSFEs=; b=gK4J47PeRG664dlXk9lRrrhXO/U/FDNLC2q5oviYTSJUX4uPt6eTnkVwBoRa6+NmMy iF2mRr4ci67hUNeoHJQyIrxTiY/iwLNB4bG7uDMbkBc5kncMK6XNCvXaHLZh0tqET2AO 9ZDRii6bBTCJtdhVY47ld4+WaICMYmtSLFhA5XZ0/OA/XzFh/SvPeakPWBa8FIrXbiqc pXosC4vggGYm7LYvIHNJd9lBdcJjLQsYrgHWiUAd8k0M6yJGR6CGlt5cGPe7z6wSMrc3 DcneBqq9XVMCEfDe7t/opxse3xCCtHD1fy9rww3iivQTBo3frsX6z/Y6ZaJr9zV6jbRl mBEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FjW88cAvov8c+FplXx7QZsBcfT1QDCWuk6Q68HvSFEs=; b=YLoXroHCRBQMcBLEKVQySOWSE+fQL6umRpJFCzXjf8PUdDBK8HoUX73EoPCWz18k59 gIORwrNKKeFdJn3qE5p9nYhCMfQ79hOx6Tp9xpqAEGq4+XII5F3PscY9AS9aShkKiegz whkrDLD5PSOCclguwuu/gvxV9F5p+Dbbm8WVIENG8jZnjdxz3+6MjZBTzIAFxBbuf62m RSW5jvLRqAks4W2tZXUIFMESQfPkpeqiSjOn+XSJDvOD1kSXFvsG8h1jmXH/dOynFYD2 B4JrrKUKAhxIGgyqOOQ/b5FCyJiaPFhFYW0cflaiz1Ff4XenwUtV/BHfN7k4JpE2cP1X M6Pw== X-Gm-Message-State: AOAM533tea+HiL7cq6xRpKqUDbXxOFTJPOt/EbFoWV++nvNnLxB3/F7Q WyYLzrkjUB2nu5GsFLypfDlF7Q8n3N1R43z/vA== X-Google-Smtp-Source: ABdhPJwx8GsfNgkAgbGykxOgd5wIrBnaxsdPZ1wdic8G6u6eSMU4I88L/SotUYHTPIaSrPtK3Hirv9VPvxQFV+yC0gA= X-Received: by 2002:adf:80cb:: with SMTP id 69mr9802177wrl.325.1603901831397; Wed, 28 Oct 2020 09:17:11 -0700 (PDT) In-Reply-To: <83y2jqcrvn.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:191896 Archived-At: --000000000000ea4bd705b2bd7eac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Is XKB universally available? AFAICT, we don't require it, but use it > if available (not for XkbTranslateKeyCode, though). No. E.g. Java has functions to process keystrokes with and without XKB. I have no idea how it works without: I use KDE that internally uses XKB. But AFAIK GNOME (optionally) replaces XKB with something else. > > 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 '=D0=B9' in Russian layout. If it is a self-inserting command, character '=D0=B9' should be added to th= e 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-=D1=87 =D0= =B9' is translated to 'C-x q'. Without looking, I'm pretty sure this goes well into Elisp part of Emacs, and changing key events from integers to something else would be a compatibility nightmare. Paul On Wed, 28 Oct 2020 at 16:06, Eli Zaretskii wrote: > > From: Paul Pogonyshev > > Date: Wed, 28 Oct 2020 01:43:04 +0100 > > Cc: Juri Linkov , 43830@debbugs.gnu.org > > > > Apparently what Java does internally is calling function > > XkbTranslateKeyCode() to translate 'keycode' that corresponds > > to a physical key into a character using the current XKB layout. > > Is XKB universally available? AFAICT, we don't require it, but use it > if available (not for XkbTranslateKeyCode, though). > > > 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. > --000000000000ea4bd705b2bd7eac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Is XKB universally available?=C2=A0 AFAICT, we don= 9;t require it, but use it
> if available (not for XkbTranslateKeyCod= e, though).

No. E.g. Java has functions to process k= eystrokes with and without XKB.
I have no idea how it works witho= ut: I use KDE that internally uses XKB.
But AFAIK GNOME (optional= ly) replaces XKB with something else.

> > However, in Elisp this= is further complicated by there being no
> > real KeyEvent struct= ure, instead it's a single integer as far as I
> > can see.>=C2=A0
> Why would you need that?=C2=A0 If we decide to u= se XkbTranslateKeyCode, we
> could translate the keycode in C, accord= ing to some logic that took
> into account the modifiers and perhaps = also some user options, and
> returned the resulting translated chara= cter.

The point is that the character is not e= nough, you need to know both
the character and the physical key (= you cannot reconstruct the key
from the character alone). E.g. su= ppose I type '=D0=B9' in Russian layout.
If it is a self-= inserting command, character '=D0=B9' should be added to the
<= div>active buffer. But if I'm typing a multikey binding, it should be
interpreted as 'q' (it's the same physical key), so th= at e.g. 'C-=D1=87 =D0=B9' is
translated to 'C-x q'= ;. Without looking, I'm pretty sure this goes well
into Elisp= part of Emacs, and changing key events from integers to
somethin= g else would be a compatibility nightmare.

Paul


On Wed, 28 Oct 2020 at 16:06, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Paul Pogonyshev <pogonyshev@gmail.com= >
> Date: Wed, 28 Oct 2020 01:43:04 +0100
> Cc: Juri Linkov <juri@linkov.net>, 43830@debbugs.gnu.org
>
> Apparently what Java does internally is calling function
> XkbTranslateKeyCode() to translate 'keycode' that corresponds<= br> > to a physical key into a character using the current XKB layout.

Is XKB universally available?=C2=A0 AFAICT, we don't require it, but us= e it
if available (not for XkbTranslateKeyCode, though).

> 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?=C2=A0 If we decide to use XkbTranslateKeyCode, we<= br> 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.
--000000000000ea4bd705b2bd7eac--