bug#19925: 25.0.50; mouseover menu items takes up to 30sec to show the proper tooltip or message

[Eli Zaretskii]

> Date: Sun, 22 Feb 2015 20:29:06 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 19925@debbugs.gnu.org
> 
> > AFAICS, that's because the cursor stops blinking after 10 blinks.
> > Make it blink forever, and the problem is gone.
> > 
> > There's nothing that can be done here to fix this.  Tooltips for w32
> > menu items need input events to pop up, because when a menu is shown,
> > Emacs doesn't have control, and waits for the menu to pop down.
> 
> Excellent reply; thank you, Eli.  Changing `blink-cursor-blinks' to
> 0 does indeed make both tooltip help and echo-area help work properly
> for mouseover.
> 
> (I assume that what you say about the limitation of w32 tooltips for
> menu items applies also to echo-area help for menu items.)

Yes.  The problem is that the help-echo events are not being
processed, so any tooltips in any form will not show up.

> I would suggest the following, as a partial remedy:
> 
> 1. This defect (yes, it is a defect, even if it is the result of
>    using a particular OS or window manager) should be documented
>    fairly prominently, where tooltip and echo-area help is presented.
> 
>    That means not only the manual but also the doc string of
>    `tooltip-mode' - not because this has anything to do with that
>    mode (the problem exists whether the mode is on or off), but
>    only because a user looking for help regarding this behavior
>    might look for things having to do with tooltips.

I didn't document it yet, as we don't normally document subtle bugs,
and with the change described below, users will hopefully seldom bump
into this, at least in the default configuration.

> 2. Make the default value of `blink-cursor-blinks' be 0, at least
>    on the platforms that present this defect.

I don't see any chance for this suggestion to be accepted, what with
the current trend towards laptops and saving battery power (which were
the main motivation behind the default behavior of stopping the
blinking after a few blinks).

> Would it perhaps be possible also to change the value to 0 as soon
> as a user mouseovers a menu?  And then change it back to its
> previous value when the menu is no longer displayed?  Could Emacs
> detect those events?  IOW, before "waiting for the menu to pop down",
> couldn't it set the value to 0, and then when it pops down set it
> back to its previous value?

This is infeasible on w32, at least not with simple, localized
(a.k.a. "safe") changes.  The processing of w32 menu-bar menus is
triggered by the main thread, but is implemented, including popping
the menu down, in the input thread, so a temporary binding is tricky
at best, because the input thread cannot run Lisp or make changes to
Lisp-related variables, and the main (a.k.a "Lisp") thread doesn't
get any triggers when the menu is popped down, so it cannot restore
the original value.

Instead, I've stopped incrementing the blink-cursor counter while the
menu is active on w32, so it never reaches the limit, and doesn't stop
the blinking, until the menu is popped down.

So there was something to be done after all, thanks for the idea.

The default behavior is now (almost) fixed on the emacs-24 branch.  I
say "almost" because there are still a couple of subtle issues:

 . disabling blink-cursor-mode brings the problem back again
 . dropping a menu when the cursor already stopped blinking shows the
   problem (because clicking to drop a menu doesn't count as an input
   event on w32, and so the cursor doesn't resume blinking)
 . the "solution" is really a band-aid, and I hope a better solution
   will be found eventually