GNU bug report logs -
#8116
24.0.50; `minibuffer-message': ignore mouse-up event for `sit-for' on Windows?
Previous Next
Reported by: "Drew Adams" <drew.adams <at> oracle.com>
Date: Fri, 25 Feb 2011 16:52:01 UTC
Severity: normal
Found in version 24.0.50
Done: Stefan Kangas <stefankangas <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8116 in the body.
You can then email your comments to 8116 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#8116
; Package
emacs
.
(Fri, 25 Feb 2011 16:52:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Drew Adams" <drew.adams <at> oracle.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 25 Feb 2011 16:52:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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'
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#8116
; Package
emacs
.
(Fri, 25 Feb 2011 18:07:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 8116 <at> debbugs.gnu.org (full text, mbox):
> 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
Agreed. I think the way to attack this is elsewhere, tho: the mouse-up
should be eaten up by the menu code.
Stefan
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#8116
; Package
emacs
.
(Fri, 25 Feb 2011 18:29:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 8116 <at> debbugs.gnu.org (full text, mbox):
> > Seems like we should be able to make this work somehow.
>
> Agreed. I think the way to attack this is elsewhere, tho:
> the mouse-up should be eaten up by the menu code.
Yes, that sounds good.
Dunno whether that would ever be an inconvenience - I can't think of a negative
use case. Seems like every menu selection action would always involve mouse
down + up.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#8116
; Package
emacs
.
(Sun, 18 Jul 2021 00:31:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 8116 <at> debbugs.gnu.org (full text, mbox):
"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?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 18 Jul 2021 00:31:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#8116
; Package
emacs
.
(Sun, 18 Jul 2021 02:06:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 8116 <at> debbugs.gnu.org (full text, mbox):
> Do you have a test case that demonstrates the problem?
The problem is specified in the bug report.
Whether the situation is problematic in the same way as
when the problem was reported, 10 years ago, someone
who uses Emacs 27 or the incipient 28 can investigate.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#8116
; Package
emacs
.
(Sun, 18 Jul 2021 06:52:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 8116 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#8116
; Package
emacs
.
(Sun, 18 Jul 2021 12:05:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 8116 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
>> Do you have a test case that demonstrates the problem?
>
> The problem is specified in the bug report.
A test case makes it much more likely that somebody will take the effort
to poke at this problem. Without a test case, that somebody will first
have to come up with one themselves.
But if you're not interested in being helpful, that's fine, of course.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#8116
; Package
emacs
.
(Sun, 18 Jul 2021 12:10:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 8116 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> 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.
Ah, I see. I'll rename the bug report to be more specific, then.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Changed bug title to '24.0.50; `minibuffer-message': ignore mouse-up event for `sit-for' on Windows?' from '24.0.50; `minibuffer-message': ignore mouse-up event for `sit-for'?'
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 18 Jul 2021 12:11:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#8116
; Package
emacs
.
(Sun, 18 Jul 2021 18:26:02 GMT)
Full text and
rfc822 format available.
Message #33 received at 8116 <at> debbugs.gnu.org (full text, mbox):
> But if you're not interested in being helpful,
> that's fine, of course.
Yet another snarky disparagement. Not helpful.
Follows on your "since Drew can't be bothered"
to send a patch - when the bug report provided
the exact replacement for the single function
that needed to be replaced.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#8116
; Package
emacs
.
(Sun, 18 Jul 2021 18:31:01 GMT)
Full text and
rfc822 format available.
Message #36 received at 8116 <at> debbugs.gnu.org (full text, mbox):
> > > 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.
Thanks for this info. I guess the bug can then either
be closed or kept open in the wishlist, the fix needing
redesign etc.
I wonder if this effect should be mentioned in the manual?
Removed tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 16 Aug 2021 12:12:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
Stefan Kangas <stefankangas <at> gmail.com>
:
You have taken responsibility.
(Wed, 12 Mar 2025 03:59:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
"Drew Adams" <drew.adams <at> oracle.com>
:
bug acknowledged by developer.
(Wed, 12 Mar 2025 03:59:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 8116-close <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#8116
; Package
emacs
.
(Wed, 12 Mar 2025 14:05:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 8116 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Tue, 11 Mar 2025 20:58:02 -0700
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 8116-close <at> debbugs.gnu.org, drew.adams <at> oracle.com
>
> 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.
Let's just ask Cecilio (CC'ed) whether he might have any ideas for
improving this aspect of Emacs's behavior on MS-Windows.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 10 Apr 2025 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 65 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.