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: master 3b41141708: Expose the name of an event's input device to Lisp Date: Sun, 10 Apr 2022 15:31:50 +0800 Message-ID: <875ynhe6mx.fsf@yahoo.com> References: <164933858147.29834.15050766441005536059@vcs2.savannah.gnu.org> <87fsmow1hz.fsf@yahoo.com> <83a6cway59.fsf@gnu.org> <87tub4uivu.fsf@yahoo.com> <83y20fakwn.fsf@gnu.org> <87o81bu7zj.fsf@yahoo.com> <83v8vjai4s.fsf@gnu.org> <87bkxbsqfl.fsf@yahoo.com> <835yniah0u.fsf@gnu.org> <8735impqw4.fsf@yahoo.com> <83v8vi8uyu.fsf@gnu.org> <871qy6o9p3.fsf@yahoo.com> <83o81a8qnd.fsf@gnu.org> <87zgkulbuu.fsf@yahoo.com> <83ilri8iag.fsf@gnu.org> <87k0by43an.fsf@gnus.org> <87bkx9lqno.fsf@yahoo.com> <8335il8p4c.fsf@gnu.org> <874k31h3kz.fsf@yahoo.com> <83y20d7808.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23868"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: larsi@gnus.org, monnier@iro.umontreal.ca, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 10 09:33:54 2022 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 1ndS53-000666-Vi for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 09:33:54 +0200 Original-Received: from localhost ([::1]:43204 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ndS52-0005P8-I5 for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 03:33:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50964) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndS3V-0004gb-Gr for emacs-devel@gnu.org; Sun, 10 Apr 2022 03:32:17 -0400 Original-Received: from sonic312-25.consmr.mail.ne1.yahoo.com ([66.163.191.206]:37082) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ndS3T-00076t-FC for emacs-devel@gnu.org; Sun, 10 Apr 2022 03:32:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649575921; bh=CvqjzY5wfndAt6ulrTLN1LINi0vk3hkTpeoPdmpX4aQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=FN+ULKZXQBzyJkTq34fG/VpCs3ebgeA6lSJXvnBfks2J2t8RfVRGjSsgvnZcUzKFD/iY4TWx8DZ9jDQMRDR/Hj8WwF+mQkwJZimAgDj+zb42JFtZrITZqmcpfH8naXGK04QhTd94utglXSdN+F6poBkwacbq/JG1qG7TXxMAmGrF8lA20vbYN2sxXaSeRUlcLjHPEblhQJ9v+Qym6HkhN2M5xKeHguq6DC16RWTW07mCa3IcYr/iWdf/66aoluF4TtZeRRHJco+H/319s+W2UDNJo7XYBo2ONruQG7NbFSowgzg37Kurcozv4xLk4xv9Xs3/rgAbmsUrcFsKNwph1Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649575921; bh=be1GGNDjTjjekq++k06lb2mBp+OZGVVM/nV9L/f6T16=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=rJnxCJfCg8sluFTsh4TpcD7YkVnUaW0gF9QbKbu58iLbsaMFrG1OP2gSYgoc34uzWT2yI1RRI1aj6AUeMwPYH6thJdmf12XOvFFSMfSraiq0fehO/7fXrowqUHN4B5FBBUVwLUppcZ66R2bKnXglYc2UqKXQkzJbMZu4lYkqSocaub+NO83ilcl9covqtAkBdq8e8mz59ub9ojtMmc4gAa1gAQ/W/9u9pRQgfi9alLQp/oT1clXbknQwfkI22CJSNtjs4ash1XS1q8OQ3hQ7eIA1LiWs+yqb3O6HP6c06JUg952TyT9IEjRR1G3ut9edtqOXfADW9lv/1u0so7889g== X-YMail-OSG: i3rZYv0VM1nAwXoWA36JIZtRw.8jWf.v_dp_TO.ony64zDR9GWNn.dKra_OsXvi 3dQSL8yMG3ebVdULaUmpNXYm0pNiayhBkdiBwBAgu1qbg_3wU6tZMUoEWuDS592Qrs_R2vTQi5uY HQHSTbFi_PYVYX_iGTWpCr2jOfadYPbiV0R10Yg1.UsyaXq7w_gRXy2u9D5S.Zt0inLv3H3xJSNw TAhjcKYKIhncReExjw_6q6qCRiG_i.pIkZmTZwcO_6FQtzbyADiTuIIFoyXkfUQBEvBr6IVteO9Y j.1MI65mluLaplp9GvhKjL8iTlGZMS4F4E3_7l3Aku0zDU2bpHAbeLQBPOyRJ6LyGcsKTsOBTpWa s2k20eZkQwJQ9noAnUkRGrSAkfxNUtqim0v4sspo4PEIDm5mx.6leYOBWZL8SlAGDhYqZs0GqY26 cS2wYHup.oKOrUScD6AsnAWWFrEBNTZuxw4iPs4Vlrg5XQuQarQIILi1HTeCS3fzmQcezpXzDl6H iPTImxNdggdLAhRFxp0X_MVoHMOnkSpRvHN.pbodNexcA_gFfp1.8M3r6ru6tis87.MNau2vzD0q YE4Lv5yjE9ezLwISfzwW6.j77OVtZkkWzkM0mFeRo_Z3VfXMxvbtNvAZjHQsB.2gjn9qFFwVKLSk BsLufSz9tQnRprMcRkIIQR.IuvNiDV.DUfMOG2OjLY14UvqnWqPx8ecTTUQP2mRsuoOoGmfWz4u6 Y0T.q2YIkyhB57kGEKQ3EF_yvcPRFrvxouE48DZToQSiSv6DWp9nhrZYjBUyMlgKb.V.abRw5czI mcZnqz_ssxYrgViEAD3NKI66jjHW7rvW0nqgHiUUmz X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Sun, 10 Apr 2022 07:32:01 +0000 Original-Received: by hermes--canary-production-sg3-65d7bd97b5-p7hgv (VZM Hermes SMTP Server) with ESMTPA ID 6d47cabc0e85979662649d993487c693; Sun, 10 Apr 2022 07:31:54 +0000 (UTC) In-Reply-To: <83y20d7808.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 10 Apr 2022 09:44:07 +0300") X-Mailer: WebService/1.1.20048 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.191.206; envelope-from=luangruo@yahoo.com; helo=sonic312-25.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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" Xref: news.gmane.io gmane.emacs.devel:288110 Archived-At: Eli Zaretskii writes: > Who is "we" in this context? What level of Emacs input processing > does this "we" allude to? The input processing at the C level: everything between and including handle_one_xevent to make_lispy_event. > My point is that the level on which devices could be important is > below the code which inserts the events into the main Emacs event > queue from which we read events as part of our main loop. If we agree > on that, we can stop arguing about making Emacs aware of the device > types, because the only aspect that worries me in your design is that > the device type should be exposed to, known by, and actively acted > upon on much higher levels, like the commands bound to respective > input events. That is something we should IMO try hard to avoid. [...] > I don't yet understand why we _should_ know or care about that. If a > device pretends to be a keyboard, but emits events that "normal" > keyboards cannot, we can still process such a device by pretending > those additional events are some special function keys. Like we do > with several window-system messages already, and even with SIGUSR2 > signal. Is anything wrong with doing the same for those devices you > are talking about? If so, what exactly is wrong and why? Once again, > please reply by presenting specific use cases where this paradigm > cannot work well. They emit the same events that "normal" keyboards do. The foot pedal for example will insert "b" just the same as a "normal" keyboard will. If you open a text editor window and press the foot pedal, the letter "b" is inserted. If you turn on "xinput test-xi2" and press the foot pedal, you will probably get something like this: EVENT type 3 (KeyRelease) device: 3 (10) <----- this is the device ID of the foot pedal detail: 56 <--------- this is the keycode corresponding to the keysym "b" flags: root: 996.00/568.00 event: 136.00/94.00 buttons: modifiers: locked 0 latched 0 base 0 effective: 0 group: locked 0 latched 0 base 0 effective: 0 valuators: windows: root 0x79a event 0x4c00001 child 0x0 And if you press "b" on your keyboard, you get the same thing: EVENT type 3 (KeyRelease) device: 3 (4) <------ this is the device ID of the "normal" keyboard detail: 56 <--------- this is the keycode corresponding to the keysym "b" flags: root: 996.00/568.00 event: 136.00/94.00 buttons: modifiers: locked 0 latched 0 base 0 effective: 0 group: locked 0 latched 0 base 0 effective: 0 valuators: windows: root 0x79a event 0x4c00001 child 0x0 Since device IDs are not in any particular order or guaranteed to always be the same for each device, we use the name of the device to identify devices instead. The relationship is similar to that of file descriptors and file names. But presumably the program for which the foot pedal was designed for presents the user with a dropdown from which the device that is actually the foot pedal is chosen. That way, if an input with the character "b" is registered and comes from the foot pedal, it treats that as a press of the pedal. Otherwise, it treats it as the user pressing the character "b" on the keyboard. I hope this explanation makes things clearer. Thanks.