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: Sun, 1 Nov 2020 17:51:00 +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> <87blghbjpn.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e5dd1305b30e6fa3" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27124"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43830@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 01 17:54:34 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 1kZGck-0006xY-MD for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Nov 2020 17:54:34 +0100 Original-Received: from localhost ([::1]:58064 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZGcj-0003A3-LZ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Nov 2020 11:54:33 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43664) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZGaI-0001Oy-Gy for bug-gnu-emacs@gnu.org; Sun, 01 Nov 2020 11:52:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55026) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kZGaI-0008S3-4t for bug-gnu-emacs@gnu.org; Sun, 01 Nov 2020 11:52:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kZGaI-0001s5-3G for bug-gnu-emacs@gnu.org; Sun, 01 Nov 2020 11:52:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Paul Pogonyshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Nov 2020 16:52: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.16042494797144 (code B ref 43830); Sun, 01 Nov 2020 16:52:02 +0000 Original-Received: (at 43830) by debbugs.gnu.org; 1 Nov 2020 16:51:19 +0000 Original-Received: from localhost ([127.0.0.1]:38339 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZGZb-0001rA-Bn for submit@debbugs.gnu.org; Sun, 01 Nov 2020 11:51:19 -0500 Original-Received: from mail-wr1-f46.google.com ([209.85.221.46]:47067) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZGZZ-0001qy-Rq for 43830@debbugs.gnu.org; Sun, 01 Nov 2020 11:51:18 -0500 Original-Received: by mail-wr1-f46.google.com with SMTP id k10so10501870wrw.13 for <43830@debbugs.gnu.org>; Sun, 01 Nov 2020 08:51:17 -0800 (PST) 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=jyg6qJX6sBzwA41BJ6vmfy3nXJtJrlCmyPNdoiQ8niE=; b=TAT+y55JzuuY09RF1RZn6IAu6Dj4AbZEsLLJ05MtLFdCoJgWy/wvnqxTW7VC6YKJw6 43y3YEoy73F8/H9QFcvrhbO9sEQKq/j5R7nR5rqfpFB6fVFy2tNbMDPvoDivFbzdZiL3 Tns10IAOWlT9gLA4F4PYuRpd2rnNzDf8191ZP6BamMQQ5kWJjWj2JWIXpZBYmxUfF5T/ wY1jO2tFam5qBPA4GqiEaV7RmJt7pSdS27JwScM1l0FNKP4iYzxz8R9Tq+aEX3ytyahN h4zG+RBdVFHMN7SiKCWDMCgM9Uxn3AgHN+H/Tf2SEGg2RxN7KHGCBjvurrV5WWcVIkSN D8Wg== 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=jyg6qJX6sBzwA41BJ6vmfy3nXJtJrlCmyPNdoiQ8niE=; b=ujS9HvI8ak8wBLhWMF/jeDmVY6qiuXSY9lZZHbpHprG05nCUXncS9V4nlcIfyQi3R+ NzIgikFnodEmJhXVagX8GrCu3MevxOpjjLwAgEyX3F7kUWnrYaBjW85nxcoW+E5Z5YQU qWKKlaADeiHJ0oAAoHvQUC2uJpZyYnQtGeF7jXeL4ErGwNtohHpfRP8rkyf0wwY+Pm0r 58B/ZF7Gp8YpcWu7F6LiKd0Wn5Hrtyx58K3bugVy8o0NHC8LS1rUljtaahf8WjDGXJA0 Hah2jbQkN1XDwBbNBGSnkbvu0iqTpu0c1OLzrBZdi4NyWk1A+GkEijtcptHBxQZx8VTD vS7w== X-Gm-Message-State: AOAM533pTkxRhKArDK+Ov10ke6ISsK3BTR6yZjR7NnQLMBBNFrNCwUo0 0AwysW56l1t6b8vbiBRS8CmbYD3lkL/eRCnmtw== X-Google-Smtp-Source: ABdhPJzkD72/TBedAmaY6H/i08H8Vo2smqewtxiVex3eqnb2pG5BncD/uMQ8k6AKjS0axU+HD/a/E74uVg4bShKGAOo= X-Received: by 2002:adf:b19c:: with SMTP id q28mr15093609wra.119.1604249471801; Sun, 01 Nov 2020 08:51:11 -0800 (PST) In-Reply-To: <87blghbjpn.fsf@mail.linkov.net> 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:192415 Archived-At: --000000000000e5dd1305b30e6fa3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Could you please give an example how you bind such key sequences as > 'C-.' and 'C-=D1=87 =D0=B9' in Emacs input modes? How they do translatio= n > to physical keys without using xkb? I don't and that's the whole point. I want that when _any_ keymap defines `M-q', this keybinding can be activated by typing M-q or M-=D0=B9, because this is the same physical key. Automatically. `reverse-im' achieves this but _only_ for keys that type letters in the second layout. E.g. M-/ (which I often use) won't work in Russian layout because that physical letter types '.' in this layout. > > What about functions like `read-event'? It returns integers if I press > > M-[letter] or C-[letter]. > > read-event is also implemented in C. But maybe I don't understand > your question. I mean, what about the cases where it is called from Elisp? It is implemented in C, but also is publicly available. I have come up with two ideas: 1. `read-event' and its internal C implementation grow an optional parameter that says whether to return character as if being typed (as now) or for keybinding use (i.e. from physical keys). 2. Alternatively, if this cannot be determined in advance (i.e. before calling `read-event' etc.), these functions could set variable named sth. like `last-keybinding-keycode'. Then the caller would use either the return value (as now) or, if it wants, the value of the variable instead. Paul On Sun, 1 Nov 2020 at 09:01, Juri Linkov wrote: > >> 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 layo= ut. > > If it is a self-inserting command, character '=D0=B9' should be added t= o 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-=D1=87= =D0=B9' is > > translated to 'C-x q'. > > What is worse is that in a writable buffer, typing '=D0=B9' should insert > this character untranslated, but in the same buffer when it's in > read-only view mode, typing the same '=D0=B9' should translate it to 'q' > and quit the buffer with the View-quit command. When using reverse-im > with local-function-key-map, the Help buffer says: > > q (translated from =D0=B9) runs the command View-quit. > > So the question is whether it's possible to do the same using > XkbTranslateKeyCode? The local-function-key-map is smart enough > to not translate self-inserting keys. Can code for XkbTranslateKeyCode > use the same condition to detect self-inserting keys? > --000000000000e5dd1305b30e6fa3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Could you please give an example how you bind such ke= y sequences as
> 'C-.' and 'C-=D1=87 =D0=B9' in Emacs= input modes?=C2=A0 How they do translation
> to physical keys withou= t using xkb?

I don't and that's the whole po= int. I want that when _any_ keymap
defines `M-q', this keybin= ding can be activated by typing M-q or M-=D0=B9,
because this is = the same physical key. Automatically.

