From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#74423: Low level key events Date: Tue, 19 Nov 2024 11:43:08 -0500 Message-ID: References: <31bdc55d-8c13-4de0-9cef-bd6cc4fb033f@imayhem.com> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27243"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 74423@debbugs.gnu.org To: Cecilio Pardo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 19 17:44:26 2024 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 1tDRKz-0006uv-AD for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 Nov 2024 17:44:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tDRKl-00049t-JT; Tue, 19 Nov 2024 11:44:12 -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 1tDRKe-000499-4N for bug-gnu-emacs@gnu.org; Tue, 19 Nov 2024 11:44:05 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tDRKc-00043s-Dy for bug-gnu-emacs@gnu.org; Tue, 19 Nov 2024 11:44:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=8Bn0PczNjufGMQSBKSmigf4i0hKKWWr8ZDuPDJ9GxuM=; b=k0S8+zp6rk47Yo5NXBMwg5zTq/kjrbVeICcA3G7xAIchICKQ9GCoNLc0NFZe2RAtgiMBFtgIknM+b+uNTpuOhmxfbLQK023/MAvwf6n99Yc9dVUn0UYiCz9xdBareHnO8FpnsEIJ2aFr490WU/lrNvuRYg4CzfMzinHgdjxOAJqzotme1qHJaahwaB2DlvdfPbDVZxoX34q1nq8slFF4zHOUt23W9itmNcVUPeY2EZwCamQMDGth5uV2t47xEOltQBkenML5QL+zItaq6X/CnMzP7m5Ql8Wrqub+wre5LV4sh8B32Ma4GLdTocT6n0q/GnmgN0PlGzpWiKrb2BeKUw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tDRKc-0006zq-0H for bug-gnu-emacs@gnu.org; Tue, 19 Nov 2024 11:44:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Nov 2024 16:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74423 X-GNU-PR-Package: emacs Original-Received: via spool by 74423-submit@debbugs.gnu.org id=B74423.173203460226834 (code B ref 74423); Tue, 19 Nov 2024 16:44:01 +0000 Original-Received: (at 74423) by debbugs.gnu.org; 19 Nov 2024 16:43:22 +0000 Original-Received: from localhost ([127.0.0.1]:43814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tDRJx-0006yk-Se for submit@debbugs.gnu.org; Tue, 19 Nov 2024 11:43:22 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tDRJv-0006yW-D5 for 74423@debbugs.gnu.org; Tue, 19 Nov 2024 11:43:20 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CBC28444FC9; Tue, 19 Nov 2024 11:43:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1732034591; bh=x0U5QRphRWOBhk3qTb+t1GYb3TTKXwrTBdou9IHDK4k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=TGxWCQ7QfpmZFyNlgQgVwZe7NIYKAS+KWhrwf+CCz8DtRFcwAfQHuLW+l5kw1FVV9 s3Vkynne5Pb6M27mgIvciUE5R+7KKyGwy0M/af5AL2Q7/+Pu5wxagEZHQCG9mG7z61 NxIu2luKuze2gwpQjBYOSG2YHPEUIioZgtHy8GSFX5aLfUf+25l8JhQjvZbuByXJ4/ hQp7ZPo9uROQPK5CzBsWIoBnfiLzFxZ7cA7kuWeTQCjGLYuDNlgeuEMGZ/dJLJ1zQp YwUTOE+XU5wUION6r7yX1HjFOHNLXR8U7BL1ZBqoFFIUNZx4wELGGNgn0G0fK3hG/+ Xxhq0NKJ56ILQ== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 46EB5444FC1; Tue, 19 Nov 2024 11:43:11 -0500 (EST) Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 35F50120370; Tue, 19 Nov 2024 11:43:11 -0500 (EST) In-Reply-To: (Cecilio Pardo's message of "Mon, 18 Nov 2024 21:35:40 +0100") 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:295646 Archived-At: > It provides events for press/release of keys, independently of the normal > keyboard events. These events are bound int the special-event-map. Some l= isp > is included to implement detection of multiple tapping on keys, and runni= ng > commands or simulating modifiers. I hadn't followed the discussion over at emacs-devel, but this is cool. I used to have a local patch which generated extra events for all key presses/releases. I never wrote any useful Lisp-level code for it (all I had were bindings to ignore those events so Emacs was still usable =F0=9F=99=82), but I really think it would make for fun new hacks. I haven't had time to look at your whole patch, but here are some comments. > + (let ((key (cl-third last-input-event))) Please try and use `event-*` functions. If none serve (as will often be the case), define local "replacements" until they can be promoted to `subr.el`. > + ((functionp func) (funcall func)) > + ((eq 'hyper func) > + (message "H-...") > + (let ((r (read-event))) > + (setq unread-command-events > + (list (event-apply-modifier > + r 'hyper 24 "H-")))))))))) Move that code to a function, so you can get rid of this `hyper` special case. BTW, any reason why you couldn't use `event-apply-hyper-modifier`? [ BTW, this becomes more ... interesting ... when you want to be able to cumulative that for several modifiers, in which case your `read-event` might return an event which is not the one to which you want to add `H-`. ] > + switch (keysym) > + { > + case GDK_KEY_Shift_L: key =3D Qlshift; break; > + case GDK_KEY_Shift_R: key =3D Qrshift; break; > + case GDK_KEY_Control_L: key =3D Qlctrl; break; > + case GDK_KEY_Control_R: key =3D Qrctrl; break; > + case GDK_KEY_Alt_L: key =3D Qlalt; break; > + case GDK_KEY_Alt_R: key =3D Qralt; break; > + default: > + key =3D Qnil; > + } > + > + switch (keysym) > + { > + case GDK_KEY_Shift_L: > + case GDK_KEY_Shift_R: > + modifier =3D Qshift; > + break; > + case GDK_KEY_Control_L: > + case GDK_KEY_Control_R: > + modifier =3D Vx_ctrl_keysym; > + if (NILP (modifier)) > + modifier =3D Qctrl; > + break; > + case GDK_KEY_Alt_L: > + case GDK_KEY_Alt_R: > + modifier =3D Vx_meta_keysym; > + if (NILP (modifier)) > + modifier =3D Qalt; > + break; > + case GDK_KEY_Meta_L: > + case GDK_KEY_Meta_R: > + modifier =3D Vx_meta_keysym; > + if (NILP (modifier)) > + modifier =3D Qmeta; > + break; > + case GDK_KEY_Hyper_L: > + case GDK_KEY_Hyper_R: > + modifier =3D Vx_hyper_keysym; > + if (NILP (modifier)) > + modifier =3D Qhyper; > + break; > + case GDK_KEY_Super_L: > + case GDK_KEY_Super_R: > + modifier =3D Vx_super_keysym; > + if (NILP (modifier)) > + modifier =3D Qsuper; > + break; > + default: > + modifier =3D Qnil; > + } I think the list of low-level keys handled here should not be hard-coded. IOW, maybe `enable-low-level-keys` should not be a boolean but a list/map/table indicating which keys to handle. > + if (!NILP (key)) > + { > + EVENT_INIT (inev.ie); > + XSETFRAME (inev.ie.frame_or_window, f); > + inev.ie.kind =3D LOW_LEVEL_KEY_EVENT; > + inev.ie.timestamp =3D xkey.time; > + inev.ie.arg =3D list2 (is_press ? Qt : Qnil, key); > + kbd_buffer_store_buffered_event (&inev, &xg_pending_quit_event); > + } > + > + if (!NILP (modifier)) > + { > + EVENT_INIT (inev.ie); > + XSETFRAME (inev.ie.frame_or_window, f); > + inev.ie.kind =3D LOW_LEVEL_MODIFIER_KEY_EVENT; > + inev.ie.timestamp =3D xkey.time; > + inev.ie.arg =3D list2 (is_press ? Qt : Qnil, modifier); > + kbd_buffer_store_buffered_event (&inev, &xg_pending_quit_event); > + } > +} So, IIUC you might generate 2 low-level events for a single key press? Why? Other note: in the distant past (back around Emacs-21) I seem to remember Gerd making changes to the event structure so as to avoid allocating Lisp objects for this code. I think it was related to problems due to running this low-level event-handler code from within a C signal handler, which is a practice was have since stopped, luckily, but maybe there are still good reasons to try and avoid involving allocating objects into the Lisp heap in this low-level code. Stefan