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

From: Eli Zaretskii <[email-masked]>
Date: Wed, 12 Mar 2025 16:04:03 +0200

> From: Stefan Kangas <[email-masked]>
> Date: Tue, 11 Mar 2025 20:58:02 -0700
> Cc: Lars Ingebrigtsen <[email-masked]>, [email-masked], [email-masked]
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> >> From: Lars Ingebrigtsen <[email-masked]>
> >> Date: Sun, 18 Jul 2021 02:30:08 +0200
> >> Cc: [email-masked]
> >>
> >> "Drew Adams" <[email-masked]> 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.