RE: address@hidden: Lingering input pending with motifmenu bar]

[Drew Adams]

        I've found a Lisp-level workaround --- by using `read-event' and
        `with-timeout', it's possible to catch just the events we are
        interested in (i.e., mouse clicks and keystrokes).  It took quite a
        long time to find something that works, though.

    If this is the right way to wait N seconds, we should make sit-for do
    this, so that user programs don't have to use a complex work-around.

    If this indeed works right, then I think putting this into sit-for
    is a clear bug-fix.  Would you like to do it?

Please make sure that all possible user events are treated. I don't know if
Chong meant to include mouse wheel in "mouse clicks", but wheel movement
should be included as a user event that ends `sit-for'. Likewise, drag
events (which aren't clicks either). Also, at least some of the special
events (`special-event-map') are user events (e.g. iconify-frame,
delete-frame).

Even though the doc of `sit-for' speaks of input events, I wonder if there
isn't perhaps some existing code that expects `sit-for' to also stop waiting
for other, non-user events. We shall see...

Also, if we fix `sit-for' this way, would something similar need to be done
for code that sets variables such as `last-input-event'? I'm guessing that
here and there current code already tries to distinguish user events, and it
might need updating to use the correct approach. IOW, maybe the same
approach should be used elsewhere.

Because the exact list of events that are user-initiated might change (e.g.
over releases), I wonder if it would be worth defining `user-event' as a
type (category) of events and `user-event-p' as its test. Then, any code
that deals with this would use that, and the exact set of user events would
only be updated in one place.

Is the `sit-for' bug fix to be made before the release?