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 14:17:46 +0800 Message-ID: <87sfqlfomt.fsf@yahoo.com> References: <164933858147.29834.15050766441005536059@vcs2.savannah.gnu.org> <87ee28xyg2.fsf@yahoo.com> <83ee28az95.fsf@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> <87tub1kbkf.fsf@yahoo.com> <831qy58ofh.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="12821"; 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, emacs-devel@gnu.org, rms@gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 10 08:19:34 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 1ndQv8-00039g-9K for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 08:19:34 +0200 Original-Received: from localhost ([::1]:42356 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ndQv6-0007JN-60 for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 02:19:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43780) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndQtc-0005FR-GG for emacs-devel@gnu.org; Sun, 10 Apr 2022 02:18:01 -0400 Original-Received: from sonic307-56.consmr.mail.ne1.yahoo.com ([66.163.190.31]:41820) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ndQtZ-0005jD-Fc for emacs-devel@gnu.org; Sun, 10 Apr 2022 02:18:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649571475; bh=lWCQIqpDSJdVvxKbw28HaDm8Shx2JOEz7au8tWlridA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=qcxrn+rLHgVolLYmSbqErdAFQsoi2cGe3viuCwL+0rhsuhaBtp2mq+5yu9FKKiXoCLWBA92fHcdiIwPvOdGF8316w7CIR0HtzBCuYQWYlBjJkjgvC+ks2gk4ydTW+R8qNxJe14b/w9hC0tFDQdfjbNBBHSR+SKaQt3erGuV4jZVNCeFzcY9ghRc1SyFtGlbY/55lnoxP/SiQ5cTnHZtVDh5KUVcbuYuPljKpb6OgmpMnLA2stUKfHUC+DIMEybc1bAd7+KMLEqFz3A8jykKCFaS5PXXyV0ymNG4wb4ZhHirW0ZXTRxMrymEI18x+VrmoB5cytxgHzRJoKDx50a+pww== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649571475; bh=6khT8HfpKT1Fmfsen2vS7KFO99XzDzMbsV6vxL7w46N=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=Dq4izHGyYKnS59I+Dfm30KNwH49ZZyCoWMomGovzGoe4Z8RuxrEmuXMpnd9zxvaxzAwp6oArFcr8iGUDjXs/jptYs4QmfbC2Q/1IYQMyj0o+ltkWtVTZ1kAZseZtwCcmp7pMJNcr0vTTPNZLhua5/LEZoD+K/G7DwKv0fDOkLLQwzd8YJluzWAeOLodI3jqZFUhm56SabA8ia3F9Pid1bnUc8PShx+B7/7ReHjURVD36f1R1U7AJ2Y3kVD2b9NYC1gt+bc62Duq6Y66u1tjDbbUzvyb2E7tUjDY2I0F/eFzI+aE5veivt5/8h2Z6sTBi4iQ6p7tmxe7or0f6y6hEXw== X-YMail-OSG: CBTp2IgVM1mBXShDhRwNt5oUhC0vfNpXJTRdfMLo9kLV9BS_hS3Zvu297a0mDSa oE1w3.woPLbKi.dwh60mdVkqyE7Jh6asVNukiTiV7Ft9sQ9xu.gFv3NIprB_.SQluTIN0Jf82vb. 7b2jTbw1jPoDK_iCbI32F4nxedx64j5tES7xAKdceqE6wb0H8owCVsL_XIwMFMJaOHXusXOwPWh8 XGlKK4zmLX7Px2L.rJTRo81C6h4fJ7tQlkanCsFlz3Sb53tZOB7RKnSEElERUKnhLhelGm1QfPu. _DfUqtqiqzlYnnkHavKMpiJAcco8fbejCMdS5.zoV_23GFNzi0SrXhd6MA9VHm5ECVHDy2IzzxbJ NaltXOTT5Rs.lLFSxdoTAmmNbF7bzNviQ0QT3i0e3m5BWFjjDegY7w53uBGItRFzTDxkogSKGq7O .SreQxwBy8ofgSclfsZ0jQo4TGxaidhin_e4CorhqAz34hfEb8lDJkC2XOrkc28tPDqNrnkRjtnX AVserHjhg97yyAxZoIwAifcR5z42qJPfr8A9u_.qz9a7q38DA51xF9kDkVwKs7GYyIh.9VtNLbne OxTsgLxS.1KupgINCxp5fQHWHxWoQY.Li4FigPU842x_etJefV.Qi2c.jx6XZ29MLjDxywzAocUt BhUFr_boY8vzmjI2UZpngL4FnhhdOs3sRo8iKvgDxtX0bGSYBMaV._HD2g4SqTgugtpci2_ASm89 jxwztL1lPYwG23yk4VIzJCrpk7bOV97v4uCR61dht5.HCy42f_X5FgM.6of5bafmGnQjJuTum8ZP u2DGM8DmcFdwkwRRsWU3kD1Aud_fL9kpuGyc.xCc_C X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Sun, 10 Apr 2022 06:17:55 +0000 Original-Received: by hermes--canary-production-sg3-65d7bd97b5-gqv44 (VZM Hermes SMTP Server) with ESMTPA ID 2bead06427cfa42f5867615981e663ec; Sun, 10 Apr 2022 06:17:51 +0000 (UTC) In-Reply-To: <831qy58ofh.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 10 Apr 2022 09:04:02 +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.190.31; envelope-from=luangruo@yahoo.com; helo=sonic307-56.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=unavailable 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:288098 Archived-At: Eli Zaretskii writes: > Then the events emitted by those buttons which are not part of the > device will not be emitted. > > Or maybe I misunderstand what you have in mind when you say "the > buttons we want to change are not part of the device". I wanted to say that the buttons belong to different instances of the same kind of device (ordinary computer mice). > If these events are different, they should have different symbols, > yes. How is this different from, say, mouse-6, which only appears > when you have a mouse with 6 or more buttons, although commands can be > bound to mouse-6 even if such a mouse isn't available? These events are the same aside from the device that generated them, the only difference is that we want the same event to be treated differently based on such a fact. > We've been through this: the second mouse should have its buttons > numbered starting from some number N to distinguish it from the first. > For example, N could be 11, so the buttons are mouse-11, mouse-12, > etc. How do you decide which mouse is the "second mouse"? > Display capabilities are tested as preconditions for producing some > fancy effect on display, not for dispatch on input events. If we > don't test the display for some capability, trying to produce the > related display effect is likely to signal an error, which is not > useful. > > Besides, even if the display-capability analogy is actually an > argument against your design: we test generic capabilities, not the > names of the display terminal on which Emacs shows its frames. Hmm, then I suppose a better anology would be `overriding-terminal-local-map'. If I connect the second mouse to a different X display, I can make input from that mouse behave differently by changing the keymap for the terminal associated with that other display. Why shouldn't I be able to do that with the second mouse when it is connected to the same X display as the first mouse? Thanks. > That is a separate issue, not the one I was talking about. If there > needs to be some Lisp executed, once, when the (second) keyboard is > attached to Emacs, or when we switch to another type of keyboard, and > if that cannot be done automatically (e.g., by Emacs listening to some > special system event or polling some port), then so be it. But from > that point onwards, the key input on the Lisp level doesn't need to > know about the keyboard devices, perhaps not even that there's more > than one keyboard. I will give this some more thought.