bug#8116: 24.0.50; `minibuffer-message': ignore mouse-up event for `sit-for'?

["Drew Adams" <drew.adams@oracle.com>]

If you pop up a menu (e.g. using `x-popup-menu') and one of its items
calls `minibuffer-message', the user will never see the message,
presumably because the call to `sit-for' in `minibuffer-message' sees
the mouse-up event (from choosing the menu item) as user input,
canceling the `sit-for' timeout.
 
Seems like we should be able to make this work somehow.  Perhaps
`sit-for' could accept an optional arg listing a set of events to
ignore, and `minibuffer-message' could then call it with mouse-up
in that list?
 
But should _all_ uses of `minibuffer-message' ignore `mouse-up' events
wrt the timeout?  Dunno.  Sounds doubtful.
 
Still, this seems like something we should be able to handle, so that
users can see a message associated with a menu item.
 
Example use: A user chooses a menu item to cycle some variable/behavior
(e.g. a sort order) to the next possible value, and the action ends with
a message echoing what the new value is.  Currently, the user can do
this over and over without ever seeing what the new value is each time.
In some contexts it might not be convenient for the user to stop the
overall interaction just to interrogate the value.  That is, use of
the popup menu might be only one link in a chain of user interactions.
 
One possibility might be to move the `sit-for' out of
`minibuffer-message', making the calling code be responsible for it
instead.  That would be analogous to the way `message' is used.  But I'm
not sure how that would affect other things - perhaps it is important
that `minibuffer-message' calls `sit-for' itself.  Dunno.
 

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2011-02-14 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'