GNU bug report logs -
#19925
25.0.50; mouseover menu items takes up to 30sec to show the proper tooltip or message
Previous Next
Full log
Message #34 received at 19925 <at> debbugs.gnu.org (full text, mbox):
> > 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.
This bug report was last modified 10 years and 112 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.