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: Tue, 6 Oct 2020 19:48:05 +0200 Message-ID: References: <83r1qb9sgl.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000025614a05b1043426" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24735"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43830@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 06 19:49:19 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 1kPr5S-0006KL-AL for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 06 Oct 2020 19:49:18 +0200 Original-Received: from localhost ([::1]:36780 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kPr5Q-0005Up-Tk for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 06 Oct 2020 13:49:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48058) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kPr5C-0005Uc-Hq for bug-gnu-emacs@gnu.org; Tue, 06 Oct 2020 13:49:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42537) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kPr5B-0000nM-Lv for bug-gnu-emacs@gnu.org; Tue, 06 Oct 2020 13:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kPr5B-0003Ke-Kk for bug-gnu-emacs@gnu.org; Tue, 06 Oct 2020 13:49: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: Tue, 06 Oct 2020 17:49: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.160200650412766 (code B ref 43830); Tue, 06 Oct 2020 17:49:01 +0000 Original-Received: (at 43830) by debbugs.gnu.org; 6 Oct 2020 17:48:24 +0000 Original-Received: from localhost ([127.0.0.1]:54083 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kPr4a-0003Jp-Ed for submit@debbugs.gnu.org; Tue, 06 Oct 2020 13:48:24 -0400 Original-Received: from mail-wm1-f53.google.com ([209.85.128.53]:33716) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kPr4Y-0003Jb-EK for 43830@debbugs.gnu.org; Tue, 06 Oct 2020 13:48:22 -0400 Original-Received: by mail-wm1-f53.google.com with SMTP id z22so2754791wmi.0 for <43830@debbugs.gnu.org>; Tue, 06 Oct 2020 10:48:22 -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=tyXCOsNDZ0Z5br9Um4qZbf6Xv91SS7NuZbO5Dphh6j4=; b=gus5narMPpLK5PTV/IdH44JOm5U81iIf+NVSx2EvugxS/aNkJA2AY6zFoqWAgSy7S3 hVm5uYIi6v4Q6XViBrt1vXjXhYQ4HZtx/IEQgbjzk3IUJwhiwqqJDGVcxRvFghplifAP vR+f3kYj50ocJaKm7cmPpWd//4oC0E/vMviGgOW5nYtDEO6cef18y0N3xbxHPusJAzUq 80HODBRK1XhHE++5qDhFxZ4GjNTTELvOBe5FBwA+a/9G/bpq4i+b/htDWaOMOsAbaERX UX1ru2NnyV1h+MKwMTTMbwHqNVui26Ya3nkaNPld9eiXgNyom2v/M/sEGQm+wruq7/Ya 1tLw== 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=tyXCOsNDZ0Z5br9Um4qZbf6Xv91SS7NuZbO5Dphh6j4=; b=GRW8DpObwhOOwb6uJT92xLWwJTw6NljWR2kuoS90NFvGXhaCJWRPEMQBlRjDIXdbWZ hYemfrhCZK7kYBIIGWv1jFoeOxwvCB7ZTDkhaCrexyfRgZm3n/52yQczhhAebv9O0Vup VsfusH0OjOTVjgnkLy0RbSg4RM/hIBC8Z//XcZjnndcxQW2ExyJuf/W/aOYDNavxHdV7 UZdFNABlPGFwzeU9wCdeV6ilt72bFxiPO/2/QUu1IAkp2QwskmR14ujAlOU726YnO9Li za3HcmTetIKts/6F+VxBqZwFyFsZ8PogjBA/3+ZwUp71dRVeM7VPTZzfqOwV9BVlAwna ueIA== X-Gm-Message-State: AOAM532ID8y+zjR1fGAbgGqOLLvc6lfcY0g1kXdO1Qum4IUj9SK1hkaB UpP2Y+Mx5MhgzAzuXL4Vhh2VvgEJucbbWGjTcA== X-Google-Smtp-Source: ABdhPJxDq2I7pGTspe9GMUxmb0TU0LfMq7iQWHMmGBjr2t3hyW7LMUTwKtcRBEUKJ/0oVoehy67Ek0MEqOj0yZqVaZk= X-Received: by 2002:a7b:c081:: with SMTP id r1mr6011075wmh.158.1602006496402; Tue, 06 Oct 2020 10:48:16 -0700 (PDT) In-Reply-To: <83r1qb9sgl.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:189922 Archived-At: --00000000000025614a05b1043426 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Do you know how to retrieve the key code corresponding to the English > keyboard layout when the active layout is something else, like > Russian? No, but there must be a way, because both GTK+ and KDE know how to do this. GTK+ also can do this when run under KDE, so I'm pretty sure the information itself comes from X (xkb), not e.g. from GNOME configuration. No idea about the other way round, but I guess it also works. > Or maybe the keyboard driver can be configured to return ASCII > characters when the Ctrl key is held, even when the layout is > non-English? Not sure what you mean here, but certainly it doesn't need to be configured by the user. Maybe by the application/framework (i.e. KDE, GTK+ or Emacs). > A workaround is to bind C-=D1=8B to the same command as C-s (and similarl= y > with other combinations that matter). This is not feasible because Emacs has hundreds of shortcuts coming from all sorts of places (the core, major and minor modes, my config and so on). It's certainly not just about C-s. By the way, same goes for shortcuts/keybindings even without modifiers. E.g. I have my own keybinding to switch to *scratch* buffer. is, predictably, "undefined". However, if using Emacs' own Rus= sian input method, it works just like , even though the key on itself types "=D1=8B". Paul On Tue, 6 Oct 2020 at 19:26, Eli Zaretskii wrote: > > From: Paul Pogonyshev > > Date: Tue, 6 Oct 2020 17:34:34 +0200 > > > > I use English and Russian keyboard layouts. For every single applicatio= n > I don't need to care which layout is > > currently selected for shortcuts, e.g. Ctrl+S and Ctrl+=D0=AB do the sa= me (S > and =D0=AB are on the same physical > > key). Of course, in Emacs it doesn't work this way: C-s triggers > Isearch, but C-=D1=8B "is undefined". > > Do you know how to retrieve the key code corresponding to the English > keyboard layout when the active layout is something else, like > Russian? Does someone else here know? > > Or maybe the keyboard driver can be configured to return ASCII > characters when the Ctrl key is held, even when the layout is > non-English? > > What Emacs does, AFAICT, when a key press event comes in is call the > Xlib function that returns the character produced by the keyboard, and > that character depends on the current keyboard layout. We then add > the modifier keys to that character. I don't see the "original" > English-layout character available anywhere in that code, but maybe > I'm missing something. > > A workaround is to bind C-=D1=8B to the same command as C-s (and similarl= y > with other combinations that matter). > --00000000000025614a05b1043426 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Do you know how to retrieve the key code correspondin= g to the English
> keyboard layout when the active layout is somethin= g else, like
> Russian?

No, but there must be = a way, because both GTK+ and KDE know how to do
this. GTK+ also c= an do this when run under KDE, so I'm pretty sure the
informa= tion itself comes from X (xkb), not e.g. from GNOME configuration.
No idea about the other way round, but I guess it also works.
<= br>
> Or maybe the keyboard driver can be configured to return= ASCII
> characters when the Ctrl key is held, even when the layout i= s
> non-English?

Not sure what you mean = here, but certainly it doesn't need to be configured
by the u= ser. Maybe by the application/framework (i.e. KDE, GTK+ or Emacs).

> A workaround is to bind C-=D1=8B to the same command = as C-s (and similarly
> with other combinations that matter).
<= br>
This is not feasible because Emacs has hundreds of shortcuts = coming from
all sorts of places (the core, major and minor modes,= my config and so on).
It's certainly not just about C-s.

By the way, same goes for shortcuts/keybindings even = without modifiers.
E.g. I have my own keybinding <f12 s> to= switch to *scratch* buffer.
<f12 =D1=8B> is, predictably, = "undefined". However, if using Emacs' own Russian
i= nput method, it works just like <f12 s>, even though the key on itsel= f
types "=D1=8B".

Paul

On Tue, 6 Oct 2020 at 19:26, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Paul Pogonyshev <pogonyshev@gmail.com>
> Date: Tue, 6 Oct 2020 17:34:34 +0200
>
> I use English and Russian keyboard layouts. For every single applicati= on I don't need to care which layout is
> currently selected for shortcuts, e.g. Ctrl+S and Ctrl+=D0=AB do the s= ame (S and =D0=AB are on the same physical
> key). Of course, in Emacs it doesn't work this way: C-s triggers I= search, but C-=D1=8B "is undefined".

Do you know how to retrieve the key code corresponding to the English
keyboard layout when the active layout is something else, like
Russian?=C2=A0 Does someone else here know?

Or maybe the keyboard driver can be configured to return ASCII
characters when the Ctrl key is held, even when the layout is
non-English?

What Emacs does, AFAICT, when a key press event comes in is call the
Xlib function that returns the character produced by the keyboard, and
that character depends on the current keyboard layout.=C2=A0 We then add the modifier keys to that character.=C2=A0 I don't see the "origin= al"
English-layout character available anywhere in that code, but maybe
I'm missing something.

A workaround is to bind C-=D1=8B to the same command as C-s (and similarly<= br> with other combinations that matter).
--00000000000025614a05b1043426--