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 19:15:08 +0800 Message-ID: <877d7xb35v.fsf@yahoo.com> References: <164933858147.29834.15050766441005536059@vcs2.savannah.gnu.org> <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> <875ynhe6mx.fsf@yahoo.com> <83r165735n.fsf@gnu.org> <8735ilcof3.fsf@yahoo.com> <83lewd70wz.fsf@gnu.org> <87sfqlb88e.fsf@yahoo.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="9891"; 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 13:16:12 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 1ndVYB-0002Sl-Rs for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 13:16:11 +0200 Original-Received: from localhost ([::1]:59280 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ndVYA-0004yi-OH for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Apr 2022 07:16:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48666) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ndVXO-0004Ii-14 for emacs-devel@gnu.org; Sun, 10 Apr 2022 07:15:22 -0400 Original-Received: from sonic303-21.consmr.mail.ne1.yahoo.com ([66.163.188.147]:42657) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ndVXL-0005YQ-Hm for emacs-devel@gnu.org; Sun, 10 Apr 2022 07:15:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649589317; bh=mjEO7TVRXFuDi3vMjeuwCGnXBLzX1oAhV4AwkPrB8Uk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=QlZojiyGTrWGqC5E9YCGeFTq5/Y+PdzBB9C56x+Btl/yh6Ih25W3KrP53zYGrklyZJQC3aCOS/0j7FttBYtx4NwOKwnnDCJ68+rpFxBMd7EjkMRU7NqoJ4TNSOJXWBbCyv9uqpwNY8g+o/+Xg5BgMejc4tSY9UguJ/WIBYRmQIJic+gJXxFs/HVgW6bP7sHwzv3KgImeALTb0dkPjvjEhk7aw7iaNbQjFhd1EHFoOEQk5uTFyxzuNY5WA0XfxrM8N4Tat8c8sn/Iig0Vn8tfh1x1YiIFDu8iEwtzwoRrLqd46qkP04a0SFXjK8slAYLiNdW43Bz2iBTCiJywgp1QEg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649589317; bh=+I4ovSOULMgq/y3++clxNLpsUxE6QgVIg9+rjW0bYj9=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=Tw9Ec6X+5DyuNSEOnqq8wy8EHB+QawNzJFGTYxuP6sYKmmeOr2uYxA1+o6HtUmA1bYzTfca2zisd7CWfT4v5p43VDG1AtaYsMABlW43VIDrwNR7fJE1GsJ/PmbtHp8691EyogPi/WUnOXGMUAzahPd0wXSS7DDUYE7f4FI6mRvUkWd6HdJ6B3a1NnYHpTzpACNWLw6YmyIDLRIrClVEdfLA9cuTNJwFL7MELnSEkkRa7EgIyNHGx7iGnosU8Xh7koKZuzKtzUQ4AT3gz2ZwWqiycl1U6atM7Wc5BI+iPFL61WfTc1vDpUNQi2iaYGLr6wuvE9RjJ7dOPez+f/TDmxQ== X-YMail-OSG: Qj8Zj.oVM1nASu0kQpw7h56WZ4d6iOAzo1xp72tKC4O.XmSX_2wHlMEHLwWZThy rT1LA5rmRazQ9cWhWknuW6k3mSxbCG3SxOtiCy2YJ1d.ZSZ.5FZO5CIpTjCQ.wMaKEMGVs1G0q7A CdWy5I6I6ZDWfN2qkzQrXAFgtA4oMbRPu7HxeIfN0KqZadT4qsdz872V54n0ZcqgIZf5Rp5jPH7r 8PtvYycr.DT2hh4pP4aGl1FPf47.mAWg6lrEGb9uUefMq0UUwBJsNHKQ_judaWvokQ2ccPIPKeAy dpGByHbjFM.hGM83BzAg6z7GBoSVylLZx5JS8JeF5YCLClSxXMxeleyXqyc7W3C73m7sU7yN.XSq jrndPbvjI2bWQYTzkuAU7FVcUJBxL4R9BGEzRiEdy9rMpoZ_zw6ENeE_FK1DP19.mvETm2P8Sp7t QsMSeaCyeKiuTtmua4L8gfUskdhMqvVgL8if8iILkElxs1folBTCPFEQSLd1NK30t1AAM_WrUWzJ VSWUHSmfLXWOK_bnfyZQIkSqsqlFnI1.wzFMg3zDh8Fi0ge5FlBVbzD_5RWTFizV5QQv6M7UueYT .1KhTG2MbbVy6vFPWAQWkh_NP3bDAV4onWtpUXK2N7e8H0WCssoYxQPBcsSaAbdVb9CnBoP8Uf7T nIdTAn5MNryJGZhqTa.h4oH4iJeS8eyFZN6nJvoq2muOJ6AggEhR16CrZ8Pa7zP51ZphnRrcCYIt 0bcruE4C496ApwDMiekk0dDV0vMN3iE2ctpMLpFZpvzzbBoaK18CCaJluR27p1Qs1g0NhPjfiLND WeRi_audOSTrGjNJYiTnDyRNmsC6NTedQhEL_A1hmd X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Sun, 10 Apr 2022 11:15:17 +0000 Original-Received: by hermes--canary-production-sg3-65d7bd97b5-gqv44 (VZM Hermes SMTP Server) with ESMTPA ID 6d689fbc83f87db9e979fb64bc4aaacf; Sun, 10 Apr 2022 11:15:13 +0000 (UTC) In-Reply-To: <87sfqlb88e.fsf@yahoo.com> (Po Lu's message of "Sun, 10 Apr 2022 17:25:37 +0800") 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.188.147; envelope-from=luangruo@yahoo.com; helo=sonic303-21.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:288126 Archived-At: Po Lu writes: > Eli Zaretskii writes: > >> The low-level code which generates Lispy events can, of course, use >> some Lisp data structures, including user-defined data structures. > > [...] > >> Yes, but what does the "class" part in "class mouse" signify? Why not >> just "mouse"? > > Sure, that would work too. I will start working on the feature along > those lines. > > Thanks. I found out that only having an alist-of-items doesn't really work. For example, there is no sensible behavior if two packages bind different function keys to the same device or device class. So the new design I've been toying with involves two functions, `register-device-function-key' and `delete-device-function-key'. `register-device-function-key' takes a device or device class, and a recommended function key. If no function key was previously registered for that device, it associates the function key with the device. Otherwise, it returns the function key that was previously registered. Either way, it increments the reference counter of that device or device class. `delete-device-function-key' the device or device class, subtracts from its reference counter. If there are no references left, it deletes the function key from the alist. The benefit is that multiple pieces of code can reliably bind to the same device or class, but binding then becomes weird. I have to call this when pixel-scroll-precision is being activated. (define-key pixel-scroll-precision-mode-map (vector (register-device-function-key 'mouse 'coarse-mouse) 'wheel-down) #'pixel-scroll-precision-interpolate) And when the minor mode is deactivated, I have to call (delete-device-function-key 'mouse) then remove the previous binding from pixel-scroll-precision-mode-map. What do you think? Is that a reasonable design?