From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Physical keyboard events Date: Mon, 04 Nov 2024 17:35:52 +0800 Message-ID: <871pzrl4sn.fsf@yahoo.com> References: <31bdc55d-8c13-4de0-9cef-bd6cc4fb033f@imayhem.com> <19ab52d0-88bd-4378-8fa8-8603e01233e3@imayhem.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23483"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Cecilio Pardo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 04 10:37:07 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 1t7tWD-0005u2-Mo for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Nov 2024 10:37:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t7tVP-0001YC-S5; Mon, 04 Nov 2024 04:36:17 -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 1t7tVH-0001Xx-Be for emacs-devel@gnu.org; Mon, 04 Nov 2024 04:36:08 -0500 Original-Received: from sonic301-31.consmr.mail.ne1.yahoo.com ([66.163.184.200]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t7tVD-0007lg-2S for emacs-devel@gnu.org; Mon, 04 Nov 2024 04:36:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1730712959; bh=oExjH5SD5dwg3Mp2Ke3xGp5NuRNYK1IgeTwzGQIeZe4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=rX0X0jn5RVluihv/oiBoNFFxhvL0VE5EQRaIJJ5AJryPEfssNg+ZRhezPq1FvD0J3k1NOisxKTsxwVxlOp94X3gaYqXUeykWlVY5lfjr9hhJ5B3Y1JAXiyhisvxDEH06zX/n5SKI8eBUKCaxByXGRK4xg0AXCpIoohE1B9R5bTHD+zHOFUXR9v7JuINL1/trkvvHX8rti89ZcmLd8AoJ0C4lb5bFhu0XBPScfPU5tO2rRNRM+i9s3thyIhqoGOQmeJ2jR2m0sQY5JmJj4E8ctOKRf52ScmoLP8eyIwAeLTbkOZKpqM2ybwSeTDiwrjK4xMZcOJSIgqat/tls8d7aZQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1730712959; bh=FwGCijD7tsm1XeyW7J48StOJIsi+vADAuN+qIq84zVp=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=ZXHIBdy401U9lKTiIvsXRIqAodjF735sMNqY43A5/ganV9J9Tas21FZ8zaLfe1B18Bsop3+sm18eHncBO950JBjvLe/ImzFa5vBWIudDbWj1TDyWqqPVBqODlBWEADXiysOkYDvDu6qRM985b+guGs2V2ds9yUI+AZbkuKEivGHTZLpVv7T7GVJkfmTpNVIF2pfOLHbt8ODjNsSa3Rg/qi5mWjRZ6MQGQdrVow2yi4qOjhJhWjH2h4/114PGG/wnuWlOGivbsBNTuQVMV7aL5u0obHNr0ehQX2vsxyJ34VrslCzRiFaSEagK+y/5BfLIcSb9+EVRK3RMnMmz+AtdOA== X-YMail-OSG: Mz4xFrYVM1mPa75DHxg3x1nm5XM325GPB4QeJqTEfkRkU.X8CGfhChivEMZA.zS 6CEKx0nlLeNoZ8EgZn3v5J1.KH3T3g00NhcvN5.vwkGVnuVvySdcL0i9mSUifHq9fB63oJCTQWcl qadJQySjnYCOB74FndGJIUOeXhA1TgKTd_EuRqVBojPYtVzPI8FyL0i_b_dnePLRfCXA.pGycDG. 6nCR1sWOsujX4cC_riefUb2x9DjE6XWgAl4Yvgx3lkt6Tp_Yrq4cklAF1rL77kN44JAO97ytk9Yw JnJyfGn4eSk.PPrCLZ_7q8vIQ62Jrsbo.qygNNg6J3xF.Sfz8mm9frUGlOveJY4ngo2Jo3rvloIS Vhk0fcxZ858ZIpKOoA8vD5B3k6vVXSyhMaN6vOkgckmKDUJXyfBbQiZWfc9aSe53DfOJR1hsJraC iggfeqA9I6gCiPgk_o68bkCiNujGqyzM0F7dscaOSfccBhRQjpV3W34VXYWW9FM452nsqWaGtdn. SY0oVHBvM_Gbxl89zJ8WaXYQHBT6MwKc0xT.5pEK.5N1J_5XIPpRyYrPoUJ.PCs1V7achlqRyJTk RvehBSq7Cdbtqh8z67lP7ZKIaeCfA3QWnHug4DfNIwSH.z6fIf1tkRHYlmRtGKwquH3zqO3YBXZi Xh9qP_BK3NkMB37eLW9GwgdAcX_EoEFdOL56vUa5QMLoiWRaHUUp6hv0CC3ObWElDbtZA7Xa147q bmPWt29Fa91T5CNYNQWzzv5NK_lmLIriPH_DdkOeRcmSDjarwBM0dSckk5sTnpM.arWJwQe00g6p QaYuaXkfRMKA0Y8EAajSSq8PcXp4VVHoAs75ImIqKA X-Sonic-MF: X-Sonic-ID: bde5e04a-604d-4d54-ba93-6d3b831ebce7 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Mon, 4 Nov 2024 09:35:59 +0000 Original-Received: by hermes--production-sg3-5b7954b588-2czcw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ae9abd199bf67dbcf3fc4cb6c649e847; Mon, 04 Nov 2024 09:35:56 +0000 (UTC) In-Reply-To: <19ab52d0-88bd-4378-8fa8-8603e01233e3@imayhem.com> (Cecilio Pardo's message of "Mon, 4 Nov 2024 09:03:58 +0100") X-Mailer: WebService/1.1.22806 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.184.200; envelope-from=luangruo@yahoo.com; helo=sonic301-31.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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:325084 Archived-At: Cecilio Pardo writes: > 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. I must disagree. When Emacs has enough information to decide which modifiers are produced by physical keys it receives, as it does here, it should not confuse Lisp programmers with a view of the keyboard state that runs contrary to their expectations, not to mention that the disparity between X keysyms and X modifiers is very great, and users who swap the positions of the Shift and Ctrl modifiers will not expect to receive raw keyboard events which disregard their keyboard configuration. BTW, if the intention is to forward just modifier key events to Lisp, don't let's refer to them as "physical keyboard events", but in more specific terms. >> 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? It's not acceptable only to support X11+GTK and PGTK, whether or not non-free systems are also supported, because there are numerous severe deficiencies with those configurations, and with them we are at the mercy of an upstream that is uncooperative at best. And above all, what I said applies just as well to the GTK configurations.