all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 19925@debbugs.gnu.org
Subject: bug#19925: 25.0.50; mouseover menu items takes up to 30sec to show the proper tooltip or	message
Date: Sun, 22 Feb 2015 20:29:06 -0800 (PST)	[thread overview]
Message-ID: <b1bbbbd9-9a78-42e1-bce0-4b2f14666348@default> (raw)
In-Reply-To: <<837fv98faf.fsf@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.)

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.





       reply	other threads:[~2015-02-23  4:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<1d10f417-acb4-4b32-8bc3-fe949388330d@default>
     [not found] ` <<837fv98faf.fsf@gnu.org>
2015-02-23  4:29   ` Drew Adams [this message]
2015-02-23  4:33     ` bug#19925: 25.0.50; mouseover menu items takes up to 30sec to show the proper tooltip or message Drew Adams
2015-02-23 17:54     ` Eli Zaretskii
     [not found] <<b1bbbbd9-9a78-42e1-bce0-4b2f14666348@default>
     [not found] ` <<83zj847bur.fsf@gnu.org>
2015-02-23 19:17   ` Drew Adams
2015-02-23 19:42     ` Eli Zaretskii
     [not found]   ` <<ffcbfc26-1f09-4b68-ade2-f0e8c16a6115@default>
     [not found]     ` <<83vbis76tm.fsf@gnu.org>
2015-02-23 19:51       ` Drew Adams
2015-02-22 22:54 Drew Adams
2015-02-23  3:42 ` Eli Zaretskii
2015-02-23  4:39   ` Stefan Monnier
2015-02-23 17:56     ` Eli Zaretskii
2015-02-23  5:17   ` Jan D.
2015-02-23 18:07     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b1bbbbd9-9a78-42e1-bce0-4b2f14666348@default \
    --to=drew.adams@oracle.com \
    --cc=19925@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.