> On Feb 1, 2020, at 10:55 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> `x-popup-menu` is setup to handle mouse events specially when “aborting” the
>> menu by clicking off of it:
>> 
>>> If the user gets rid of the menu without making a valid choice, for
>>> instance by clicking the mouse away from a valid choice or by typing
>>> keyboard input, then this normally results in a quit and
>>> ‘x-popup-menu’ does not return. But if POSITION is a mouse button
>>> event (indicating that the user invoked the menu with the mouse) then
>>> no quit occurs and ‘x-popup-menu’ returns nil.
> 
> I wasn't aware (or if I was, I forgot about it in the mean time) of
> this oddity.
> 
>> This seems sensible.
> 
> I'm glad you find it so, because I can't figure out the underlying logic
> of this oddity.  Can you explain why you think it's sensible?


It seems sensible to me that if a mouse-event generates a popup menu, and it is “gotten rid of” by the user by clicking off the menu, that this should NOT signal a quit and ring the bell as if some kind of error has occurred.  This is what `x-popup-menu` appears to implement, but its higher-level interface `popup-menu` inhibits this sensible feature by “normalizing” positions.  

I encountered this using minions mode.  Its popup menu for minor modes is very useful, but sometimes you just want to take a quick look at what modes are set, and not alter anything. But clicking off the menu to get rid of it signals ‘quit and rings the bell.  Reading the note above in `x-popup-menu` I considered passing a mouse event would be a reliable fix.  But since `popup-menu` strips event information, the only remaining possibility is to trap the quit:

(condition-case nil
        (popup-menu map)
      (quit nil)))

This seems rather heavy-handed.  You can try a simple example (click off the menu):

(let ((menu-bar (make-sparse-keymap "Dismiss Menu")))
  (define-key menu-bar [testing] '(menu-item "Nothing" nil))
  (popup-menu menu-bar))