GNU bug report logs - #8116
24.0.50; `minibuffer-message': ignore mouse-up event for `sit-for' on Windows?

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#8116: closed (24.0.50; `minibuffer-message': ignore mouse-up
 event for `sit-for' on Windows?)
Date: Wed, 12 Mar 2025 03:59:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Tue, 11 Mar 2025 20:58:02 -0700
with message-id <CADwFkmnwxJO_ofefz=JW2kAphVvaDc2XNon4NXdz2JQUh2dssA <at> mail.gmail.com>
and subject line Re: bug#8116: 24.0.50; `minibuffer-message': ignore mouse-up event for `sit-for' on Windows?
has caused the debbugs.gnu.org bug report #8116,
regarding 24.0.50; `minibuffer-message': ignore mouse-up event for `sit-for' on Windows?
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
8116: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8116
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.50; `minibuffer-message': ignore mouse-up event for `sit-for'?
Date: Fri, 25 Feb 2011 08:50:15 -0800

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'
 

[Message part 3 (message/rfc822, inline)]

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, drew.adams <at> oracle.com,
 8116-close <at> debbugs.gnu.org
Subject: Re: bug#8116: 24.0.50; `minibuffer-message': ignore mouse-up event
 for `sit-for' on Windows?
Date: Tue, 11 Mar 2025 20:58:02 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Date: Sun, 18 Jul 2021 02:30:08 +0200
>> Cc: 8116 <at> debbugs.gnu.org
>>
>> "Drew Adams" <drew.adams <at> oracle.com> writes:
>>
>> > 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.
>>
>> Do you have a test case that demonstrates the problem?
>
> You won't be able to see this on any system but MS-Windows.  On
> Windows, the Emacs menus are implemented in a way that has this
> unfortunate side effect: we basically preempt the Emacs command loop
> for as long as the menu stays open.
>
> If someone wants to redesign how Emacs menus are implemented on
> Windows, I think that would be very welcome.  But until that happens,
> this is Emacs "functioning as designed", not some easily-fixed bug.

It sounds like this is not going to be an easy fix, but require a
redesign.  Without a patch, that sounds rather unlikely.  I'm therefore
closing this bug report now, as this is the expected behavior.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.