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

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

[Drew Adams]

> 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.)

I would suggest that:

1. Users will expect help on menu items to just work, out of the box.

2. They, like I, will not understand the default behavior.  And as
   I mentioned earlier, they will get into trouble by relying on the
   incorrect information that is displayed (unsynced pointer position
   and displayed help).  They could even get into big trouble - loss
   of data, by picking the wrong menu item.

3. The connection between option `blink-cursor-blink' and this
   unfortunate default behavior is, to put it mildly, difficult to
   discover.  Even if I look at the doc for `blink-cursor-blink' I
   would have a hard time making the connection.  And of course a
   user will not land on the `blink-cursor-blink' doc by accident
   in this context.

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.

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

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?

If that's not feasible then I do hope that #1 and #2 will be done.
The current situation is not friendly to users, and it makes Emacs
look like it is quite handicapped and unhelpful.

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

[Drew Adams]

I see that this bug report is similar to that of #18543.
Please feel free to merge them if you think that is appropriate.

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

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

[Drew Adams]

> > 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).

How about as a user choice (option)?  Not everyone is on a battery
all of the time. ;-)

> > 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.

Great; good to hear.

> 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

When this has all been taken care of, as best we (you) can, is there
a user option that should be added or enhanced, to give users control
over the possibilities?  Just wondering.

Thx.

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

[Eli Zaretskii]

> Date: Mon, 23 Feb 2015 11:17:21 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 19925@debbugs.gnu.org
> 
> > > 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).
> 
> How about as a user choice (option)?

blink-cursor-blinks is a defcustom, so the user option already exists.
Or maybe I don't understand what do you mean by "user option".

> > 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
> 
> When this has all been taken care of, as best we (you) can, is there
> a user option that should be added or enhanced, to give users control
> over the possibilities?  Just wondering.

Again, I think we already have enough knobs there.

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

[Drew Adams]

> > > > 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).
> >
> > How about as a user choice (option)?
>
> blink-cursor-blinks is a defcustom, so the user option already exists.
> Or maybe I don't understand what do you mean by "user option".

Ignore, please.

> > > 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
> >
> > When this has all been taken care of, as best we (you) can, is there
> > a user option that should be added or enhanced, to give users control
> > over the possibilities?  Just wondering.
> 
> Again, I think we already have enough knobs there.

OK.

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

[Drew Adams]

Moving the mouse over menu items, a user should see the associated
:help pretty much immediately - at most after a delay of a second or
two.

Instead, sometimes the help text is shown immediately, sometimes it is
shown only after, say, 30 seconds, and sometimes after any number of
seconds less than, say, 30.  I'm not sure, but I think the problem might
be somewhat more pronounced for items on a submenu or a subsubmenu.

The same problem occurs, regardless of whether tooltip mode is on.  That
is, it happens whether the mouseover text is shown in a tooltip or in
the echo area.

This bug renders mouseover help on menu items useless, and it makes
Emacs look pretty bad.

Worse: because the help text for a previously mouseovered menu item
remains displayed, a user can read it mistakenly as the help for the
item the mouse is currently over.  That is, the text is not removed when
you move mouse away from a given item, just as it is not updated when
you move mouse to another item.  The help display is, well, the
opposite of helpful.

In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
 of 2014-10-20 on LEG570
Bzr revision: 118168 rgm@gnu.org-20141020195941-icp42t8ttcnud09g
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking=yes,glyphs CPPFLAGS=-DGLYPH_DEBUG=1'

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 14:54:44 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> Moving the mouse over menu items, a user should see the associated
> :help pretty much immediately - at most after a delay of a second or
> two.
> 
> Instead, sometimes the help text is shown immediately, sometimes it is
> shown only after, say, 30 seconds, and sometimes after any number of
> seconds less than, say, 30.  I'm not sure, but I think the problem might
> be somewhat more pronounced for items on a submenu or a subsubmenu.
> 
> The same problem occurs, regardless of whether tooltip mode is on.  That
> is, it happens whether the mouseover text is shown in a tooltip or in
> the echo area.
> 
> This bug renders mouseover help on menu items useless, and it makes
> Emacs look pretty bad.
> 
> Worse: because the help text for a previously mouseovered menu item
> remains displayed, a user can read it mistakenly as the help for the
> item the mouse is currently over.  That is, the text is not removed when
> you move mouse away from a given item, just as it is not updated when
> you move mouse to another item.  The help display is, well, the
> opposite of helpful.

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.

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

[Stefan Monnier]

> 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.

Can't we cause regular dummy events?


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Drew Adams <drew.adams@oracle.com>,  19925@debbugs.gnu.org
> Date: Sun, 22 Feb 2015 23:39:52 -0500
> 
> Can't we cause regular dummy events?

We could, but sounds complicated, for the same reasons temporarily
binding blink-cursor-blinks to zero is: you'd have to start those
dummy events when the menu is activated (otherwise processing these
events will effectively undo the benign effect of batteries of
stopping the blinking), and stop them when the menu pops down, which
is tricky at best, as I explained elsewhere in this thread.

But if someone wants to work on this, and they come up with a clean
patch, it'd be welcome.

Bonus points for explaining why the tips _are_ displayed, but after a
much longer delays than intended.

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

[Jan D.]

Hi.

> 23 feb 2015 kl. 04:42 skrev Eli Zaretskii <eliz@gnu.org>:
> 
>> Date: Sun, 22 Feb 2015 14:54:44 -0800 (PST)
>> From: Drew Adams <drew.adams@oracle.com>
>> 
>> Moving the mouse over menu items, a user should see the associated
>> :help pretty much immediately - at most after a delay of a second or
>> two.
>> 
>> Instead, sometimes the help text is shown immediately, sometimes it is
>> shown only after, say, 30 seconds, and sometimes after any number of
>> seconds less than, say, 30.  I'm not sure, but I think the problem might
>> be somewhat more pronounced for items on a submenu or a subsubmenu.
>> 
>> The same problem occurs, regardless of whether tooltip mode is on.  That
>> is, it happens whether the mouseover text is shown in a tooltip or in
>> the echo area.
>> 
>> This bug renders mouseover help on menu items useless, and it makes
>> Emacs look pretty bad.
>> 
>> Worse: because the help text for a previously mouseovered menu item
>> remains displayed, a user can read it mistakenly as the help for the
>> item the mouse is currently over.  That is, the text is not removed when
>> you move mouse away from a given item, just as it is not updated when
>> you move mouse to another item.  The help display is, well, the
>> opposite of helpful.
> 
> 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.

It sounds strange to tie tooltips to the blink cursor.  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.

I this not how it is done on w32?  If not, why not?
I know enough about w32 to know that this is doable.

	Jan D.

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

[Eli Zaretskii]

> 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.