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: Fri, 03 Jan 2025 23:55:49 -0500 Message-ID: References: <31bdc55d-8c13-4de0-9cef-bd6cc4fb033f@imayhem.com> <705fabb8-1ea0-4894-8c32-05097ab822c9@imayhem.com> <868qsvz07i.fsf@gnu.org> <162dada7-ad54-4ca5-8f11-d55dd6dccb3c@imayhem.com> <867c8ezny3.fsf@gnu.org> <86bjxev7ng.fsf@gnu.org> <343e2854-a16e-4718-894a-470b733ae91f@imayhem.com> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24603"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: luangruo@yahoo.com, 74423@debbugs.gnu.org, Eli Zaretskii To: Cecilio Pardo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 04 05:57:30 2025 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 1tTwE5-0006G1-EW for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jan 2025 05:57:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTwDj-0004pf-ES; Fri, 03 Jan 2025 23:57:07 -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 1tTwDf-0004pQ-0k for bug-gnu-emacs@gnu.org; Fri, 03 Jan 2025 23:57:03 -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 1tTwDe-0004Of-OY for bug-gnu-emacs@gnu.org; Fri, 03 Jan 2025 23:57: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=24dLY3Nd4Z4zhqjL9RnLC/boiy8M2vjPlfJistbgnyo=; b=apSJcubwtvUl2wi6Poqpo4Ygrr2S1Iyg5YoF3uyxyyDQaGwkOxI10vJTUolfUKm70sMFzHB8EPn9I6UZMP/RC/XMde5LIau0UuZdzSQ7ZsIRrs2RM4h0jKU7mDdee1jQNuf/IWSrb5XvHgGHKagzgKLtguHlubnwwzLqAmG31bVF1WJ4P2g+cKnr7bp2XVzCddMBeAHpmsJymewlHMk1HvZndYP376GMNai8gGr7gaqIvjEQhvb0cvGV4igoxtGbcm2XhfjIV30n0g384mh0fQE6G5ZnkQv/p6g3A0CP+XbSQmLiUhNPN5OXg2vUt5CNX3EY0AkA/u9Uqw4xN8fFaQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tTwDe-0000vD-0j for bug-gnu-emacs@gnu.org; Fri, 03 Jan 2025 23:57: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: Sat, 04 Jan 2025 04:57: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.17359665643468 (code B ref 74423); Sat, 04 Jan 2025 04:57:01 +0000 Original-Received: (at 74423) by debbugs.gnu.org; 4 Jan 2025 04:56:04 +0000 Original-Received: from localhost ([127.0.0.1]:52970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTwCh-0000tr-CX for submit@debbugs.gnu.org; Fri, 03 Jan 2025 23:56:03 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63226) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTwCd-0000tJ-3q for 74423@debbugs.gnu.org; Fri, 03 Jan 2025 23:56:01 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0AD83440CF4; Fri, 3 Jan 2025 23:55:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1735966550; bh=6OFTmN76rrqJg49/MJWDIYKBUnyg9dVNUi7iW2eyJ9A=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=SBVzCp99zvUEw3YRKn+3uZ98hZk1dmqU3UVlUArvD3e8N+9SzJ0JK5xl/pmgudkxL H+Uu5H6G2X1op1r0769EevKcTc8O7XcgC5iudEg3N85AIrvv3wDaiSNHwYeFfduUlF XoztAanJmD5tI7GTT742g4WDVq62zprYH+RtM3jSmBbAW1+Os9Y0itNL62XRco+09p 6njeAw+e7Hs6NzyE2Pt7IQTZ1NWcR5NhG7W1U0iFiQ72QMB29Tau653TQeDU5qbTVW qHKhi0xNquyASlj4feVIaSHbo76j9cVEQNv4pjYUX8biWvmkC3dMoISWq2gnwcnGJl v0LuNM2LYAyhA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1FE32440CDE; Fri, 3 Jan 2025 23:55:50 -0500 (EST) Original-Received: from alfajor (104-195-200-87.cpe.teksavvy.com [104.195.200.87]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D4484120070; Fri, 3 Jan 2025 23:55:49 -0500 (EST) In-Reply-To: (Cecilio Pardo's message of "Thu, 2 Jan 2025 16:42:34 +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:298323 Archived-At: > In this new version I changed the way events are handled. > Now llk-handle generates input events to be used with normal > keymaps, instead of running a command. The function llk-bind > activates event generation for a key and a combination of > events press, release, double, triple. I really like what I see. As I think I mentioned, I had made a related effort in local patches, but I couldn't figure out back then how to make the low-level events useful. I wouldn't be surprised if such low-level events remain limited in their use, but I suspect that some specific uses of them could become very popular. I haven't seen many opinions of late on your code (other than my own), sadly. I think we need some more reviewers here. > You suggested to auto generate the keysym table, but we > would still need a table to relate the Windows keys to the X > equivalent. I don't doubt some part has to be done manually, but I think we should strive to make it via code as much as possible. E.g. on each platform we should try to provide a programmatic way to map the integer key to/from a meaningful system-specific string or symbol (at least, to the extent that the underlying system provides such a functionality). Mapping between those symbols in different systems will likely be (at least partly) manual, inevitably, but I'm hoping this can be significantly smaller (especially I'm hoping we can "align" the system-specific symbols such that many are already identical between the different systems). Finally it's not 100% indispensable to have unified symbols that work identically on all systems: users could also just use the system-specific names. They'd need a mapping between them only for code/configuration that is used with different systems. So it's only really important when those names start to be used in libraries. > +@cindex @code{low-level-key} event > +@item (low-level-key @var{is-key-press} @var{key} @var{modifier} @var{time} @var{frame}) > +This event is sent on the physical press or release of keys, only on > +systems where it is supported, currently X, MS-Windows and PGTK, and > +only if the variable @code{enable-low-level-key-events} has a > +non-@code{nil} value. See its documentation for the values to use, that > +can activate the events for all or some keys. > + > +@var{is-key-press} is @code{t} for a key press, @code{nil} for a key > +release. @var{time} is the event's time in milliseconds, as reported by > +the underlying platform, and should only be used to measure time > +intervals between events of this same kind. [ This made me wonder if those timestamps can be compared between events coming from different X11 servers. ] > @var{frame} is the frame +receiving the event. Any chance this could be changed to a window? [ What does it even mean? Usually we associate keyboard events with the `window-point` of the currently selected window (and they don't come with the information attached), whereas we associated mouse events with the position of the mouse cursor. But when I do `down-meta down-mouse-1 up-mouse-1 up-meta` to generate a `M-mouse-1` event, the events on the `meta` key end up associated with the position of the mouse cursor even tho they come from the keyboard. ] > @var{modifier} is @code{nil} if the key is not a > +modifier key, @code{t} if it is, but it is unknown which one, or one of > +@code{shift}, @code{control}, @code{meta}, @code{alt}, @code{super}, > +@code{hyper}. In the docstring you mention that PGTK can't distinguish modifiers. It would be useful here to mention here also the kinds of reasons why we might get just `t`: can it happen for some keys and not others, or is it the case for all the events of a given kind of terminal? > Loading @file{low-level-key.el} sets a handler > +that can generate normal input events for key press, release and multi > +tap. See the function @code{llk-bind}. Any other ELisp code could do a similar task, tho. So, I'd probably present it a bit differently, like: Because generating these events for all keys would interfere with normal keyboard input, they are by default filtered out by a binding in `special-event-map`. @file{low-level-key.el} is a package that lets you configure which of those events to turn into normal input events. It is also able to recognize some specific patterns such a (multi) taps. [ BTW, you might like to explain what is a (multi) tap here, as well. ] > +(cl-defstruct (low-level-key (:type list)) I recommend you add `(:constructor nil)` and `(:copier nil)` so the macro doesn't auto-define `make-low-level-key` and `copy-low-level-key` functions. > +(defvar llk-bindings nil > + "List of bindings for low level key events (press/release/tap). > +Use the `llk-bind' function to add bindings. See its documentation for > +a description of the binding information.") [ Seeing how it's used, I suggest you use a hash-table instead of a list. ] > +EVENTS are symbols that activate one event. Possible values are `press', > +`release', `double' and `triple'. Any reason why there isn't an option to emit an event for a single press+release? > + (llk-bind xk-shift-l \\='double) > + > +will generate the event `double-xk-shift-l', than can be bound to a > +command with: AFAICT the event will be named `double-key-xk-shift-l`. Did I miss something? [ I like this "key-" in the event name, FWIW, so I suggest to keep the code but fix the doc rather than the reverse. Tho, if we can drop the `xk-`, I'd be happier yet. Maybe the generated event names should have "llk-" in them instead of "key-". ] > +(defun describe-low-level-key () > + "Wait for key press and describe the low-level key event it generates." > + (interactive) > + (define-key special-event-map [low-level-key] 'llk--describe)) This is brittle. I don't really have a better suggestion, sadly, but it deserves a comment. > +(setq llk-bindings nil) Why? Also the file lacks the usual end of file marker (and the call to `provide`). I'll try and take a look at the C code later. Stefan