unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Popup-menu signals quit when Aborted
@ 2020-02-01 14:51 JD Smith
  2020-02-01 15:14 ` Eli Zaretskii
  2020-02-01 15:55 ` Stefan Monnier
  0 siblings, 2 replies; 8+ messages in thread
From: JD Smith @ 2020-02-01 14:51 UTC (permalink / raw)
  To: emacs-devel


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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Popup-menu signals quit when Aborted
  2020-02-01 14:51 Popup-menu signals quit when Aborted JD Smith
@ 2020-02-01 15:14 ` Eli Zaretskii
  2020-02-01 15:55 ` Stefan Monnier
  1 sibling, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2020-02-01 15:14 UTC (permalink / raw)
  To: JD Smith; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Popup-menu signals quit when Aborted
  2020-02-01 14:51 Popup-menu signals quit when Aborted JD Smith
  2020-02-01 15:14 ` Eli Zaretskii
@ 2020-02-01 15:55 ` Stefan Monnier
  2020-02-01 16:41   ` JD Smith
  1 sibling, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2020-02-01 15:55 UTC (permalink / raw)
  To: JD Smith; +Cc: emacs-devel

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




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Popup-menu signals quit when Aborted
  2020-02-01 15:55 ` Stefan Monnier
@ 2020-02-01 16:41   ` JD Smith
  2020-02-01 16:47     ` Stefan Monnier
  2020-02-01 16:48     ` Eli Zaretskii
  0 siblings, 2 replies; 8+ messages in thread
From: JD Smith @ 2020-02-01 16:41 UTC (permalink / raw)
  To: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Popup-menu signals quit when Aborted
  2020-02-01 16:41   ` JD Smith
@ 2020-02-01 16:47     ` Stefan Monnier
  2020-02-01 21:58       ` JD Smith
  2020-02-01 16:48     ` Eli Zaretskii
  1 sibling, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2020-02-01 16:47 UTC (permalink / raw)
  To: JD Smith; +Cc: emacs-devel

> 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




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Popup-menu signals quit when Aborted
  2020-02-01 16:41   ` JD Smith
  2020-02-01 16:47     ` Stefan Monnier
@ 2020-02-01 16:48     ` Eli Zaretskii
  2020-02-01 21:58       ` JD Smith
  1 sibling, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2020-02-01 16:48 UTC (permalink / raw)
  To: JD Smith; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Popup-menu signals quit when Aborted
  2020-02-01 16:47     ` Stefan Monnier
@ 2020-02-01 21:58       ` JD Smith
  0 siblings, 0 replies; 8+ messages in thread
From: JD Smith @ 2020-02-01 21:58 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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
> 




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Popup-menu signals quit when Aborted
  2020-02-01 16:48     ` Eli Zaretskii
@ 2020-02-01 21:58       ` JD Smith
  0 siblings, 0 replies; 8+ messages in thread
From: JD Smith @ 2020-02-01 21:58 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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?




^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2020-02-01 21:58 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-02-01 14:51 Popup-menu signals quit when Aborted JD Smith
2020-02-01 15:14 ` Eli Zaretskii
2020-02-01 15:55 ` Stefan Monnier
2020-02-01 16:41   ` JD Smith
2020-02-01 16:47     ` Stefan Monnier
2020-02-01 21:58       ` JD Smith
2020-02-01 16:48     ` Eli Zaretskii
2020-02-01 21:58       ` JD Smith

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).