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