From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Cecilio Pardo Newsgroups: gmane.emacs.devel Subject: Re: Physical keyboard events Date: Mon, 4 Nov 2024 09:03:58 +0100 Message-ID: <19ab52d0-88bd-4378-8fa8-8603e01233e3@imayhem.com> References: <31bdc55d-8c13-4de0-9cef-bd6cc4fb033f@imayhem.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28793"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 04 09:04:47 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 1t7s4s-0007Qe-Nn for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Nov 2024 09:04:46 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t7s4E-0007Bx-Jt; Mon, 04 Nov 2024 03:04:06 -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 1t7s4C-000793-Oo for emacs-devel@gnu.org; Mon, 04 Nov 2024 03:04:04 -0500 Original-Received: from mail.imayhem.com ([82.223.54.191] helo=zealous-pike.82-223-54-191.plesk.page) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t7s4A-0001g3-By for emacs-devel@gnu.org; Mon, 04 Nov 2024 03:04:04 -0500 Original-Received: from [192.168.68.102] (111.red-88-21-7.staticip.rima-tde.net [88.21.7.111]) by zealous-pike.82-223-54-191.plesk.page (Postfix) with ESMTPSA id 20C488012F; Mon, 4 Nov 2024 08:04:00 +0000 (UTC) Authentication-Results: zealous-pike.82-223-54-191.plesk.page; spf=pass (sender IP is 88.21.7.111) smtp.mailfrom=cpardo@imayhem.com smtp.helo=[192.168.68.102] Received-SPF: pass (zealous-pike.82-223-54-191.plesk.page: connection is authenticated) Content-Language: es-ES In-Reply-To: Received-SPF: pass client-ip=82.223.54.191; envelope-from=cpardo@imayhem.com; helo=zealous-pike.82-223-54-191.plesk.page X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:325081 Archived-At: On 04/11/2024 1:21, Po Lu wrote: > Thank you. A number of comments: this is simply unacceptable, as Emacs > must not depend on XKB for such a basic feature. Ok. > ??? Code producing such events should not relay modifier keysyms > verbatim, but ought to detect the virtual modifiers to which they are > mapped, and convert them into Emacs modifiers, namely, meta, alt, ctrl, > hyper, super, and shift. Otherwise, Lisp will find it impossible > reliably to establish a correspondence between "physical key events" and > modifiers. This is about keys, not modifiers. For the use case of binding commands to keys, this remapping would be counterproductive. I can provide a function to make that conversion if needed. > Please find some means of generating such events by saving them into the > keyboard event buffer defined in handle_ome_xevent. Ok. > x_filter_events is not the proper location for this call. It is only > invoked to filter an event through the active GTK or X input method > context, and it is not invoked if Emacs is configured not to open input > method contexts, or they are unavailable by happenstance. > > This call is properly placed in handle_one_xevent, beneath the labels > for KeyPress, KeyRelease, XI_KeyPress, XI_KeyRelease, and the GTK > keyboard callbacks in gtkutil.c. Pay attention to the different manners > in which the key codes are converted into keysyms and the keysyms into > modifiers, and imitate them closely or reuse them if possible. > > Lastly, you must decide whether to capture modifier key events before > they are filtered by the input method, or after. Input methods have > complete discretion over disposing of these events and will either > discard them entirely or resend a possibly modified event to Emacs. In > the latter scenario, you will receive duplicates of one and the same > event, and in principle it is impossible to distinguish between the > duplicates and the originals. Equally unsatisfactory is the option of > generating these events after they are filtered by the input method, > since none will be generated if the IM takes the other course. > > These are the same concerns that led me not to implement raw modifier > key events when this feature was proposed some years ago. Then probably this should only support X11+gtk and pgtk. Do those look ok? Is it acceptable to have support for nonfree systems in this case? Thanks for your review.