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 01:43:04 +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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f1881605b2b07262" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40528"; 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 01:44:30 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 1kXZZm-000APo-8L for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Oct 2020 01:44:30 +0100 Original-Received: from localhost ([::1]:44638 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kXZZl-0008I8-BC for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 27 Oct 2020 20:44:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58964) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kXZZK-0008Ht-80 for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2020 20:44:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34875) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kXZZJ-0005lQ-Vi for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2020 20:44:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kXZZJ-0006tJ-QW for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2020 20:44:01 -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 00:44:01 +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.160384580426438 (code B ref 43830); Wed, 28 Oct 2020 00:44:01 +0000 Original-Received: (at 43830) by debbugs.gnu.org; 28 Oct 2020 00:43:24 +0000 Original-Received: from localhost ([127.0.0.1]:46421 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXZYi-0006sM-BX for submit@debbugs.gnu.org; Tue, 27 Oct 2020 20:43:24 -0400 Original-Received: from mail-wr1-f47.google.com ([209.85.221.47]:32855) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kXZYg-0006s9-1k for 43830@debbugs.gnu.org; Tue, 27 Oct 2020 20:43:22 -0400 Original-Received: by mail-wr1-f47.google.com with SMTP id b8so3893054wrn.0 for <43830@debbugs.gnu.org>; Tue, 27 Oct 2020 17:43:21 -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=gqSWFK0urn0+pz5NWQXEzjYNj8ADFYKBLXnaXL78WtU=; b=GZKffG0d42PNhPdeYbyLtIwvmtxvDXgPCPwWaIucpx3oL68hHztcDSwiEkn8VQ6egH ZKjEVtmJ5AZlETbA+jmGpBVZog9HFynVioBPtu7noPDcBXq+QIG+d/GBopVMjs7qH/nu mExcCOQ09SX2aKNNXAxzHagNP5vfSa/gg6le3fJWAri3Ewv/nyU0Ehgw97Yk73n70FFI dnb19/YhofqasSymgJ40JvaMnXJy9SFjRHkD6UA20YopcyxzFMoXEbEYkASbLguiiGUl Q3YIVWsfNHsm+w1nIDOeHQFKlCaPjftlUaHMXIQ9EPY+IDBmPnFzLqWpYLazJa6n0Sho Mc1g== 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=gqSWFK0urn0+pz5NWQXEzjYNj8ADFYKBLXnaXL78WtU=; b=LhFwWdhM6xHpxI63X7Tqk+RUBRdYkdtpA+emljL/2icsSAtWqRxpQT6TwEvcxRSgoT 8QILIjlEBFj9Kj/ie8Y9/oFci5Sct24/nj6rM6tQoJeVcL2VK+yV5WAAZ+S22KVhP1N4 69vKfSIrBjC1406oSifbESHnOHL5DR9Z9t03HOnvtrRePNzxBe5WfZu8c9oyktrShQU/ TkoSPtFheJtmxj2TS/Ny/KIu9JOkT5hU0oqp9k8SyenlRGlP5wNZDebSkE2XoPIj8UPc +z7Q3jnGrAuuuuED5I76ha7l5MmL0RibuxmHkUJzSAMwlFRmUGBiUZGs5Ygsb3XVK0F1 tqNA== X-Gm-Message-State: AOAM532cPgcFTQrWL9ECwF/U48LXcyWJIkflzPACmhSpjUG9blf+YLix 148+YUjSoNJbPL3StHF8RO+HXuxCdLtRNdrXDQ== X-Google-Smtp-Source: ABdhPJzbwu6MCyk4XLFkTfCtEY+CgKN1M/Og+EP4gPTp45Bd/K0d3X+8KfY37XbyieHZAaUhlGIpIhlWKP4ElIHwZjU= X-Received: by 2002:adf:b19c:: with SMTP id q28mr5533885wra.119.1603845795972; Tue, 27 Oct 2020 17:43:15 -0700 (PDT) In-Reply-To: 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:191805 Archived-At: --000000000000f1881605b2b07262 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. And then passes on its own KeyEvent object that contains both the character and the physical typed key, with downstream code using either of the two, depending on situation (i.e. when text is being typed, character is used, when bindings like Alt+X are activated X states for the physical key, which can also e.g. type =D0=A7 in Russian layout). 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. Since this is not OOP, changing anything here would mean a thousand incompatibilities all over the place, so it's easier to just give up and live with the non-perfect workaround of reverse-im as suggested. Paul On Thu, 8 Oct 2020 at 15:58, Paul Pogonyshev wrote: > > The issue is more general than just a single character with a > > modifier, because key sequences such as "C-x z" will still not > > work: the 'z' will become the corresponding non-ASCII character > > when a non-US keyboard layout is used. Therefore, the only general > > solution is for Emacs to be aware of the keyboard layout in use, > > and map the characters internally to their ASCII equivalents using > > that layout. > > Probably yes, I don't know how other applications do it internally. > As I mentioned, LibreOffice and IDEA (both are probably Java) do > it somehow, so there is a way. Maybe I'll try to dig through it later, > since I'm very familiar with Java. > > By the way, what I forgot to mention, is that Emacs input modes > perform exactly like I want (i.e. bind to physical keys, so that C-. > in Russian works as C-/ in English; also e.g. C-=D1=87 =D0=B9 is translat= ed to > C-x q, so even non-modified characters inside bindings work), but > they have the advantage of knowing the layout, of course. And, > as I mentioned, there are two problems with them: 1) I have to > use C-\ to switch and 2) configuration of `xkb' is bypassed. > > Paul > > > > On Thu, 8 Oct 2020 at 10:49, Eli Zaretskii wrote: > >> > From: Juri Linkov >> > Cc: pogonyshev@gmail.com, 43830@debbugs.gnu.org >> > Date: Wed, 07 Oct 2020 22:01:47 +0300 >> > >> > >> We already discussed this 10 years ago, and the conclusion was that >> > >> it would require too fundamental changes in how Emacs processes >> keystrokes. >> > > >> > > Can you point me to that discussion? >> > >> > https://lists.gnu.org/archive/html/emacs-devel/2005-11/msg01237.html >> >> Thanks. >> >> My take out of that discussion: >> >> . There's a patch in >> https://lists.gnu.org/archive/html/emacs-devel/2005-11/msg01384.html >> which seems to allow what Paul wanted with single characters with >> modifiers, such as C-z or M-s. That patch has a disadvantage that >> it disables AltGr, but if we install that patch as an optional >> feature, perhaps the disadvantage is not so bad? >> >> . The issue is more general than just a single character with a >> modifier, because key sequences such as "C-x z" will still not >> work: the 'z' will become the corresponding non-ASCII character >> when a non-US keyboard layout is used. Therefore, the only general >> solution is for Emacs to be aware of the keyboard layout in use, >> and map the characters internally to their ASCII equivalents using >> that layout. >> >> (The discussions also included LEIM features, but I think that is a >> separate issue.) >> > --000000000000f1881605b2b07262 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apparently what Java does internally is calling functionXkbTranslateKeyCode() to translate 'keycode= 9; that corresponds
to a physical key into a character using the = current XKB layout.
And then passes on its own KeyEvent objec= t that contains both
the character and the physical typed key, wi= th downstream
code using either of the two, depending on situatio= n (i.e. when
text is being typed, character is used, when binding= s like Alt+X
are activated X states for the physical key, which c= an also e.g.
type =D0=A7 in Russian layout).

=
However, in Elisp this is further complicated by there being no
<= div>real KeyEvent structure, instead it's a single integer as far as I<= /div>
can see. Since this is not OOP, changing anything here would
mean a thousand incompatibilities all over the place, so it's
easier to just give up and live with the non-perfect workaround
of reverse-im as suggested.

Paul
<= br>

On Thu, 8 Oct 2020 at 15:58, Paul Pogonyshev <pogonyshev@gmail.com> wrote:
> The issue = is more general than just a single character with a
> modifier, becau= se key sequences such as "C-x z" will still not
> work: the= 'z' will become the corresponding non-ASCII character
> when= a non-US keyboard layout is used.=C2=A0 Therefore, the only general
>= ; solution is for Emacs to be aware of the keyboard layout in use,
> = and map the characters internally to their ASCII equivalents using
> = that layout.

Probably yes, I don't know how othe= r applications do it internally.
As I mentioned, LibreOffice and = IDEA (both are probably Java) do
it somehow, so there is a way. M= aybe I'll try to dig through it later,
since I'm very fam= iliar with Java.

By the way, what I forgot to ment= ion, is that Emacs input modes
perform exactly like I want (i.e. = bind to physical keys, so that C-.
in Russian works as C-/ in Eng= lish; also e.g. C-=D1=87 =D0=B9 is translated to
C-x q, so even n= on-modified characters inside bindings work), but
they have the a= dvantage of knowing the layout, of course. And,
as I mentioned, t= here are two problems with them: 1) I have to
use C-\ to switch a= nd 2) configuration of `xkb' is bypassed.