`reverse-im&= #39; achieves this but _only_ for keys that type letters in
the s= econd layout. E.g. M-/ (which I often use) won't work in Russian
<= div>layout because that physical letter types '.' in this layout.

> > What about functions like `read-event'? It returns integer= s if I press
> > M-[letter] or C-[letter].
>=C2=A0
> read-event is also implemented in C.=C2=A0 But maybe I don't unde= rstand
> your question.

I mean, what abo= ut the cases where it is called from Elisp?=C2=A0 It is
implement= ed in C, but also is publicly available.

I have co= me up with two ideas:

1. `read-event' and its = internal C implementation grow an optional
parameter that says wh= ether to return character as if being typed (as
now) or for keybi= nding use (i.e. from physical keys).

2. Alternativ= ely, if this cannot be determined in advance (i.e. before
calling= `read-event' etc.), these functions could set variable named sth.
like `last-keybinding-keycode'. Then the caller would use either = the
return value (as now) or, if it wants, the value of the varia= ble instead.

Paul

On Sun, 1 Nov 2020 at 09:01= , Juri Linkov <juri@linkov.net>= ; wrote:
>>= ; Why would you need that?=C2=A0 If we decide to use XkbTranslateKeyCode, w= e
>> could translate the keycode in C, according to some logic that too= k
>> 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 Rus= sian layout.
> If it is a self-inserting command, character '=D0=B9' should b= e added to the
> active buffer. But if I'm typing a multikey binding, it should be<= br> > interpreted as 'q' (it's the same physical key), so that e= .g. 'C-=D1=87 =D0=B9' is
> translated to 'C-x q'.

What is worse is that in a writable buffer, typing '=D0=B9' should = insert
this character untranslated, but in the same buffer when it's in
read-only view mode, typing the same '=D0=B9' should translate it t= o 'q'
and quit the buffer with the View-quit command.=C2=A0 When using reverse-im=
with local-function-key-map, the Help buffer says:

=C2=A0 q (translated from =D0=B9) runs the command View-quit.

So the question is whether it's possible to do the same using
XkbTranslateKeyCode?=C2=A0 The local-function-key-map is smart enough
to not translate self-inserting keys.=C2=A0 Can code for XkbTranslateKeyCod= e
use the same condition to detect self-inserting keys?
--000000000000e5dd1305b30e6fa3--