Disabling mouse input

Disabling mouse input

[Daniel Radetsky]

[-- Attachment #1: Type: text/plain, Size: 1917 bytes --]

I want to disable mouse input to emacs. One reason is that,
while typing something on my laptop, I may accidentally hit
the touchpad, whereupon emacs will complain that
"C-c C-x <mouse-wheel-down> is not a real keybind" (whereas
I had actually intended to enter C-c C-x j or something).
This is annoying, and none of the common solutions to this
problem (e.g. palm detection) seem good enough. Since I
don't want to use the mouse with emacs to begin with, I'd
rather just disable it altogether.

Unfortunately, there doesn't seem to be a way to do that.
You can of course unbind the mouse inputs, but they will
still be generated and lead to spurious errors as above.
It's also not possible to solve this with advice since the
calls to functions which generate the mouse inputs occur in
C code. As far as I can tell, the only solution is hacking
core emacs.

Attached is a draft patch. I imagine I'll have to add
more/better docs and other checklist items, but what I have
here will allow others to see what I've done and tell me if
I'm doing it the Right Way or the Stupid Way.

Basically, we define a lisp var in C `ignore-mouse-input`.
If you setq it to t in emacs, you stop receiving mouse
inputs. If you setq it back to nil, you get them again. It
works for me, but unfortunately I have no idea how to write
ert tests. Maybe somebody could point me to a few of the
simple ones to study in order to get the idea.

Also, the C code does look a bit funny, but I couldn't
figure out any automated way to check/fix it, and I'm not
actually familiar with that C style. flycheck said it looked
fine. I tried running clang-format, but it said there were
already 3000 lines worth of errors in that file before I'd
even touched it, so that's obviously out-of-date. I didn't
see anything about this in the contrib guide. In any case, I
can fix this later once I know whether, in principle, the
change is acceptable.

--dmr

[-- Attachment #2: 0001-no-mouse.patch --]
[-- Type: text/plain, Size: 2103 bytes --]

From 8e0522f053d369a73bd1f387d513303887363f51 Mon Sep 17 00:00:00 2001
From: Daniel Radetsky <dradetsky@gmail.com>
Date: Fri, 1 Nov 2024 00:00:33 -0700
Subject: [PATCH] no mouse

---
 src/keyboard.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/src/keyboard.c b/src/keyboard.c
index 6d28dca9aeb..37a1e86d6e6 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -1305,6 +1305,8 @@ some_mouse_moved (void)
   return NULL;
 }
 
+bool is_mouse_input (Lisp_Object);
+
 \f
 /* This is the actual command reading loop,
    sans error-handling encapsulation.  */
@@ -10420,6 +10422,20 @@ restore_reading_key_sequence (int old_reading_key_sequence)
    If DISABLE_TEXT_CONVERSION_P, disable text conversion so the input
    method will always send key events.  */
 
+/* Check if read key kind is a mouse input (so we can discard it if
+	 desired).  */
+bool
+is_mouse_input (Lisp_Object kind)
+{
+	return (EQ (kind, Qmouse_click) ||
+		EQ (kind, Qtouchscreen) ||
+		EQ (kind, Qtouchscreen_begin) ||
+		EQ (kind, Qtouchscreen_end) ||
+		EQ (kind, Qtouchscreen_update) ||
+		EQ (kind, Qtouch_end) ||
+		EQ (kind, Qpinch));
+}
+
 static int
 read_key_sequence (Lisp_Object *keybuf, Lisp_Object prompt,
 		   bool dont_downcase_last, bool can_return_switch_frame,
@@ -10924,6 +10940,11 @@ read_key_sequence (Lisp_Object *keybuf, Lisp_Object prompt,
       if (EVENT_HAS_PARAMETERS (key))
 	{
 	  Lisp_Object kind = EVENT_HEAD_KIND (EVENT_HEAD (key));
+		if (!NILP (ignore_mouse_input) && is_mouse_input (kind))
+			{
+				goto replay_key;
+			}
+
 	  if (EQ (kind, Qmouse_click) || EQ (kind, Qtouchscreen))
 	    {
 	      Lisp_Object window = POSN_WINDOW (EVENT_START (key));
@@ -13908,6 +13929,9 @@ syms_of_keyboard (void)
   DEFSYM (Qsuspend_resume_hook, "suspend-resume-hook");
   DEFSYM (Qcommand_error_default_function, "command-error-default-function");
   DEFSYM (Qsigusr2, "sigusr2");
+  DEFVAR_LISP ("ignore-mouse-input", ignore_mouse_input,
+	       doc: /* If non-nil, discard mouse input in the command loop */);
+  ignore_mouse_input = Qnil;
 }
 
 static void
-- 
2.46.1

Re: Disabling mouse input

[Corwin Brust]

Hi Daniel,

On Fri, Nov 1, 2024 at 9:01 PM Daniel Radetsky <dradetsky@gmail.com> wrote:
>
> I want to disable mouse input to emacs.

While reviewing your patch is beyond my meager abilities, I think I
might be able to try it out to at least confirm if it works fine under
Windows.

Mostly, I reply to say: disabling the mouse completely sounds like a
good feature to have; thanks for working on this!

Re: Disabling mouse input

[Daniel Radetsky]

On Fri, Nov 01, 2024 at 09:44:59PM GMT, Corwin Brust wrote:

> While reviewing your patch is beyond my meager abilities, I think I
> might be able to try it out to at least confirm if it works fine under
> Windows.

You could always just claim to have reviewed it. Nobody will
know. That will help to intimidate any developers who may be
on the fence about approving.

Also thanks for testing. Let me know how it goes.

Re: Disabling mouse input

[Eli Zaretskii]

> Date: Fri, 1 Nov 2024 19:01:00 -0700
> From: Daniel Radetsky <dradetsky@gmail.com>
> 
> I want to disable mouse input to emacs. One reason is that,
> while typing something on my laptop, I may accidentally hit
> the touchpad, whereupon emacs will complain that
> "C-c C-x <mouse-wheel-down> is not a real keybind" (whereas
> I had actually intended to enter C-c C-x j or something).
> This is annoying, and none of the common solutions to this
> problem (e.g. palm detection) seem good enough. Since I
> don't want to use the mouse with emacs to begin with, I'd
> rather just disable it altogether.
> 
> Unfortunately, there doesn't seem to be a way to do that.
> You can of course unbind the mouse inputs, but they will
> still be generated and lead to spurious errors as above.
> It's also not possible to solve this with advice since the
> calls to functions which generate the mouse inputs occur in
> C code. As far as I can tell, the only solution is hacking
> core emacs.

Not necessarily "hacking": changing the core will also do ;-)

(This should not surprise anyone, because input events are handled in
C, not in Lisp, and so disabling this in Lisp is expected to be
impossible.)

> Attached is a draft patch. I imagine I'll have to add
> more/better docs and other checklist items, but what I have
> here will allow others to see what I've done and tell me if
> I'm doing it the Right Way or the Stupid Way.
> 
> Basically, we define a lisp var in C `ignore-mouse-input`.
> If you setq it to t in emacs, you stop receiving mouse
> inputs. If you setq it back to nil, you get them again. It
> works for me, but unfortunately I have no idea how to write
> ert tests. Maybe somebody could point me to a few of the
> simple ones to study in order to get the idea.

Thanks, but this is not enough, and I also think it doesn't
necessarily ignore the mouse events on the right level.  We should
instead ignore these events where they are read, here:

          /* No need for FIONREAD or fcntl; just say don't wait.  */
	  while ((nr = (*t->read_socket_hook) (t, &hold_quit)) > 0)
	    nread += nr;

This loop should ignore and remove from the queue any events whose
'kind' (as declared in termhooks.h) is a mouse or touchpad event.  And
perhaps we also should allow ignoring the latter, but not the former.
Otherwise, the "ignored" input events will act like ghosts: they do
exist in the queue, and do trigger input-even related mechanisms we
have, such as while-no-input, but cannot be accessed.

Stefan, Po Lu (and others), do you agree?

In addition, we'd need to change display-mouse-p, so that it reflects
the fact that mouse clicks are not available.  Otherwise, some
features will present mouse-driven UI that cannot be used.

> +  DEFVAR_LISP ("ignore-mouse-input", ignore_mouse_input,
> +	       doc: /* If non-nil, discard mouse input in the command loop */);
> +  ignore_mouse_input = Qnil;

This should be DEFVAR_BOOL instead.

Re: Disabling mouse input

[Daniel Radetsky]

On Sat, Nov 02, 2024 at 09:38:20AM GMT, Eli Zaretskii wrote:
> (This should not surprise anyone, because input events are handled in
> C, not in Lisp, and so disabling this in Lisp is expected to be
> impossible.)

Well, everyone I talked to was sure it must be possible in
Lisp, so I figured somebody would ask eventually.

> Thanks, but this is not enough, and I also think it doesn't
> necessarily ignore the mouse events on the right level.  We should
> instead ignore these events where they are read, here:

It was clearly enough for you to tell me I was doing it the
Stupid Way, which was my objective, so I don't see the
problem. I mean, obviously you're not going to merge what I
sent. That wasn't the point.

> This loop should ignore and remove from the queue any events whose
> 'kind' (as declared in termhooks.h) is a mouse or touchpad event.  And
> perhaps we also should allow ignoring the latter, but not the former.

Sounds reasonable. I'll take another look soon.

> Otherwise, the "ignored" input events will act like ghosts: they do
> exist in the queue, and do trigger input-even related mechanisms we
> have, such as while-no-input, but cannot be accessed.

I can't tell if this issue is supposed to be a consequence
of not implementing ignore-touchpad-but-not-mouse, or of
ignoring the events the way I was doing it (via the goto in
read_key_sequence).

> In addition, we'd need to change display-mouse-p, so that it reflects
> the fact that mouse clicks are not available.  Otherwise, some
> features will present mouse-driven UI that cannot be used.

Good point. I'm thoroughly ignorant of emacs' mouse-driven UI.

> > +  DEFVAR_LISP ("ignore-mouse-input", ignore_mouse_input,
> > +	       doc: /* If non-nil, discard mouse input in the command loop */);
> > +  ignore_mouse_input = Qnil;
> 
> This should be DEFVAR_BOOL instead.

Okay, wasn't certain about that.

It was also suggested to me that other devs would want the
feature exposed via a global minor mode, not just a
variable. Do you? I looked into it and it was about 10 lines
of Lisp (most of which was to allow it to be set via
customize), so that's not a big deal if so. Or I mean
probably not; maybe I'll discover it's much worse in
practice once I know what's actually involved.

Thanks for the info.

Re: Disabling mouse input

[Eli Zaretskii]

> Date: Sat, 2 Nov 2024 03:17:39 -0700
> From: Daniel Radetsky <dradetsky@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Po Lu <luangruo@yahoo.com>, 
> 	emacs-devel@gnu.org
> 
> It was also suggested to me that other devs would want the
> feature exposed via a global minor mode, not just a
> variable. Do you?

I don't think it matters much at this point.  It is trivial to make a
minor mode based on a variable, and we've done that with some of the
variables.  Example: display-line-numbers-mode.  So I suggest to focus
on having the variable working correctly first, and worry about
whether making it a mode later.

Btw, a minor mode like that will only make sense if it's a global
minor mode, because making it buffer-local will be difficult even
conceptually.

Re: Disabling mouse input

[Stefan Monnier]

>> (This should not surprise anyone, because input events are handled in
>> C, not in Lisp, and so disabling this in Lisp is expected to be
>> impossible.)
> Well, everyone I talked to was sure it must be possible in
> Lisp, so I figured somebody would ask eventually.

My first intuition would be to do something like:

    (define-key input-decode-map [wheel-down] (lambda (_prompt) []))
    (define-key input-decode-map [wheel-up]   (lambda (_prompt) []))
    (define-key input-decode-map [mouse-1]    (lambda (_prompt) []))
    (define-key input-decode-map [mouse-2]    (lambda (_prompt) []))
    (define-key input-decode-map [mouse-3]    (lambda (_prompt) []))

If that works, then you'll probably want to add more bindings for those
cases where you hit the "mouse" while holding a modifier, i.e. something like:

    (dolist (modifier '(control meta nil))
      (dolist (base '(wheel-down wheel-up mouse-1 mouse-2 mouse-3))
        (define-key input-decode-map
                    (vector (event-convert-list (list modifier base)))
                    (lambda (_prompt) []))))
    

- Stefan

Re: Disabling mouse input

[James Cherti]

Your code snippet provides an interesting solution. Thank you for 
sharing it, Stefan.

--
James Cherti
https://www.jamescherti.com/

On 2024-11-02 09:38, Stefan Monnier wrote:
>>> (This should not surprise anyone, because input events are handled in
>>> C, not in Lisp, and so disabling this in Lisp is expected to be
>>> impossible.)
>> Well, everyone I talked to was sure it must be possible in
>> Lisp, so I figured somebody would ask eventually.
> My first intuition would be to do something like:
>
>      (define-key input-decode-map [wheel-down] (lambda (_prompt) []))
>      (define-key input-decode-map [wheel-up]   (lambda (_prompt) []))
>      (define-key input-decode-map [mouse-1]    (lambda (_prompt) []))
>      (define-key input-decode-map [mouse-2]    (lambda (_prompt) []))
>      (define-key input-decode-map [mouse-3]    (lambda (_prompt) []))
>
> If that works, then you'll probably want to add more bindings for those
> cases where you hit the "mouse" while holding a modifier, i.e. something like:
>
>      (dolist (modifier '(control meta nil))
>        (dolist (base '(wheel-down wheel-up mouse-1 mouse-2 mouse-3))
>          (define-key input-decode-map
>                      (vector (event-convert-list (list modifier base)))
>                      (lambda (_prompt) []))))
>      
>
> - Stefan
>
>

Re: Disabling mouse input

[Dov Grobgeld]

Why not disable the touchpad on the OS level? E.g. under X11 you can do it with:

    xinput set-prop 12 "Device Enabled" 0

where 12 is the id of the touchpad as seen by "xinput list". This also
prevents accidentally losing the focus of the emacs window. An
additional benefit is that this only turns off the touchpad, and if
you are using an external mouse, it still works.

This is what I do when working on my laptop, and I have a keybinding
in my window manager that toggles the enabling of the touchpad.

(Most laptops also have a low level driver option of turning off the
touchpad, but in my experience this doesn't always work under Linux.)

Regards,
Dov

On Sat, Nov 2, 2024 at 4:33 PM James Cherti <contact@jamescherti.com> wrote:
>
> Your code snippet provides an interesting solution. Thank you for
> sharing it, Stefan.
>
> --
> James Cherti
> https://www.jamescherti.com/
>
> On 2024-11-02 09:38, Stefan Monnier wrote:
> >>> (This should not surprise anyone, because input events are handled in
> >>> C, not in Lisp, and so disabling this in Lisp is expected to be
> >>> impossible.)
> >> Well, everyone I talked to was sure it must be possible in
> >> Lisp, so I figured somebody would ask eventually.
> > My first intuition would be to do something like:
> >
> >      (define-key input-decode-map [wheel-down] (lambda (_prompt) []))
> >      (define-key input-decode-map [wheel-up]   (lambda (_prompt) []))
> >      (define-key input-decode-map [mouse-1]    (lambda (_prompt) []))
> >      (define-key input-decode-map [mouse-2]    (lambda (_prompt) []))
> >      (define-key input-decode-map [mouse-3]    (lambda (_prompt) []))
> >
> > If that works, then you'll probably want to add more bindings for those
> > cases where you hit the "mouse" while holding a modifier, i.e. something like:
> >
> >      (dolist (modifier '(control meta nil))
> >        (dolist (base '(wheel-down wheel-up mouse-1 mouse-2 mouse-3))
> >          (define-key input-decode-map
> >                      (vector (event-convert-list (list modifier base)))
> >                      (lambda (_prompt) []))))
> >
> >
> > - Stefan
> >
> >
>

Re: Disabling mouse input

[Stefan Monnier]

> This is what I do when working on my laptop, and I have a keybinding
> in my window manager that toggles the enabling of the touchpad.

Along the same lines, I remember someone mentioning that they used
a tool which disables the touchpad for a short time after every
keyboard event.


        Stefan "who uses a trackpoint rather than a touchpad 🙂"

Re: Disabling mouse input

[tomas]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

On Sat, Nov 02, 2024 at 12:43:17PM -0400, Stefan Monnier wrote:
> > This is what I do when working on my laptop, and I have a keybinding
> > in my window manager that toggles the enabling of the touchpad.
> 
> Along the same lines, I remember someone mentioning that they used
> a tool which disables the touchpad for a short time after every
> keyboard event.
> 
> 
>         Stefan "who uses a trackpoint rather than a touchpad 🙂"

ISTR it was syndaemon (1), part of Debian package xserver-xorg-input-synaptics,
if you happen to inhabit a civilised operating system ;-)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Disabling mouse input

[James Cherti]

I prefer not to disable the touchpad at the OS level, as I still use it 
in other
applications like the web browser. My main goal is to avoid accidental 
clicks or
cursor movement in Emacs when I’m coding for extended periods. By 
disabling the
mouse only within Emacs, I can prevent these distractions while 
reinforcing a
keyboard-centric workflow, which helps me maintain my flow and avoid the 
slower
habit of relying on the mouse to move the cursor, for example.

--
James Cherti
https://www.jamescherti.com/

On 2024-11-02 12:30, Dov Grobgeld wrote:
> Why not disable the touchpad on the OS level? E.g. under X11 you can do it with:
>
>      xinput set-prop 12 "Device Enabled" 0
>
> where 12 is the id of the touchpad as seen by "xinput list". This also
> prevents accidentally losing the focus of the emacs window. An
> additional benefit is that this only turns off the touchpad, and if
> you are using an external mouse, it still works.
>
> This is what I do when working on my laptop, and I have a keybinding
> in my window manager that toggles the enabling of the touchpad.
>
> (Most laptops also have a low level driver option of turning off the
> touchpad, but in my experience this doesn't always work under Linux.)
>
> Regards,
> Dov
>
> On Sat, Nov 2, 2024 at 4:33 PM James Cherti <contact@jamescherti.com> wrote:
>> Your code snippet provides an interesting solution. Thank you for
>> sharing it, Stefan.
>>
>> --
>> James Cherti
>> https://www.jamescherti.com/
>>
>> On 2024-11-02 09:38, Stefan Monnier wrote:
>>>>> (This should not surprise anyone, because input events are handled in
>>>>> C, not in Lisp, and so disabling this in Lisp is expected to be
>>>>> impossible.)
>>>> Well, everyone I talked to was sure it must be possible in
>>>> Lisp, so I figured somebody would ask eventually.
>>> My first intuition would be to do something like:
>>>
>>>       (define-key input-decode-map [wheel-down] (lambda (_prompt) []))
>>>       (define-key input-decode-map [wheel-up]   (lambda (_prompt) []))
>>>       (define-key input-decode-map [mouse-1]    (lambda (_prompt) []))
>>>       (define-key input-decode-map [mouse-2]    (lambda (_prompt) []))
>>>       (define-key input-decode-map [mouse-3]    (lambda (_prompt) []))
>>>
>>> If that works, then you'll probably want to add more bindings for those
>>> cases where you hit the "mouse" while holding a modifier, i.e. something like:
>>>
>>>       (dolist (modifier '(control meta nil))
>>>         (dolist (base '(wheel-down wheel-up mouse-1 mouse-2 mouse-3))
>>>           (define-key input-decode-map
>>>                       (vector (event-convert-list (list modifier base)))
>>>                       (lambda (_prompt) []))))
>>>
>>>
>>> - Stefan
>>>
>>>

Re: Disabling mouse input

[tomas]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

On Sun, Nov 03, 2024 at 07:34:11AM -0500, James Cherti wrote:
> I prefer not to disable the touchpad at the OS level, as I still use it in
> other
> applications like the web browser.

That's why syndaemon (mentioned elsewhere in this thread)
offers a user-configurable timeout after the last key event
where pad events are ignored.

Personally I can't vouch for or against, since my typing
habits seem to naturally avoid the pad, but I know some
happy users.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Disabling mouse input

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Po Lu <luangruo@yahoo.com>,
>   emacs-devel@gnu.org
> Date: Sat, 02 Nov 2024 09:38:19 -0400
> 
> >> (This should not surprise anyone, because input events are handled in
> >> C, not in Lisp, and so disabling this in Lisp is expected to be
> >> impossible.)
> > Well, everyone I talked to was sure it must be possible in
> > Lisp, so I figured somebody would ask eventually.
> 
> My first intuition would be to do something like:
> 
>     (define-key input-decode-map [wheel-down] (lambda (_prompt) []))
>     (define-key input-decode-map [wheel-up]   (lambda (_prompt) []))
>     (define-key input-decode-map [mouse-1]    (lambda (_prompt) []))
>     (define-key input-decode-map [mouse-2]    (lambda (_prompt) []))
>     (define-key input-decode-map [mouse-3]    (lambda (_prompt) []))

Wouldn't that cause Emacs to think input events arrived, when some
mouse events are read by the socket hook?

Re: Disabling mouse input

[Stefan Monnier]

>>     (define-key input-decode-map [wheel-down] (lambda (_prompt) []))
>>     (define-key input-decode-map [wheel-up]   (lambda (_prompt) []))
>>     (define-key input-decode-map [mouse-1]    (lambda (_prompt) []))
>>     (define-key input-decode-map [mouse-2]    (lambda (_prompt) []))
>>     (define-key input-decode-map [mouse-3]    (lambda (_prompt) []))
>
> Wouldn't that cause Emacs to think input events arrived, when some
> mouse events are read by the socket hook?

I think the answer is yes, tho I'm not sure what you mean by "think
input events arrived" nor why you seem to think that would be a problem.


        Stefan

Re: Disabling mouse input

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dradetsky@gmail.com,  luangruo@yahoo.com,  emacs-devel@gnu.org
> Date: Sat, 02 Nov 2024 12:54:22 -0400
> 
> >>     (define-key input-decode-map [wheel-down] (lambda (_prompt) []))
> >>     (define-key input-decode-map [wheel-up]   (lambda (_prompt) []))
> >>     (define-key input-decode-map [mouse-1]    (lambda (_prompt) []))
> >>     (define-key input-decode-map [mouse-2]    (lambda (_prompt) []))
> >>     (define-key input-decode-map [mouse-3]    (lambda (_prompt) []))
> >
> > Wouldn't that cause Emacs to think input events arrived, when some
> > mouse events are read by the socket hook?
> 
> I think the answer is yes, tho I'm not sure what you mean by "think
> input events arrived" nor why you seem to think that would be a problem.

I mentioned that in my original comments: stuff like while-no-input
will think some input arrived, which is not what the users would want,
when this knob is used.

Which is why I prefer to prevent inserting the mouse events into the
input queue to begin with.

Re: Disabling mouse input

[Stefan Monnier]

>> I think the answer is yes, tho I'm not sure what you mean by "think
>> input events arrived" nor why you seem to think that would be a problem.
>
> I mentioned that in my original comments: stuff like while-no-input
> will think some input arrived, which is not what the users would want,
> when this knob is used.

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.


        Stefan

Re: Disabling mouse input

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dradetsky@gmail.com,  luangruo@yahoo.com,  emacs-devel@gnu.org
> Date: Sat, 02 Nov 2024 13:04:25 -0400
> 
> >> I think the answer is yes, tho I'm not sure what you mean by "think
> >> input events arrived" nor why you seem to think that would be a problem.
> >
> > I mentioned that in my original comments: stuff like while-no-input
> > will think some input arrived, which is not what the users would want,
> > when this knob is used.
> 
> 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, 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.

Re: Disabling mouse input

[Stefan Monnier]

>> 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-<FOO> to <FOO>, to
drop `drag` modifiers, etc...) into mere entries in `function-key-map`.

Re: Disabling mouse input

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dradetsky@gmail.com,  luangruo@yahoo.com,  emacs-devel@gnu.org
> Date: Sat, 02 Nov 2024 14:11:58 -0400
> 
> >> 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.

If the OP is happy with this kind of solution, I don't mind.

> > 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`.

And then what to do with track-mouse?

Re: Disabling mouse input

[Daniel Radetsky]

On Sat, Nov 02, 2024 at 02:11:58PM GMT, Stefan Monnier wrote:
> 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.

While I think you underestimate the frequency, I agree with
your concern and your suggestion looks intriguing so I'm
going to test it.

Re: Disabling mouse input

[Stefan Monnier]

>> 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.
> While I think you underestimate the frequency,

Let me rephrase: I do believe the problem of accidental touchpad events
is common, but there are *many* ways to attack this problem, each with
their own set tradeoffs.  So I think we should aim to provide tools
which make it possible to provide a very customizable behavior, since
every user will prefer particular tradeoffs.

For that reason, I'm in favor of adding generic support but not
ad-hoc support.

> I agree with your concern and your suggestion looks intriguing so I'm
> going to test it.

I'm curious to know how it works for your use case.  If you encounter
problems, do report them so we can see if maybe there's a way to provide
solutions for them.


        Stefan

Re: Disabling mouse input

[Daniel Radetsky]

On Sat, Nov 02, 2024 at 09:56:31PM GMT, Stefan Monnier wrote:
> For that reason, I'm in favor of adding generic support but not
> ad-hoc support.

Very sensible. FWIW, I provided low-genericity solution at
first just because I didn't want to invest a bunch of work
before I talked it over with y'all. I figured once (or if)
we established that the basic premise was sound (e.g. that I
had hooked the event check in at the right place) we could
talk about making it more complicated (like exposing the
to-filter event list to the user). As we seem to have
established the opposite, I'm glad I didn't.

> > I agree with your concern and your suggestion looks intriguing so I'm
> > going to test it.
> 
> I'm curious to know how it works for your use case.  If you encounter
> problems, do report them so we can see if maybe there's a way to provide
> solutions for them.

I created https://github.com/dradetsky/ignore-mouse. It
works in the sense of doing what I wanted. However, per
Eli's suggestion, the downsides of the approach are likely
to be subtle, and when they are problematic, difficult to
trace back to this package. But we'll see how it goes. If my
emacs explodes and kills the neighbor's dog, I won't mention
your name.

--dmr

Re: Disabling mouse input

[James Cherti]

Hello Stefan,

Just in case anyone is interested:

I have created a small Emacs package inspired by your idea of using
input-decode-map to disable the mouse:
https://github.com/jamescherti/inhibit-mouse.el

--
James Cherti
https://www.jamescherti.com/

On 2024-11-02 09:38, Stefan Monnier wrote:
>>> (This should not surprise anyone, because input events are handled in
>>> C, not in Lisp, and so disabling this in Lisp is expected to be
>>> impossible.)
>> Well, everyone I talked to was sure it must be possible in
>> Lisp, so I figured somebody would ask eventually.
> My first intuition would be to do something like:
>
>      (define-key input-decode-map [wheel-down] (lambda (_prompt) []))
>      (define-key input-decode-map [wheel-up]   (lambda (_prompt) []))
>      (define-key input-decode-map [mouse-1]    (lambda (_prompt) []))
>      (define-key input-decode-map [mouse-2]    (lambda (_prompt) []))
>      (define-key input-decode-map [mouse-3]    (lambda (_prompt) []))
>
> If that works, then you'll probably want to add more bindings for those
> cases where you hit the "mouse" while holding a modifier, i.e. something like:
>
>      (dolist (modifier '(control meta nil))
>        (dolist (base '(wheel-down wheel-up mouse-1 mouse-2 mouse-3))
>          (define-key input-decode-map
>                      (vector (event-convert-list (list modifier base)))
>                      (lambda (_prompt) []))))
>      
>
> - Stefan
>
>

Re: Disabling mouse input

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, but this is not enough, and I also think it doesn't
> necessarily ignore the mouse events on the right level.  We should
> instead ignore these events where they are read, here:
>
>           /* No need for FIONREAD or fcntl; just say don't wait.  */
> 	  while ((nr = (*t->read_socket_hook) (t, &hold_quit)) > 0)
> 	    nread += nr;
>
> This loop should ignore and remove from the queue any events whose
> 'kind' (as declared in termhooks.h) is a mouse or touchpad event.  And
> perhaps we also should allow ignoring the latter, but not the former.
> Otherwise, the "ignored" input events will act like ghosts: they do
> exist in the queue, and do trigger input-even related mechanisms we
> have, such as while-no-input, but cannot be accessed.
>
> Stefan, Po Lu (and others), do you agree?

I agree, and it's probably also a good idea to abort any key sequence
involving down-mouse-1 events if this option should be enabled during
them.

> In addition, we'd need to change display-mouse-p, so that it reflects
> the fact that mouse clicks are not available.  Otherwise, some
> features will present mouse-driven UI that cannot be used.

Though I confess to not having read enough of this conversation to
understand why this option is useful.  Surely it must be more difficult
to control Emacs with one input device than with two.

Re: Disabling mouse input

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Daniel Radetsky <dradetsky@gmail.com>,  Stefan Monnier
>  <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Mon, 04 Nov 2024 17:48:17 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thanks, but this is not enough, and I also think it doesn't
> > necessarily ignore the mouse events on the right level.  We should
> > instead ignore these events where they are read, here:
> >
> >           /* No need for FIONREAD or fcntl; just say don't wait.  */
> > 	  while ((nr = (*t->read_socket_hook) (t, &hold_quit)) > 0)
> > 	    nread += nr;
> >
> > This loop should ignore and remove from the queue any events whose
> > 'kind' (as declared in termhooks.h) is a mouse or touchpad event.  And
> > perhaps we also should allow ignoring the latter, but not the former.
> > Otherwise, the "ignored" input events will act like ghosts: they do
> > exist in the queue, and do trigger input-even related mechanisms we
> > have, such as while-no-input, but cannot be accessed.
> >
> > Stefan, Po Lu (and others), do you agree?
> 
> I agree, and it's probably also a good idea to abort any key sequence
> involving down-mouse-1 events if this option should be enabled during
> them.

If we filter mouse events in the above loop, down-mouse-1 etc. will
also be filtered, no?

> > In addition, we'd need to change display-mouse-p, so that it reflects
> > the fact that mouse clicks are not available.  Otherwise, some
> > features will present mouse-driven UI that cannot be used.
> 
> Though I confess to not having read enough of this conversation to
> understand why this option is useful.  Surely it must be more difficult
> to control Emacs with one input device than with two.

The rationale is to avoid unintended mouse moves and touchpad touches
from affecting Emacs.

Re: Disabling mouse input

[James Cherti]

Hello Daniel,

I tested your patch, and it works well. After applying it, I simply set
`ignore-mouse-input` to `t`, which completely disabled the mouse.

I hope this patch will be integrated into Emacs core. Like you, I prefer 
using
the keyboard exclusively, as I find it significantly more efficient than 
relying
on the mouse while developing software in Emacs.

Currently, I'm using the disable-mouse package to disable the mouse, but it
only remaps mouse key bindings, which is less elegant and efficient than
setting `ignore-mouse-input` to `t`.

--
James Cherti
https://www.jamescherti.com/

On 2024-11-01 22:01, Daniel Radetsky wrote:
> I want to disable mouse input to emacs. One reason is that,
> while typing something on my laptop, I may accidentally hit
> the touchpad, whereupon emacs will complain that
> "C-c C-x <mouse-wheel-down> is not a real keybind" (whereas
> I had actually intended to enter C-c C-x j or something).
> This is annoying, and none of the common solutions to this
> problem (e.g. palm detection) seem good enough. Since I
> don't want to use the mouse with emacs to begin with, I'd
> rather just disable it altogether.
>
> Unfortunately, there doesn't seem to be a way to do that.
> You can of course unbind the mouse inputs, but they will
> still be generated and lead to spurious errors as above.
> It's also not possible to solve this with advice since the
> calls to functions which generate the mouse inputs occur in
> C code. As far as I can tell, the only solution is hacking
> core emacs.
>
> Attached is a draft patch. I imagine I'll have to add
> more/better docs and other checklist items, but what I have
> here will allow others to see what I've done and tell me if
> I'm doing it the Right Way or the Stupid Way.
>
> Basically, we define a lisp var in C `ignore-mouse-input`.
> If you setq it to t in emacs, you stop receiving mouse
> inputs. If you setq it back to nil, you get them again. It
> works for me, but unfortunately I have no idea how to write
> ert tests. Maybe somebody could point me to a few of the
> simple ones to study in order to get the idea.
>
> Also, the C code does look a bit funny, but I couldn't
> figure out any automated way to check/fix it, and I'm not
> actually familiar with that C style. flycheck said it looked
> fine. I tried running clang-format, but it said there were
> already 3000 lines worth of errors in that file before I'd
> even touched it, so that's obviously out-of-date. I didn't
> see anything about this in the contrib guide. In any case, I
> can fix this later once I know whether, in principle, the
> change is acceptable.
>
> --dmr