Re: `y-or-n-p' does not wait for input - assumes `n'

[Stefan Monnier]

>     I disagree.  The problem is actually not limited to mouse-movement.
>     There's also switch-frame and select-window.

> Could you give a bit more details of the problems that occur with the
> latter two events?  Since generation of switch-frame and select-window
> events is not limited to inside an unusual construct such as
> track-mouse, I would expect them to happen often if they happen at
> all.  But people don't seem to be complaining about such problems.
> Why not?

Probably because those events are much less common (select-window is only
used if mouse-autoselect-window is set and it's a new var, and switch-frame
only happens if you really move the mouse "non trivially").

My point wasn't that there are serious cases, but just that it's completely
normal for a caller of read-event to have to explicitly ignore some events.
It's actually the rule rather than the exception.  So it makes sense to
explicitly ignore mouse-movement events rather than to try and silence them
by binding track-mouse to nil.

>     Most code that uses things like read-event end up looping and filtering
>     unwanted events.

> Yes, I see that y-or-n-p does this thru read_filtered_event.

> Most Emacs input uses read-key-sequence, which handles those funny
> events for you.  Using read-event means you get all kinds of events;
> that is what it's for.  You have to be prepared to handle them all.

Agreed.

> I don't see how to make this situation better in general.  Do you have
> an idea to suggest?

No.  Although I guess it could be useful to introduce (a hierarchy of)
classes of events so that code can ignore "all events generated by a mouse
movement" without having to list them (i.e. mouse-movement, switch-frame,
select-window, maybe help-echo, ...).


        Stefan