From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Physical keyboard events Date: Tue, 05 Nov 2024 15:13:32 +0200 Message-ID: <86fro5u8lf.fsf@gnu.org> References: <31bdc55d-8c13-4de0-9cef-bd6cc4fb033f@imayhem.com> <19ab52d0-88bd-4378-8fa8-8603e01233e3@imayhem.com> <871pzrl4sn.fsf@yahoo.com> <87o72vjk1f.fsf@yahoo.com> <86fro7uo6h.fsf@gnu.org> <87bjyvjdk2.fsf@yahoo.com> <867c9juetb.fsf@gnu.org> <87wmhiihzx.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26517"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpardo@imayhem.com, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 05 14:14:38 2024 Return-path: Envelope-to: ged-emacs-devel@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 1t8JOI-0006p1-Fv for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Nov 2024 14:14:38 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t8JNP-0002Eh-RH; Tue, 05 Nov 2024 08:13:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t8JNO-0002E1-Ll for emacs-devel@gnu.org; Tue, 05 Nov 2024 08:13:42 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t8JNM-0004gj-HQ; Tue, 05 Nov 2024 08:13:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=l4XcjUugxUByAN0BDmbugQPXZ0siXlyzk1eSeTVkfwM=; b=ZhBb1lPDd3Hw 0JdaDgJZWnrzuLccasj0evHjX8IgVKz9GATCSU0EXrpiiRQsFvqhUuPPcW4suQtNV5OGLLuyXgN6D WFFkuQDjQN7rCLhp9S3d0M2iB1S/f8NXgftIp61HhROKIy7J+PG3dmKyJrSfdNywriHKeGMfUCGd/ vVkuR+lmpLfcay7ElfgzY2/003Y1cZv8oLeObIwIiSLxHV+pXmmW15vUMdSJuz7zdOQxGI0rHYC5g iKdbM8pt17VO3BA100FjnKuoLh0CdKLDpDPv/9Ed7qSGUhKR99JpKYKqalyOHZRg4+ACE/qQ7gjpF HwR3+mS8edkyuMcbvI9nhA==; In-Reply-To: <87wmhiihzx.fsf@yahoo.com> (message from Po Lu on Tue, 05 Nov 2024 09:31:14 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:325137 Archived-At: > From: Po Lu > Cc: cpardo@imayhem.com, emacs-devel@gnu.org > Date: Tue, 05 Nov 2024 09:31:14 +0800 > > Eli Zaretskii writes: > > > On _physical_ level, there can be no "exchange of keys". That > > exchange exists on the logical level, where Ctrl followed by A yield a > > single event whose value is 1, instead of 4 events (2 keypresses and 2 > > releases), none of which is 1. > > No, that is configuring Caps Lock to serve as a Ctrl latch. I'm > speaking of remapping such a key to serve as _the_ Ctrl modifier, such > that Caps_Lock+A yields an XK_Caps_Lock event that is discarded by Emacs > as a modifier key, followed by a second event whose value is, yes, ^A, > and with the Ctrl modifier bit set in its state. I'm talking about a program that doesn't want to see ^A, since there's no such key. > >> The only reasonable manner of reporting these key events is reporting > >> the modifiers that Emacs will generate in response to them. The other > >> correct approach, that of reporting X modifier bits uninterpreted, > >> yields physical keys that are just as meaningless (ctrl, shift, mod1, > >> mod2, mod3, and so forth) and with equally tenuous a relationship with > >> the modifiers that users expect to receive from Emacs. > > > > They are presumably not meaningless to a Lisp program which wants to > > receive such events. Or at least this is my understanding. > > I am interested to hear what use Lisp programs intend to make of a mod2, > mod3, mod4, and mod5, whose meanings vary wildly from one machine to the > next. A program which wants to show the pressed key, for example? > On my system, for example: > > shift Shift_L (0x32), Shift_R (0x3e) > lock Caps_Lock (0x42) > control Control_L (0x25) > mod1 Alt_L (0x40), Alt_L (0xcc), Meta_L (0xcd) > mod2 Num_Lock (0x4d) > mod3 ISO_Level5_Shift (0xcb) > mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf) > mod5 ISO_Level3_Shift (0x5c) > > while on another: > > shift 44 57 # Left Shift, Right Shift > lock 30 # CapsLock > control 58 64 # Control > mod1 59 63 # Meta > mod2 62 # AltGraph > mod3 90 # NumLock > mod4 60 # Left Alt > mod5 65 # Compose I don't understand what this means, sorry. (You seem to be too deep in the particulars of the X keyboard handling.) I never said anything about mod1 etc. > Without consulting the X11 modifier keymap (which is impossible from > Lisp), how should a Lisp program derive any meaning from these modifier > bits, or the keys to which they are assigned? I don't know. I didn't write the patch. All I'm saying is that if the key is labeled Alt, I can envision some Lisp programs which will want to know the key pressed was Alt, not Meta. > > I can also accept that in addition we should have some intermediate > > level, whereby some key translations are performed. But then we'd > > need to agree which translations are or aren't taken into > > consideration. In the above example, does Ctrl+A produce 01 decimal? > > does Ctrl-[ produce ESC? what do the keys produce when the keyboard's > > language is not English? etc. And whether to perform this or not > > should be controllable by Lisp. > > This reaches far beyond the scope of just reporting modifier activation > that is usually discarded by Emacs (and which is always reported by the > X server). So? Emacs reaches far beyond many things. We should ideally decide what we want this feature to do, and then see how to implement it, not the other way around.