Paul=



On Thu, 8 Oct 2020 at 10:49, Eli Zarets= kii <eliz@gnu.org&= gt; wrote:
> = From: Juri Linkov <= juri@linkov.net>
> Cc: pogonysh= ev@gmail.com,=C2=A0 43830@debbugs.gnu.org
> Date: Wed, 07 Oct 2020 22:01:47 +0300
>
> >> We already discussed this 10 years ago, and the conclusion wa= s that
> >> it would require too fundamental changes in how Emacs process= es keystrokes.
> >
> > Can you point me to that discussion?
>
> https://lists.gnu.org/archi= ve/html/emacs-devel/2005-11/msg01237.html

Thanks.

My take out of that discussion:

=C2=A0. There's a patch in
=C2=A0 =C2=A0https://lists.gnu.o= rg/archive/html/emacs-devel/2005-11/msg01384.html
=C2=A0 =C2=A0which seems to allow what Paul wanted with single characters w= ith
=C2=A0 =C2=A0modifiers, such as C-z or M-s.=C2=A0 That patch has a disadvan= tage that
=C2=A0 =C2=A0it disables AltGr, but if we install that patch as an optional=
=C2=A0 =C2=A0feature, perhaps the disadvantage is not so bad?

=C2=A0. The issue is more general than just a single character with a
=C2=A0 =C2=A0modifier, because key sequences such as "C-x z" will= still not
=C2=A0 =C2=A0work: the 'z' will become the corresponding non-ASCII = character
=C2=A0 =C2=A0when a non-US keyboard layout is used.=C2=A0 Therefore, the on= ly general
=C2=A0 =C2=A0solution is for Emacs to be aware of the keyboard layout in us= e,
=C2=A0 =C2=A0and map the characters internally to their ASCII equivalents u= sing
=C2=A0 =C2=A0that layout.

(The discussions also included LEIM features, but I think that is a
separate issue.)
--000000000000f1881605b2b07262--