[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Popup-menu signals quit when Aborted
From: |
JD Smith |
Subject: |
Re: Popup-menu signals quit when Aborted |
Date: |
Sat, 1 Feb 2020 16:58:53 -0500 |
Not my code, just investigating a possible bug on request of its author.
> On Feb 1, 2020, at 11:48 AM, Eli Zaretskii <address@hidden> wrote:
>
>> From: JD Smith <address@hidden>
>> 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?