From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Disabling mouse input Date: Sat, 02 Nov 2024 14:11:58 -0400 Message-ID: References: <86sesaytjn.fsf@gnu.org> <4p6cs2adzzqihjdustvlklr3ykrrz7eq7rtz2ciywcyevgmoej@klyfgnsjtnti> <86h68py3zy.fsf@gnu.org> <86fro9y3ki.fsf@gnu.org> <86bjyxy1nh.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="40555"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: dradetsky@gmail.com, luangruo@yahoo.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 02 19:12:51 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 1t7IcC-000AJY-Bt for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Nov 2024 19:12:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t7Ibb-00037n-Ka; Sat, 02 Nov 2024 14:12:11 -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 1t7IbZ-00037U-4O for emacs-devel@gnu.org; Sat, 02 Nov 2024 14:12:09 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t7IbV-0003bb-B0; Sat, 02 Nov 2024 14:12:08 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A389180821; Sat, 2 Nov 2024 14:12:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1730571119; bh=0lI4vvFhi4Qig+2P80Axp5OubA/sJ77Oc/Ac61yQT6k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=E8g80zcfA/PMbre5Hof/gtneu/peTc1t2iXxrpaVtpty1nrVu1xjjyB3dbRiMURdE lYeDSqvTn/Sxx2FqGlbqqYBCnG9PUaxHOxEKTlJBRx6awVJyzTy6h0oW5wkUnLx5Mq MchxMNcFJkLI9bd7jd7Hw/eoYoZudnV5r4/ovmqVmvikOdXrCy+IPRPWgBbkmZJszj nxRzlxlls1MucEkZeFqR0An0EZ6E5jPUu+hT+6udNhQ77QytHltqK12WtRDvsUtwE9 JyRs1gNzgk6Hn3NaSeY88MdrysYl3p3WroQlB2BjUCgLsYFUMtc9B12NPJrlhaGp4V C/J0lIq+yMJ9w== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E78ED802DA; Sat, 2 Nov 2024 14:11:59 -0400 (EDT) Original-Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B2A12120497; Sat, 2 Nov 2024 14:11:59 -0400 (EDT) In-Reply-To: <86bjyxy1nh.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 02 Nov 2024 19:40:50 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:325025 Archived-At: >> IIUC the problematic events tend to occur "in the middle of other >> events", because they are generated as a side effect of the hand >> movement that causes the other events, so I suspect the effect on >> `while-no-input` is not particularly important. > I'm not sure I would be happy relying on that, or in general that such > events will be seen in the queue, Maybe. AFAICT the fundamental problem is a hardware problem (where the touchpad sometimes registers events which were not intended) and disabling all mouse events in Emacs is just one of the workarounds the OP considered taking. While I'm sure other people are faced with the same problem, I can't see any evidence that it's a very common wish, so I'd rather not make the C input code even more hairy than it already is by adding ad-hoc code for that if there's a way to get 99% of the result with a Lisp-only solution. OTOH, if we can come up with changes to the C code which cover this need while being generally useful, then I'm all for it. > but there's AFAIU a larger problem with this method: it requires users > to add a lot of events to the list of events "disabled" via this > method. It is also not very future-proof, I think. E.g., what about > drag-N, drag-n-drop, etc.? My understanding was that the OP wanted > a way of disabling mouse events without the need to go though all the > possible symbols Emacs uses for them. Indeed, and this is a much wider problem. E.g. for many years I had exactly such a nasty list of bindings to remap all the variations of `mouse-4/5` events to `wheel-up/down`. Changes to Emacs that make it possible to have bindings for "patterns" of events (rather than specific events) would be great. With luck it could also make the `read_key_sequence` code simpler by moving some of the ad-hoc code we have in there (e.g. to "demote" S- to , to drop `drag` modifiers, etc...) into mere entries in `function-key-map`.