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.