Popup-menu signals quit when Aborted

Popup-menu signals quit when Aborted

[JD Smith]

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

This seems sensible.  But `popup-menu` "normalizes" all incoming positions using `popup-menu-normalize-position`, which strips any mouse event designation in the position before passing it on.  So there is no way via `popup-menu` to "indicat[e] that the user invoked the menu with the mouse”.  Hence it always quits and ring the bell when the user “gets rid of the menu".

Normalizing away mouse events in this manner seems like a bug in `popup-menu` to me, since `x-popup-menu` explicitly takes mouse events and behaves differently with them.

See https://github.com/tarsius/minions/issues/25 for original discussion.

Re: Popup-menu signals quit when Aborted

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Sat, 1 Feb 2020 09:51:22 -0500
> 
> `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.
> 
> This seems sensible.  But `popup-menu` "normalizes" all incoming positions using `popup-menu-normalize-position`, which strips any mouse event designation in the position before passing it on.  So there is no way via `popup-menu` to "indicat[e] that the user invoked the menu with the mouse”.  Hence it always quits and ring the bell when the user “gets rid of the menu".
> 
> Normalizing away mouse events in this manner seems like a bug in `popup-menu` to me, since `x-popup-menu` explicitly takes mouse events and behaves differently with them.
> 
> See https://github.com/tarsius/minions/issues/25 for original discussion.

Sorry, I don't understand the goal of the report.  You seem to be
talking about internal workings of popup-menu (which has to handle
both GUI and text-mode menus, btw), and I don't think I understand why
these internal workings are of any interest to applications that use
popup-menu.  Can you explain this point?

IOW, what would you like to see, in terms of behavior _external_ to
popup-menu?

And a short recipe, starting from "emacs -Q" and showing the problem,
would be most appreciated.

Thanks.

Re: Popup-menu signals quit when Aborted

[Stefan Monnier]

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


        Stefan

Re: Popup-menu signals quit when Aborted

[JD Smith]

[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]



> 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))


[-- Attachment #2: Type: text/html, Size: 3986 bytes --]

Re: Popup-menu signals quit when Aborted

[Stefan Monnier]

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

I understand it can be useful not to signal `quit`, but I don't
understand why it would make sense to make this choice depending on
whether or not it is a mouse-event that caused the menu to be displayed.


        Stefan

Re: Popup-menu signals quit when Aborted

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Sat, 1 Feb 2020 11:41:40 -0500
> 
>  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:

Any reason why you didn't use x-popup-menu?

Re: Popup-menu signals quit when Aborted

[JD Smith]

Not certain, so I can really only turn this around — I don’t understand why signaling quit and failing to return would ever be desirable when a user dismisses a popup menu by clicking off of it.  Maybe something to do with TTY menu equivalents?  

> On Feb 1, 2020, at 11:47 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> 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.
> 
> I understand it can be useful not to signal `quit`, but I don't
> understand why it would make sense to make this choice depending on
> whether or not it is a mouse-event that caused the menu to be displayed.
> 
> 
>        Stefan
> 

Re: Popup-menu signals quit when Aborted

[JD Smith]

Not my code, just investigating a possible bug on request of its author.  

> On Feb 1, 2020, at 11:48 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: JD Smith <jdtsmith@gmail.com>
>> Date: Sat, 1 Feb 2020 11:41:40 -0500
>> 
>> 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:
> 
> Any reason why you didn't use x-popup-menu?