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

[Eli Zaretskii <eliz@gnu.org>]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Mon, 23 Feb 2015 06:17:30 +0100
> Cc: Drew Adams <drew.adams@oracle.com>,
>  19925@debbugs.gnu.org
> 
> It sounds strange to tie tooltips to the blink cursor.

They aren't.  The problem is that tooltips pop up when help-echo
events are processed by the Emacs code that reads the event queue.
When a menu is active on w32, nothing triggers the queue-processing
code for many seconds, and so these help-echo events are not seen
until then, by which time a typical user will lose patience.  The
timer which blinks the cursor triggers that processing more frequently
as a side effect, and works around the problem.

> This is how it is done for X and NS:
> 
> On mousover, check if tooltip timer has been started, if not start it.
> If mouse moves outside area for tooltip, cancel timer, or if it moves into 
> another area, cancel timer and start a new one.
> When timer fires, inject an event to show tooltip.
> 
> Is this not how it is done on w32?

Yes, it's done exactly the same way on w32 (the code in tooltip.el is
system-agnostic).  But what you describe is just the end of the
tooltip display saga.  The beginning of the saga is when the
(terminal-specific) menu support code inserts a help-echo event into
the queue, which is then read from the queue, and causes Emacs to call
tooltip-show-help (via the show-help-function variable).  Next,
tooltip-show-help puts the help string into the tooltip-help-message
variable, and then starts the tooltip timer you mentioned, which, when
expired, actually causes the tooltip to be displayed.

So if the help-echo event is not read from the event queue, none of
the above will happen.  (I did verify that the help-echo events are
put into the event queue on w32.)

Having blink-cursor events come in frequently causes the event queue
to be read and the help-echo events be processed, which makes the
reaction time to mouse movements over menus much faster.

I might try to find time to look deeper into this, but my knowledge of
the Windows GUI programming is very scarce, so don't hold your breath.
People who have time and/or know more than I do about Windows GUI
programing are welcome to investigate and try solving this, or suggest
solutions they know will work.