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: Tue, 29 Oct 2024 18:52:41 +0100 Message-ID: <335ee6ff-da79-48ef-8ccf-13fb20cb00d9@imayhem.com> References: <86r07z58or.fsf@gnu.org> <86froe6eq3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4424"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 29 18:53:23 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 1t5qPC-00013h-RH for ged-emacs-devel@m.gmane-mx.org; Tue, 29 Oct 2024 18:53:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t5qOn-0002pK-8x; Tue, 29 Oct 2024 13:52:57 -0400 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 1t5qOk-0002p7-Ur for emacs-devel@gnu.org; Tue, 29 Oct 2024 13:52:54 -0400 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 1t5qOc-0001nt-4g; Tue, 29 Oct 2024 13:52:53 -0400 Original-Received: from [192.168.68.104] (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 A70148012E; Tue, 29 Oct 2024 17:52:43 +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.104] Received-SPF: pass (zealous-pike.82-223-54-191.plesk.page: connection is authenticated) Content-Language: es-ES In-Reply-To: <86froe6eq3.fsf@gnu.org> 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:324928 Archived-At: On 29/10/2024 17:44, Eli Zaretskii wrote: >> Thats why the events will be bound in special-event-map. Nobody will see >> them, except for the code that handles them. We can of course >> completely disable them with a variable. > > Even if no one sees them, bombarding the Emacs event queue with > useless events will have its effect: Emacs will become more sluggish, > some while-no-input loops will unexpectedly exit just because the user > happened to touch the Shift key for some reason, etc. This should then be always disabled by default, and explain the price to pay to those who want it. I find it acceptable. >>> Physical keys also raise the issue of supporting input methods, >>> keyboard layout switches, etc. >> >> I will define a list of keys: LeftShit, RightShift, LeftControl, etc. >> The platform dependent code will decide which one was pressed. As events >> will be invisible, I don't think we will interfere with input methods. > > I meant the non-modifier keys. When some OS feature redefines a key, > low-level events will not know that, and will still consider the key > labeled 'a' as 'a', even though I might have switched the keyboard to > another language, where the key labeled 'a' actually produces a > completely different character, say, 'ש'. The use cases I have in mind are with modifiers. If others appear, it should be clear to the user that she need to bind the key by what the OS sends when she presses it. >>> However, on what systems and which Emacs configurations will it be >>> possible to provide such a feature? >> >> I think all GUI systems can use this. > > So X (with or without any toolkit we support), PGTK, MS-Windows, and > macOS -- all those let applications access low-level key events? I would not call it low level. On Windows, it would WM_KEYDOWN and VM_KEYUP. And we would use the 'virtual key', not the scan code.