Better default values for tooltip padding and `tooltip-hide-delay'?

Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Hello!

So far, I used Emacs 21.3 on Windows which doesn't have tooltips, so
tooltips are quite new for me. I would like to make two suggestions:

1. Since I started to use CVS Emacs, I always found the `padding' of
   the tooltips too large. Now I started to look if this is
   customizable and found `tooltip-frame-parameters', and indeed the
   padding can be changed -- it defaults to `(internal-border-width .
   5)'.

   I suggest a change of `internal-border-width' to either 1 or 2
   instead of 5. The reason is that the tooltips are too large and
   hide too much text in the buffer (for example in occur-mode
   buffers, where I like to highlight the current match by putting the
   mouse on that line so that that line is highlighted). A tooltip
   should be a `hint', but the large padding makes them more like a
   `banner'. (I don't want to turn them off either as I think they are
   quite useful -- they are just a little too big in my opinion.)

   Compared to the GNOME 2.10 tooltips, the default of 5 in Emacs
   seems to be similar, but I think (internal-border-width . 2) is
   aesthetically more pleasing, and (internal-border-width . 1) is
   also okay, but real minimalistic, so I suggest 2.
   
2. I also believed (until yesterday) that the only way to make a
   tooltip disappear is to move the mouse away from the `green area'.
   This impression was caused by the value of `tooltip-hide-delay',
   which defaults to 10 seconds. IMO, this is far too long. I
   experimented a little and I think that setting it to 3 or 4 seconds
   is much better and still long enough for reading the tooltip. 10
   seconds until the tooltip goes away feels like an eternity.

It would be great if some of you could try (setq tooltip-hide-delay 3)
and (setq tooltip-hide-delay 4) as well as customize the
`internal-border-width' of `tooltip-frame-parameters' to 2. What do
you think?

Regards,
-- 
Christian Schlauer

RE: Better default values for tooltip padding and `tooltip-hide-delay'?

[Drew Adams]

    1. the `padding' of the tooltips too large. ...       
    2. `tooltip-hide-delay' defaults to 10 seconds.
       IMO, this is far too long.

FWIW, I agree with both points.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Frank Schmitt]

"Drew Adams" <drew.adams@oracle.com> writes:

>     1. the `padding' of the tooltips too large. ...       
>     2. `tooltip-hide-delay' defaults to 10 seconds.
>        IMO, this is far too long.
>
> FWIW, I agree with both points.

me2

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Frank Schmitt <ich@frank-schmitt.net> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>>     1. the `padding' of the tooltips too large. ...       
>>     2. `tooltip-hide-delay' defaults to 10 seconds.
>>        IMO, this is far too long.
>>
>> FWIW, I agree with both points.
>
> me2

So I conclude that /everybody/ who commented on this agrees with me
and would like to see the defaults changed [1]. I looked into
tooltip.el, it is written by Gerd Moellmann -- but he seems not to be
involved anymore, at least I haven't seen him on this list lately. Who
is making such decisions now?

(Please see <URL:http://thread.gmane.org/gmane.emacs.devel/41032> for
details.)

[1] "everybody" = three individuals (including me)
-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Jason Rumney]

Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:

> Frank Schmitt <ich@frank-schmitt.net> writes:
>
>> "Drew Adams" <drew.adams@oracle.com> writes:
>>
>>>     1. the `padding' of the tooltips too large. ...       
>>>     2. `tooltip-hide-delay' defaults to 10 seconds.
>>>        IMO, this is far too long.
>
> So I conclude that /everybody/ who commented on this agrees with me
>
> [1] "everybody" = three individuals (including me)

I didn't see the original, but I strongly disagree that 10 seconds is
too long for reading a potentially long message in a tooltip. As long
as the user is not using the keyboard or mouse, what harm is there in
continuing to display the tooltip?

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Frank Schmitt]

Jason Rumney <jasonr@gnu.org> writes:

> Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:
>
>> Frank Schmitt <ich@frank-schmitt.net> writes:
>>
>>> "Drew Adams" <drew.adams@oracle.com> writes:
>>>
>>>>     1. the `padding' of the tooltips too large. ...       
>>>>     2. `tooltip-hide-delay' defaults to 10 seconds.
>>>>        IMO, this is far too long.
>>
>> So I conclude that /everybody/ who commented on this agrees with me
>>
>> [1] "everybody" = three individuals (including me)
>
> I didn't see the original, but I strongly disagree that 10 seconds is
> too long for reading a potentially long message in a tooltip. As long
> as the user is not using the keyboard or mouse, what harm is there in
> continuing to display the tooltip?

Tooltip are for me normally over point, and therefore over the text
most recently written, hiding it. I need it to go away to see what I
wrote last so I can continue there. To be able to do it I must either
insert some character I don't really want to type or reach over for the
mouse.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Jason Rumney]

Frank Schmitt <ich@frank-schmitt.net> writes:

> Tooltip are for me normally over point, and therefore over the text
> most recently written, hiding it. I need it to go away to see what I
> wrote last so I can continue there. To be able to do it I must either
> insert some character I don't really want to type or reach over for the
> mouse.

It is unusual for the mouse to be normally over point, do you have
some special code for making the mouse track point (anti-avoid.el)?
I think that would be annoying whether tooltips popped up or not.

But this has been discussed in October 2001, when the default was 5
seconds, and the consensus then was to increase tooltip-hide-delay to
10 seconds. So I don't think we should change it now without carefully
considering the arguments that were made for increasing it in the
first place.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Luc Teirlinck]

Frank Schmidt wrote:

   Tooltip are for me normally over point, and therefore over the text
   most recently written, hiding it. I need it to go away to see what I
   wrote last so I can continue there.

That problem completely goes away if you set tooltip-mode to nil.
And you still get exactly the same info in the echo area (which many
people do not seem to be aware of).

Sincerely,

Luc.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Kevin Rodgers]

Frank Schmitt wrote:
 > Tooltip are for me normally over point, and therefore over the text
 > most recently written, hiding it. I need it to go away to see what I
 > wrote last so I can continue there. To be able to do it I must either
 > insert some character I don't really want to type or reach over for the
 > mouse.

C-l

-- 
Kevin Rodgers

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Daniel Brockman]

Jason Rumney <jasonr@gnu.org> writes:

> I didn't see the original, but I strongly disagree that 10
> seconds is too long for reading a potentially long message
> in a tooltip.

Me too.  Why stop displaying it after 10 seconds even?
That limit seems really arbitrary and annoying.

> As long as the user is not using the keyboard or mouse,
> what harm is there in continuing to display the tooltip?

Exactly.  Why not keep displaying it until the user starts
typing or moves the mouse away from the tooltipped object?
After all, if the user has not yet done one of those things,
he or she is probably still reading the tooltip.

-- 
Daniel Brockman <daniel@brockman.se>

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Andreas Schwab]

Daniel Brockman <daniel@brockman.se> writes:

> Jason Rumney <jasonr@gnu.org> writes:
>
>> I didn't see the original, but I strongly disagree that 10
>> seconds is too long for reading a potentially long message
>> in a tooltip.
>
> Me too.  Why stop displaying it after 10 seconds even?
> That limit seems really arbitrary and annoying.

If a tooltip cannot be read in 10 seconds then it is too long, IMHO.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Daniel Brockman]

Andreas Schwab <schwab@suse.de> writes:

> If a tooltip cannot be read in 10 seconds then it is
> too long, IMHO.

By that logic, we should make echo area messages go away
after a while too, so people don't make them "too long".

As I said, in my mind, if the user has not yet moved the
mouse or started typing, he or she is probably still reading
the tooltip.  If that's not right, then what am I missing?

-- 
Daniel Brockman <daniel@brockman.se>

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Andreas Schwab]

Daniel Brockman <daniel@brockman.se> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> If a tooltip cannot be read in 10 seconds then it is
>> too long, IMHO.
>
> By that logic, we should make echo area messages go away
> after a while too, so people don't make them "too long".

Echo area messages don't hide other parts of the display, as long as they
fit in one screen line.  And yes, they should be short as well.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Daniel Brockman]

Andreas Schwab <schwab@suse.de> writes:

> Echo area messages don't hide other parts of the display,
> as long as they fit in one screen line.

So would you advocate adding a timeout for echo area
messages that don't fit in one screen line?

-- 
Daniel Brockman <daniel@brockman.se>

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Andreas Schwab]

Daniel Brockman <daniel@brockman.se> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> Echo area messages don't hide other parts of the display,
>> as long as they fit in one screen line.
>
> So would you advocate adding a timeout for echo area
> messages that don't fit in one screen line?

No, they are not nearly as bad as big tooltips.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Stefan Monnier]

> If a tooltip cannot be read in 10 seconds then it is too long, IMHO.

You're confusing on-the-fly quick help messages and help-echo tooltip
messages.  Most help-echo messages are meant as on-the-fly quick help
messages, but it doesn't have to be the case.  They can be used to give some
extra info instead, in which case they could be fairly long and detailed.


        Stefan

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> If a tooltip cannot be read in 10 seconds then it is too long, IMHO.
>
> You're confusing on-the-fly quick help messages and help-echo tooltip
> messages. 

I don't think so.

> They can be used to give some extra info instead, in which case they
> could be fairly long and detailed.

The problem with big tooltips is that they obscure large parts of the
display.  As such they are only disturbing most of the time.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> If a tooltip cannot be read in 10 seconds then it is too long, IMHO.
>
> You're confusing on-the-fly quick help messages and help-echo tooltip
> messages.  Most help-echo messages are meant as on-the-fly quick help
> messages, but it doesn't have to be the case.  They can be used to give some
> extra info instead, in which case they could be fairly long and detailed.

I just have the feeling that most tooltips are so short so that they
can be read in 3 to 4 seconds. Displaying all tooltips for 10 seconds
just because there are some tooltips that are fairly long is not
perfect, IMO. How could this be solved? Personally I'd find it
acceptable to `re-trigger' a long tooltip (by moving the mouse off of
the `trigger element' and on it again) in order to be able to read the
rest of it, but maybe others find that this is bad style.

What about my other suggestion: changing `internal-border-width' of
`tooltip-frame-parameters' to 2 instead of 5? The genereous `padding'
around the tooltips really wastes space on the screen. As I said in my
original message, I think that a tooltip should be a `hint', but the
large padding makes them more like a `banner'. (I don't want to turn
them off either as I think they are quite useful -- they are just a
little too big in my opinion.)

,----
| tooltip-frame-parameters's value is 
| ((name . "tooltip")
|  (internal-border-width . 5)
|  (border-width . 1))
`----

-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Lennart Borgman]

Christian Schlauer wrote:

>I just have the feeling that most tooltips are so short so that they
>can be read in 3 to 4 seconds. Displaying all tooltips for 10 seconds
>just because there are some tooltips that are fairly long is not
>perfect, IMO. How could this be solved? Personally I'd find it
>acceptable to `re-trigger' a long tooltip (by moving the mouse off of
>the `trigger element' and on it again) in order to be able to read the
>rest of it, but maybe others find that this is bad style.
>  
>
I would prefer something like having ESC remove the tooltip by default.

>What about my other suggestion: changing `internal-border-width' of
>`tooltip-frame-parameters' to 2 instead of 5? The genereous `padding'
>  
>
Looks much better with 2 IMHO.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Jason Rumney]

Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:

> What about my other suggestion: changing `internal-border-width' of
> `tooltip-frame-parameters' to 2 instead of 5?

I don't have any objection to this. The original reason for 5 was to
be consistent with GNOME, but recent versions of GNOME seem to use
less padding now (2 or 3 pixels by the look of it). We should find out
exactly what GNOME uses (it may be a fraction of the font height for
example) and try to be consistent with that.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Jason Rumney <jasonr@gnu.org> writes:

> Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:
>
>> What about my other suggestion: changing `internal-border-width' of
>> `tooltip-frame-parameters' to 2 instead of 5?
>
> I don't have any objection to this. The original reason for 5 was to
> be consistent with GNOME, but recent versions of GNOME seem to use
> less padding now (2 or 3 pixels by the look of it).

I looked in their Human Interface Guidelines
<URL:http://developer.gnome.org/projects/gup/hig/2.0/>, but that
information is not found there.

> We should find out exactly what GNOME uses (it may be a fraction of
> the font height for example) and try to be consistent with that.

Will you pursue that? I'd really like to see this changed ...
-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Jason Rumney]

Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:

> Jason Rumney <jasonr@gnu.org> writes:
>
>> We should find out exactly what GNOME uses (it may be a fraction of
>> the font height for example) and try to be consistent with that.
>
> Will you pursue that? I'd really like to see this changed ...

gtk+/gtk/gtktooltips.c has a hardcoded "border width" of 4.

It is difficult to tell whether gtk's "border-width" is equivalent to
Emacs' internal-border-width, or internal-border-width + border-width,
since I can't put both tooltips next to each other for a careful
comparison.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Jason Rumney <jasonr@gnu.org> writes:

> Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:
>
>> Jason Rumney <jasonr@gnu.org> writes:
>>
>>> We should find out exactly what GNOME uses (it may be a fraction of
>>> the font height for example) and try to be consistent with that.
>>
>> Will you pursue that? I'd really like to see this changed ...
>
> gtk+/gtk/gtktooltips.c has a hardcoded "border width" of 4.
>
> It is difficult to tell whether gtk's "border-width" is equivalent to
> Emacs' internal-border-width, or internal-border-width + border-width,
> since I can't put both tooltips next to each other for a careful
> comparison.

I looked at GTK 2.6.4 (GNOME 2.10) tooltips now as well. All I can
tell is that Emacs' tooltips are larger at the moment (the font is
larger, too).

But I wonder if one should really stick to the GNOME padding: I looked
for tooltips in two GNOME applications, gedit and nautilus. I actually
expected some tooltips in nautilus, for example when the files are
viewed in `icon view' and I hover over a file icon, or when the column
is too small in `list view' in order to show the full file name. No
tooltip displayed the full file name (in list view) or the size of the
file (in icon view).

So what I think is that GNOME applications use tooltips in the menu
and toolbar area only, while Emacs excessively uses tooltips even in
the buffer. The latter makes me think that Emacs tooltips should have
little padding in order to not hide too much in the buffer, _ignoring_
how GNOME-tooltips look as they aren't used excessively in the main
`working window' of GNOME applications.

When you change `internal-border-width' to 2, what do you think of it?
Lennart wrote that this is much better, too.

(You use w32 too -- have you looked at the tooltips in Mozilla
Firefox? They are small with a small font size and little padding on
Windows, and they stay open for about 4 seconds -- try it on
<URL:http://www.emacswiki.org>, hover over `SiteMap'! That's a perfect
tooltip, IMO. On Ubuntu, Firefox is integrated in GNOME though and
uses GNOME-sized tooltips.)
-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:

[...]

> On Ubuntu, Firefox is integrated in GNOME though and uses
> GNOME-sized tooltips.

I have to correct myself: Firefox uses its own tooltip-size on both
w32 and on GNOME 2.10 (Ubuntu).
-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Richard M. Stallman]

There is no need for Emacs to follow GTK in regard to borders on
toolbars.  Let's do whatever Emacs users prefer.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Richard M. Stallman]

    What about my other suggestion: changing `internal-border-width' of
    `tooltip-frame-parameters' to 2 instead of 5?

Sounds good to me.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Richard M. Stallman]

    I didn't see the original, but I strongly disagree that 10 seconds is
    too long for reading a potentially long message in a tooltip. As long
    as the user is not using the keyboard or mouse, what harm is there in
    continuing to display the tooltip?

I often find that tooltips hide something useful.
That is with window manager tooltips, not Emacs tooltips;
I run Emacs on a console, so I don't often run into Emacs tooltips.
However, if people have similr experiences with Emacs tooltips,
that would be a good reason for them to disappear.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Jason Rumney <jasonr@gnu.org> writes:

> Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:
>
>> Frank Schmitt <ich@frank-schmitt.net> writes:
>>
>>> "Drew Adams" <drew.adams@oracle.com> writes:
>>>
>>>>     1. the `padding' of the tooltips too large. ...       
>>>>     2. `tooltip-hide-delay' defaults to 10 seconds.
>>>>        IMO, this is far too long.
>>
>> So I conclude that /everybody/ who commented on this agrees with me
>>
>> [1] "everybody" = three individuals (including me)
>
> I didn't see the original, but I strongly disagree that 10 seconds is
> too long for reading a potentially long message in a tooltip. As long
> as the user is not using the keyboard or mouse, what harm is there in
> continuing to display the tooltip?

I like tooltips, especially in major modes that I don't use that
often. But I will give two examples where I find them /really/
annoying, and that's why I suggested a change:

In the original message
<URL:http://article.gmane.org/gmane.emacs.devel/41032>, I already
wrote about `occur-mode': I like to highlight the match I'm currently
interested in by putting the mouse on that line in the *Occur* buffer
so that that line is highlighted in green. But then a part of that
line (and a part in the line above it) will be covered by "mouse-2: go
to this occurrence" for 10 seconds. Most tooltips are of that length,
it seems to me. I even think that tooltips that pop up when hovering
with the mouse in a buffer should not be much longer than that. Such
tooltips can then be read in 3 or 4 seconds. Covering text in the
buffer for 10 seconds for long tooltips is annoying (IMO) as tooltips
shouldn't be that long (IMO).

Second example: when diffing with `M-x ediff-buffers', there can be
`fine differences' (highlighted in light and dark blue) in a
`difference region'. Then I often `read' on the screen with the mouse
pointer in the difference region, but actually I can't do that because
/all the time/ there pops up a "Difference region 1 -- non-current" or
"Difference region 1 -- current", depending on the mouse pointer being
just in the (green or yellow) difference region or over a (blue) `fine
difference'. It's impossible to use the mouse-pointer as a reading-aid
to check the `fine differences' step-by-step. Maybe this is ediff's
fault and ediff should be changed to be less `aggressive'?

-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Stefan Monnier]

> In the original message
> <URL:http://article.gmane.org/gmane.emacs.devel/41032>, I already
> wrote about `occur-mode': I like to highlight the match I'm currently
> interested in by putting the mouse on that line in the *Occur* buffer
> so that that line is highlighted in green.  But then a part of that

Have you tried hl-line-mode in occur buffers?

> difference'.  It's impossible to use the mouse-pointer as a reading-aid
> to check the `fine differences' step-by-step.  Maybe this is ediff's
> fault and ediff should be changed to be less `aggressive'?

Hmm... I'd never seen someone use the mouse pointer as a reading aid (it
seems more common for people to use packages like avoid.el to move the
mouse cursor out of sight).  Obviously in such a case tooltips are
really annoying.  Have you tried M-x tooltip-mode RET ?


        Stefan

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> In the original message
>> <URL:http://article.gmane.org/gmane.emacs.devel/41032>, I already
>> wrote about `occur-mode': I like to highlight the match I'm currently
>> interested in by putting the mouse on that line in the *Occur* buffer
>> so that that line is highlighted in green.  But then a part of that
>
> Have you tried hl-line-mode in occur buffers?

I have used it, but not in occur buffers. I'll try.

>> difference'.  It's impossible to use the mouse-pointer as a reading-aid
>> to check the `fine differences' step-by-step.  Maybe this is ediff's
>> fault and ediff should be changed to be less `aggressive'?
>
> Hmm... I'd never seen someone use the mouse pointer as a reading aid

I normally don't do that either, but with ediff I do: the small ediff
frame has the focus, left hand on the keyboard presses the space bar
to move from difference to difference, right hand moves mouse pointer
from one `fine difference' to the next in the buffer with the latest
version.

> (it seems more common for people to use packages like avoid.el to
> move the mouse cursor out of sight). Obviously in such a case
> tooltips are really annoying. Have you tried M-x tooltip-mode RET ?

I think tooltip-mode is nice most of the time, so I haven't tried
that. I'd have to turn tooltip-mode off only in ediff-mode-hook, I
think. But in ediff, what are these "Difference region 1 --
non-current" and "Difference region 1 -- current" tooltips trying to
tell me, anyway? I'm in difference region one, but that I can also see
in the bottom line of the small ediff-frame. What is this
"current"/"non-current" about? I can see that `fine differences' are
"non-current" and the rest of the difference region is "current".
(info "(ediff)Highlighting Difference Regions") doesn't explain this,
it is only about the faces.

Maybe those tooltips are superfluous and should be taken out?
-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Stefan Monnier]

>> (it seems more common for people to use packages like avoid.el to
>> move the mouse cursor out of sight). Obviously in such a case
>> tooltips are really annoying. Have you tried M-x tooltip-mode RET ?

> I think tooltip-mode is nice most of the time, so I haven't tried
> that. I'd have to turn tooltip-mode off only in ediff-mode-hook, I
> think.

I have it turned off and am quite happy with it: the help-echo message is
still present if I need it, but displayed in the echo area where it doesn't
bother me when I don't need it.

> But in ediff, what are these "Difference region 1 -- non-current" and
> "Difference region 1 -- current" tooltips trying to tell me, anyway?

Ah, I didn't know about that (I always have my mouse pointer in the small
ediff frame because I use focus-follows-mouse), but the way you describe it,
it does seem to be of dubious value indeed.  But that doesn't mean that
tooltips shouldn't also be improved so as to be less bothersome in
such cases.


        Stefan

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Richard M. Stallman]

    wrote about `occur-mode': I like to highlight the match I'm currently
    interested in by putting the mouse on that line in the *Occur* buffer
    so that that line is highlighted in green. But then a part of that
    line (and a part in the line above it) will be covered by "mouse-2: go
    to this occurrence" for 10 seconds. Most tooltips are of that length,
    it seems to me. 

I understand the scenario, but I am not sure what to do about it.
Perhaps put the tooltip some distance up or down from the mouse
position?  Would that be good?

    Second example: when diffing with `M-x ediff-buffers', there can be
    `fine differences' (highlighted in light and dark blue) in a
    `difference region'. Then I often `read' on the screen with the mouse
    pointer in the difference region, but actually I can't do that because
    /all the time/ there pops up

Would the change I suggested above help with this case?

    Maybe this is ediff's
    fault and ediff should be changed to be less `aggressive'?

Sorry, I do not understand.  What change in behavior of ediff
are you suggesting?

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

"Richard M. Stallman" <rms@gnu.org> writes:

>     wrote about `occur-mode': I like to highlight the match I'm currently
>     interested in by putting the mouse on that line in the *Occur* buffer
>     so that that line is highlighted in green. But then a part of that
>     line (and a part in the line above it) will be covered by "mouse-2: go
>     to this occurrence" for 10 seconds. Most tooltips are of that length,
>     it seems to me. 
>
> I understand the scenario, but I am not sure what to do about it.
> Perhaps put the tooltip some distance up or down from the mouse
> position?

There is already some offset. Maybe `tooltip-x-offset' and
`tooltip-y-offset' are responsible for that, but they are not
documented:

,----[ C-h v tooltip-x-offset RET ]
| tooltip-x-offset's value is nil
| 
| Not documented as a variable.
| 
| You can customize this variable.
| 
| Defined in `tooltip'.
| 
| [back]
`----

> Would that be good?

I think the current offset is fine. I'd prefer a shorter
`tooltip-hide-delay' (4 seconds instead of 10), but that depends on
how long a tooltip may be. The Gnome Human Interface Guidelines say
"While tooltips should not be verbose, they should be longer and more
descriptive than the item's name."
<URL:http://developer.gnome.org/projects/gup/hig/2.0/desktop-integration.html#menu-item-tooltips>.
I think the "not be verbose" also suggests (quite) short tooltips.

Now I found this message
<URL:http://lists.gnu.org/archive/html/emacs-devel/2001-10/msg00379.html>
where /you/ suggest to change it to 10 seconds. I guess that makes any
attempts to change it back futile ;-)

Maybe we could agree on leaving `tooltip-hide-delay' as is (I'll
customize it then) and just change the `padding'? There were only
positive comments about reducing the padding (by you, Lennart and
Jason).

>     Second example: when diffing with `M-x ediff-buffers', there can be
>     `fine differences' (highlighted in light and dark blue) in a
>     `difference region'. Then I often `read' on the screen with the mouse
>     pointer in the difference region, but actually I can't do that because
>     /all the time/ there pops up
>
> Would the change I suggested above help with this case?
>
>     Maybe this is ediff's
>     fault and ediff should be changed to be less `aggressive'?
>
> Sorry, I do not understand.  What change in behavior of ediff
> are you suggesting?

The more I think about it, I think the best would be to remove the
tooltips that pop up when hovering with the mouse over a difference
region.

As I wrote in my reply to Stefan: in short, I don't understand what
the tooltips "Difference region 1 -- non-current" and "Difference
region 1 -- current" that pop up in difference regions are supposed to
tell me. The difference regions are not mouse-sensitive in a special
way, mouse-1/2/3 work as usual, so there is no special function for
mouse-1/2/3 that has to be explained, and the tooltip string tells me
things I can see somewhere else (which difference region I am in) and
things I don't understand ("non-current" and "current").

-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:

[placement of tooltips in relation to the mouse pointer]

> I think the current offset is fine.

I changed my mind: as Jason writes, most applications (including GNOME
and Mozilla Firefox) put tooltips below the pointer, so Emacs should,
too.

-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[David Kastrup]

Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:

> Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:
>
> [placement of tooltips in relation to the mouse pointer]
>
>> I think the current offset is fine.
>
> I changed my mind: as Jason writes, most applications (including
> GNOME and Mozilla Firefox) put tooltips below the pointer, so Emacs
> should, too.

If I move the mouse cursor to some point, it is a reasonable guess
that I have already read the stuff above the mouse point, but not yet
below.  This _very_ much holds true for tooltips in menus.  Regardless
of what other applications do, I think that I'd object to mouse tips
occuring _below_ mouse point.  It would render menu tooltips quite
obnoxious.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Jason Rumney]

"Richard M. Stallman" <rms@gnu.org> writes:

> I understand the scenario, but I am not sure what to do about it.
> Perhaps put the tooltip some distance up or down from the mouse
> position?  Would that be good?

Most applications put the tooltip below the mouse. The default for
tooltip-y-offset in Emacs is -10, which puts it above the mouse.
Maybe it is worth making the default something like 40 or even 50 (the
offset seems to be to the bottom edge of the tooltip), which puts the
tooltip a safe distance below the pointer.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Andreas Schwab]

Jason Rumney <jasonr@gnu.org> writes:

> Most applications put the tooltip below the mouse. The default for
> tooltip-y-offset in Emacs is -10, which puts it above the mouse.
> Maybe it is worth making the default something like 40 or even 50 (the
> offset seems to be to the bottom edge of the tooltip), which puts the
> tooltip a safe distance below the pointer.

I'd also suggest to make the tooltip face specify a font height of 75%.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Lennart Borgman]

Andreas Schwab wrote:

>I'd also suggest to make the tooltip face specify a font height of 75%.
>  
>
Why? If that is easily readable why not make the default font smaller 
instead?

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Andreas Schwab]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Andreas Schwab wrote:
>
>>I'd also suggest to make the tooltip face specify a font height of 75%.
>>  
>>
> Why? If that is easily readable why not make the default font smaller 
> instead?

IMHO it looks better if the tooltip font is slightly smaller than the
default font.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Andreas Schwab <schwab@suse.de> writes:

> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>> Andreas Schwab wrote:
>>
>>>I'd also suggest to make the tooltip face specify a font height of 75%.
>>>  
>>>
>> Why? If that is easily readable why not make the default font smaller 
>> instead?
>
> IMHO it looks better if the tooltip font is slightly smaller than the
> default font.

I agree. How does GNOME do this?
-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Richard M. Stallman]

    Most applications put the tooltip below the mouse. The default for
    tooltip-y-offset in Emacs is -10, which puts it above the mouse.

It seems silly to allow nil as a value equivalent to -10, or 40.
What benefit does that complexity provide?  I see none.  Does
anyone else see a reason to keep this?

It would be simpler to put the default value in the defcustom
directly, and limit this variable to integers.

I would like people to try setting the value to 40 and tell me what
they think.

    I'd also suggest to make the tooltip face specify a font height of 75%.

Would people please try that, too?

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

"Richard M. Stallman" <rms@gnu.org> writes:


[...]

>     I'd also suggest to make the tooltip face specify a font height of 75%.
>
> Would people please try that, too?

I tried that one.

On Ubuntu GNU/Linux, `emacs -q' uses the font
`-Adobe-Courier-Medium-R-Normal--17-120-100-100-M-100-ISO8859-1'.
Then, the tooltip face looks best with a height of 0.75 or 0.8, but
there is a big size difference between these two settings: the `l' of
`sample' in the customize buffer has the following heights:

0.75 -> 9 pixels
0.8  -> 11 pixels
0.9  -> 11 pixels
1.0  -> 12 pixels

With my preferred font,
`-Misc-Fixed-Medium-R-Normal--15-140-75-75-C-90-ISO8859-1' a.k.a.
`9x15', I get:

0.75 -> 8 pixels
0.8  -> 9 pixels
0.9  -> 11 pixels
1.0  -> 11 pixels

So it shouldn't be 0.75 as that is too small with 9x15. What about
0.8? It is reasonable with both fonts I tried, although the effect is
less pronounced with the `default' font on Ubuntu.

-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Stefan Monnier]

> So it shouldn't be 0.75 as that is too small with 9x15. What about
> 0.8? It is reasonable with both fonts I tried, although the effect is
> less pronounced with the `default' font on Ubuntu.

For what it's worth: LaTeX's font-lock places a "superscript" face on some
elements of the text (presumably superscripts) and uses a 0.8 factor for
that.  I myself use a small default font (misc-fixed-semicondensed-13, aka
6x13) and that is still quite readable.


        Stefan

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Richard M. Stallman]

    So it shouldn't be 0.75 as that is too small with 9x15. What about
    0.8? It is reasonable with both fonts I tried, although the effect is
    less pronounced with the `default' font on Ubuntu.

What do others think?

RE: Better default values for tooltip padding and `tooltip-hide-delay'?

[Drew Adams]

        So it shouldn't be 0.75 as that is too small with 9x15. What about
        0.8? It is reasonable with both fonts I tried, although the
        effect is less pronounced with the `default' font on Ubuntu.

    What do others think?

Since you asked -

I haven't tried any of the different font sizes, but my a-priori opinion is:

1. The tooltip font size should be the same as the size of the frame default
font.

2. Users should be able to explicitly change the tooltip font size (only).

Moving to a smaller font automatically is a bad idea. Some people have
difficulty with small text, so they set the frame font to a readable size.
Automatically introducing smaller text presents an unnecessary obstacle to
them.

Moving to a larger font automatically does not introduce this problem, but
there is also no reason to do it.

In sum, let the default tooltip font size be the same as the frame font
size - not the default frame's default font size, but the size of the
current default font for the given frame.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Lennart Borgman]

Drew Adams wrote:

>1. The tooltip font size should be the same as the size of the frame default
>font.
>
>2. Users should be able to explicitly change the tooltip font size (only).
>
>Moving to a smaller font automatically is a bad idea. Some people have
>difficulty with small text, so they set the frame font to a readable size.
>Automatically introducing smaller text presents an unnecessary obstacle to
>them.
>  
>
I really agree. The question must not only be what looks most nice. We 
should also care about people having viewing difficulties.

BTW this is a rather common problem in web design also. Unfortunately it 
is not always taken care of in a accessability review since it might 
focus on people with very bad disabilities.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Stefan Monnier]

> 1. The tooltip font size should be the same as the size of the frame default
>    font.

Let me add my vote to it.


        Stefan

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Hello,

I'll try to summarize what has been discussed in this thread. (You can
find the whole thread under
<URL:http://thread.gmane.org/gmane.emacs.devel/41032>.)

The following things were proposed/discussed:

1. Change `tooltip-hide-delay' (the display time of tooltips) from 10
   seconds to 4 seconds.

   Suggested by me, Frank Schmitt and Drew Adams agreed, but met a lot
   of resistance after that. It was changed from 5 seconds to 10
   seconds in October 2001, see
   <URL:http://lists.gnu.org/archive/html/emacs-devel/2001-10/msg00379.html>.

2. Scale the tooltip face to 75 %.

   Suggested by Andreas Schwab, tested by me, I suggested 80 %, but
   Lennart, Drew and Stefan want to keep the current size (100 %).

3. Reduce the `padding' of the tooltips, i. e. change
   `(internal-border-width . 5)' in `tooltip-frame-parameters' to 2.

   Suggested by me and supported by Drew, Frank, Lennart, and Richard.
   Jason said one should check how GNOME does this and follow them,
   but Richard answered that it is not necessary to follow GNOME.

4. Placement of tooltips above or below mouse pointer?

   Most other applications place the tooltip below the mouse, but
   David has a point when he writes "it is a reasonable guess that I
   have already read the stuff above the mouse point, but not yet
   below" and thus prefers the current behaviour.

My conclusion from this is that it is best to keep almost everything
as it is, except for point 3, the `padding' of the tooltips. No one
was against that change.

Can this be changed?

Regards,
-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Chong Yidong]

Another tooltip-related note: it seems to me that most other
applications do not display tooltips for menu-bar items.  The idea,
presumably, is that since a menu-bar item consists of text, that is
enough to explain what the item does; whereas tool-bar buttons need
tooltips because they only consist of icons or short text labels.

For instance, the menu-bar item

  Visit New File

has the tooltip

  Read and create a file or edit it

Does the tooltip really impart any information that the item doesn't?

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Luc Teirlinck]

Chong Yidong wrote:

   Another tooltip-related note: it seems to me that most other
   applications do not display tooltips for menu-bar items.  The idea,
   presumably, is that since a menu-bar item consists of text, that is
   enough to explain what the item does;

The trouble is that this assumption is often false.  Actually, many
other applications have a manual doing essentially nothing else but
explain what the toolbar and menu bar items do.  I very often have to
read the manual to figure these things out.

In the extremely rare instances where I use the Emacs menu bar, I find
many of the provided help-echo messages very useful and often
absolutely necessary for a correct understanding.  Maybe you use the
menu bar much more frequently than I do and hence you do not need
these help echos any more.  If I often need them, I would be surprised
if complete newbies never needed them.

This entire thread is about the fact that tooltips popping up in your
face are annoying.  I know, that is why I disable Tooltip Mode.  I get
exactly the same text in the echo area, where it does not annoy me.
Tooltip Mode is enabled by default because supposedly newbies are
accustomed to tooltips.  But if you are going to use the fact that
tooltips are annoying as an argument to use help echos less often or
make them less extensive, then that is definitely _not_ going to help
newbies (nor more advanced users who may often need the help too).  If
tooltips bother you, as they do me, just turn off Tooltip Mode, as I do.

Sincerely,

Luc Teirlinck.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> In the extremely rare instances where I use the Emacs menu bar, I find
> many of the provided help-echo messages very useful and often
> absolutely necessary for a correct understanding.

I agree with you.

> This entire thread is about the fact that tooltips popping up in your
> face are annoying.

I don't agree. Only in Ediff-mode they are annoying, otherwise I find
them just too big ;-)

> I know, that is why I disable Tooltip Mode. I get exactly the same
> text in the echo area, where it does not annoy me.

But do you read them in the echo area? I disabled tooltip-mode, but
I'm not used to move my eyes up and down between the mouse pointer
somewhere in the buffer to the corresponding tooltip displayed in the
echo area. This is really inconvenient, IMHO. So turning off
tooltip-mode means that I won't have any use of them: too much eye
work to read them down there!

(I'm surprised that it is a big difference (for me) between moving the
eyes from left to right over a distance of about 70 characters (i.e.,
reading -> easy) and moving the eyes up and down over a distance of
about 43 rows (i.e., reading the tooltips of toolbar icons in the echo
area -> uncomfortable).)
-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Lennart Borgman]

Christian Schlauer wrote:

>But do you read them in the echo area? I disabled tooltip-mode, but
>I'm not used to move my eyes up and down between the mouse pointer
>somewhere in the buffer to the corresponding tooltip displayed in the
>echo area. This is really inconvenient, IMHO. So turning off
>tooltip-mode means that I won't have any use of them: too much eye
>work to read them down there!
>
>(I'm surprised that it is a big difference (for me) between moving the
>eyes from left to right over a distance of about 70 characters (i.e.,
>reading -> easy) and moving the eyes up and down over a distance of
>about 43 rows (i.e., reading the tooltips of toolbar icons in the echo
>area -> uncomfortable).)
>  
>
I wonder what is best for your eyes? They are made for moving aren't 
they? I suppose you have all heard the stories about the traditional 
Chinese eye movement training in the schools there.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Luc Teirlinck]

Christian Schlauer wrote:

   But do you read them in the echo area? I disabled tooltip-mode, but
   I'm not used to move my eyes up and down between the mouse pointer
   somewhere in the buffer to the corresponding tooltip displayed in the
   echo area. This is really inconvenient, IMHO.

I personally do not find it inconvenient.  Emacs displays many
messages in the echo area that are worth reading, even if tooltip-mode
is enabled.  So I am used to pay attention to that area.  Moreover, if
something changes on my screen while everything else stays static, my
eyes automatically seem to shift to the area that changed anyway.  For
me this is pretty much an automatic reaction.  There is no conscious
effort involved.

Sincerely,

Luc.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Christian Schlauer wrote:
>
>    But do you read them in the echo area? I disabled tooltip-mode, but
>    I'm not used to move my eyes up and down between the mouse pointer
>    somewhere in the buffer to the corresponding tooltip displayed in the
>    echo area. This is really inconvenient, IMHO.
>
> I personally do not find it inconvenient.  Emacs displays many
> messages in the echo area that are worth reading, even if tooltip-mode
> is enabled.  So I am used to pay attention to that area.

Of course. But I find it inconvenient to jump with the eyes from the
mouse pointer which is over a button/toolbar icon/menu entry down to
the echo area where it is explained what the button/toolbar icon/menu
entry does.

IMO, tooltips should pop up very close to the item they describe, not
at the other end of the screen.
-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Richard M. Stallman]

    I don't agree. Only in Ediff-mode they are annoying, otherwise I find
    them just too big ;-)

If a substantial number of people find them annoying on the text
in Ediff mode, we could do a number of things:

1. Eliminate the help-echo properties on parts of diff hunks in
Ediff mode.

2. Set it up so that they only appear for the first 4 times
that the mouse is above such text in any given Ediff mode buffer.
(That way, they would be helpful, but once the user has seen
them a few times, they will get out of the way.)

#2 would require some C code, but it won't be very hard C code, so
that is not a major reason not to do this.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

"Richard M. Stallman" <rms@gnu.org> writes:

>     I don't agree. Only in Ediff-mode they are annoying, otherwise I find
>     them just too big ;-)
>
> If a substantial number of people find them annoying on the text
> in Ediff mode, we could do a number of things:
>
> 1. Eliminate the help-echo properties on parts of diff hunks in
> Ediff mode.
>
> 2. Set it up so that they only appear for the first 4 times
> that the mouse is above such text in any given Ediff mode buffer.
> (That way, they would be helpful, but once the user has seen
> them a few times, they will get out of the way.)
>
> #2 would require some C code, but it won't be very hard C code, so
> that is not a major reason not to do this.

I would prefer the first solution, as I think that the meaning of the
font locking is quite obvious. I wouldn't want to see them the first 4
times each time I use ediff (if I understood you correctly) -- then I
would want to turn off tooltip-mode in ediff-mode only.
-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Richard M. Stallman]

    > If a substantial number of people find them annoying on the text
    > in Ediff mode, we could do a number of things:
    >
    > 1. Eliminate the help-echo properties on parts of diff hunks in
    > Ediff mode.
    >
    > 2. Set it up so that they only appear for the first 4 times
    > that the mouse is above such text in any given Ediff mode buffer.
    > (That way, they would be helpful, but once the user has seen
    > them a few times, they will get out of the way.)
    >
    > #2 would require some C code, but it won't be very hard C code, so
    > that is not a major reason not to do this.

    I would prefer the first solution, as I think that the meaning of the
    font locking is quite obvious. I wouldn't want to see them the first 4
    times each time I use ediff (if I understood you correctly) -- then I
    would want to turn off tooltip-mode in ediff-mode only.

This leads me to ask two questions:

1. What do others think?  Does (nearly) everyone agree it would be
better to get rid of these tooltips?  If so, let's do it.

2. What would you think if it were even less frequent?
For instance, in each Emacs session it would show the tooltip
only 4 times.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> Date: Sat, 22 Oct 2005 00:18:05 -0400
> Cc: emacs-devel@gnu.org
> 
>     > If a substantial number of people find them annoying on the text
>     > in Ediff mode, we could do a number of things:
>     >
>     > 1. Eliminate the help-echo properties on parts of diff hunks in
>     > Ediff mode.
>     >
>     > 2. Set it up so that they only appear for the first 4 times
>     > that the mouse is above such text in any given Ediff mode buffer.
>     > (That way, they would be helpful, but once the user has seen
>     > them a few times, they will get out of the way.)
>     >
>     > #2 would require some C code, but it won't be very hard C code, so
>     > that is not a major reason not to do this.
> 
>     I would prefer the first solution, as I think that the meaning of the
>     font locking is quite obvious. I wouldn't want to see them the first 4
>     times each time I use ediff (if I understood you correctly) -- then I
>     would want to turn off tooltip-mode in ediff-mode only.
> 
> This leads me to ask two questions:
> 
> 1. What do others think?  Does (nearly) everyone agree it would be
> better to get rid of these tooltips?  If so, let's do it.
> 
> 2. What would you think if it were even less frequent?
> For instance, in each Emacs session it would show the tooltip
> only 4 times.

First, I'm surprised that the Ediff maintainer (CC'ed) was not brought
into this thread before discussing these options.  (Michael, you may
wish to read the original complaint at
http://lists.gnu.org/archive/html/emacs-devel/2005-10/msg00093.html,
to better understand the context.)

More to the point, I'm using Ediff heavily for a long time, but until
now didn't even know it popped tooltips, perhaps because I don't move
the mouse pointer when I read the diffs.  (How many people do move the
mouse in that mode, and why?)  Consequently, I cannot possibly agree
that these tooltips ``annoy'' me.

Even for people who do move the mouse as a matter of habit when
reading the diffs, I cannot easily see why the tooltips would annoy:
they pop on the text line that is different from the one where the
mouse pointer is, so if they obscure something, it's not the part of
the text that one reads at that moment (assuming the mouse pointer
closely follows the reader's eyes).

I also don't think that these tooltips are unnecessary; I think they
might convey important information for someone who is not as fluent as
I am with using visual diff tools such as Ediff.  So I think getting
rid of the tooltips (suggested solution #1 above) is not a very good
idea.

As for suggested solution #2, I dislike it even more, because I think
that a subtly inconsistent UI is much worse than a consistent, but
slightly annoying one.

Finally, I think we could prevent the Ediff tooltips from obscuring
buffer text being read, if Ediff would pop them farther from the mouse
pointer.  Would that be a good-enough solution?

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> More to the point, I'm using Ediff heavily for a long time, but until
> now didn't even know it popped tooltips, perhaps because I don't move
> the mouse pointer when I read the diffs.  (How many people do move the
> mouse in that mode, and why?)  Consequently, I cannot possibly agree
> that these tooltips ``annoy'' me.

On w32, the mouse pointer also moves to the little ediff-frame, so
most people never see these tooltips unless they move the mouse. (One
could count this as one more reason to remove the tooltips, IMO: most
people won't see them.)

I move the mouse when a single difference region extends over more
than, say, 10 rows of text and contains many small and subtle changes.
That is quite common when writing LaTeX and editing already existing
paragraphs, followed by `M-q' to beautify the paragraph again. And if
you change a word here, move a curly brace by one word there, exchange
a LaTeX macro by another, and so on you get a very `fragmented'
difference region (that is, with `fine differences') that contains
many unrelated changes, maybe 5 changes to the content and 7 to the
markup. Then I often use the mouse to `check them one by one'.

> Even for people who do move the mouse as a matter of habit when
> reading the diffs, I cannot easily see why the tooltips would annoy:
> they pop on the text line that is different from the one where the
> mouse pointer is, so if they obscure something, it's not the part of
> the text that one reads at that moment (assuming the mouse pointer
> closely follows the reader's eyes).

But in fragmented difference regions, the tooltip changes between
being in (1) the difference region or (2) in a `fine difference'
within the current difference region, so two different tooltips pop up
all the time. That's what I don't like.

> I also don't think that these tooltips are unnecessary; I think they
> might convey important information for someone who is not as fluent as
> I am with using visual diff tools such as Ediff.  So I think getting
> rid of the tooltips (suggested solution #1 above) is not a very good
> idea.

IMO, visual diff tools are easier to use than `diff -u'. Comparing the
font locking in buffer A and buffer B explains what is meant with the
colours, even to a beginner.

Also, these tooltips are only an explanation of the font locking.
There are no special functions on mouse-1/2/3 that need to be
explained.

[...]

> Finally, I think we could prevent the Ediff tooltips from obscuring
> buffer text being read, if Ediff would pop them farther from the mouse
> pointer.  Would that be a good-enough solution?

IMO, no. As I wrote above, in difference regions with many `fine
differences', the tooltips `Difference region 1 -- current' and `A
refinement of the current difference region' alternate all the time
when hovering with the mouse over the difference region -- annoying,
no matter how far from the mouse pointer.

(If the majority of people really wants to keep those tooltips, then,
IMO, we need a variable like `font-lock-maximum-decoration' for
tooltips, so that I can use tooltips, but at a lower level of
decoration (less tooltips).)
-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Eli Zaretskii]

> From: Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de>
> Date: Tue, 25 Oct 2005 21:23:05 +0200
> 
> On w32, the mouse pointer also moves to the little ediff-frame

What do you mean by that?  I don't think the mouse pointer moves for
me on w32 unless I move it myself.  Could it be a side effect of some
customization, like using avoid.el?

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de>
>> Date: Tue, 25 Oct 2005 21:23:05 +0200
>> 
>> On w32, the mouse pointer also moves to the little ediff-frame
>
> What do you mean by that?  I don't think the mouse pointer moves for
> me on w32 unless I move it myself.  Could it be a side effect of some
> customization, like using avoid.el?

I started Emacs with `runemacs -q' now and did some ediffing: the
mouse pointer jumps to the little ediff frame, and after `q y', it
jumps back to where it was before.

GNU Emacs 21.3.1 (i386-mingw-nt5.0.2195) of 2004-03-10 on NYAUMO

What about the other things I wrote in that message? Did I convince
you?
-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Eli Zaretskii]

> From: Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de>
> Date: Thu, 27 Oct 2005 20:15:52 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de>
> >> Date: Tue, 25 Oct 2005 21:23:05 +0200
> >> 
> >> On w32, the mouse pointer also moves to the little ediff-frame
> >
> > What do you mean by that?  I don't think the mouse pointer moves for
> > me on w32 unless I move it myself.  Could it be a side effect of some
> > customization, like using avoid.el?
> 
> I started Emacs with `runemacs -q' now and did some ediffing: the
> mouse pointer jumps to the little ediff frame, and after `q y', it
> jumps back to where it was before.

It jumps to the Ediff control frame when you start Ediff, but if you
then move the mouse to some other place, it never jumps to that frame
again; you have to move it there yourself if you want, e.g., to go to
the next hunk.  At least that's how it behaves for me.

> GNU Emacs 21.3.1 (i386-mingw-nt5.0.2195) of 2004-03-10 on NYAUMO

I use the CVS version, not 21.3; perhaps something changed in the
meantime.

> What about the other things I wrote in that message? Did I convince
> you?

No.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de>
>> Date: Thu, 27 Oct 2005 20:15:52 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de>
>> >> Date: Tue, 25 Oct 2005 21:23:05 +0200
>> >> 
>> >> On w32, the mouse pointer also moves to the little ediff-frame
>> >
>> > What do you mean by that?  I don't think the mouse pointer moves for
>> > me on w32 unless I move it myself.  Could it be a side effect of some
>> > customization, like using avoid.el?
>> 
>> I started Emacs with `runemacs -q' now and did some ediffing: the
>> mouse pointer jumps to the little ediff frame, and after `q y', it
>> jumps back to where it was before.
>
> It jumps to the Ediff control frame when you start Ediff, but if you
> then move the mouse to some other place, it never jumps to that frame
> again;

I tried it again in 21.3 with `runemacs -q', and I moved the mouse
pointer off the ediff frame, pressed SPC to jump to the next
difference, and it jumped back to the ediff frame. It did this after
each SPC. I didn't know this. It seems that you don't see this
behaviour, if I understand you correctly. Why is this different for
you?

> you have to move it there yourself if you want, e.g., to go to the
> next hunk. At least that's how it behaves for me.
>
>> GNU Emacs 21.3.1 (i386-mingw-nt5.0.2195) of 2004-03-10 on NYAUMO
>
> I use the CVS version, not 21.3; perhaps something changed in the
> meantime.

I saw the same in a CVS version (about 1 week old, not compiled by me
and not started with `-q').

>> What about the other things I wrote in that message? Did I convince
>> you?
>
> No.

That's bad. ;-)

My arguments were

1. "the font locking explains what is meant",
2. "fragmented difference regions with
   tooltips-all-the-time-popping-up are annoying" and
3. "no special mouse functions that need to be explained".

Yours were

1. "they contain important information for users that don't use ediff
   regularly" and
2. "they don't obscure the text that one reads at the moment".

IMO, my argument 2 really suggests to get rid of tooltips.
-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Eli Zaretskii]

> From: Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de>
> Date: Thu, 27 Oct 2005 23:05:32 +0200
> 
> > It jumps to the Ediff control frame when you start Ediff, but if you
> > then move the mouse to some other place, it never jumps to that frame
> > again;
> 
> I tried it again in 21.3 with `runemacs -q', and I moved the mouse
> pointer off the ediff frame, pressed SPC to jump to the next
> difference, and it jumped back to the ediff frame. It did this after
> each SPC. I didn't know this. It seems that you don't see this
> behaviour, if I understand you correctly. Why is this different for
> you?

Because I didn't type SPC, since you never mentioned it before.

When I try SPC now, it does move the mouse pointer to the Ediff frame,
but only if the mouse is not on another Emacs frame (or on a window
that belongs to another Windows program).  So I'm left wondering why
would you have the mouse outside any frame at this point?  If I
understood you correctly, we are discussing a situation when a user
moves the mouse across the differences (displayed in an Emacs frame in
two adjacent windows) while she reads the differences.

> >> What about the other things I wrote in that message? Did I convince
> >> you?
> >
> > No.
> 
> That's bad. ;-)
> 
> My arguments were

I understood your arguments the first time, they just don't convince
me.

But I'm not the Ediff maintainer, so it's just my personal opinion.
Michael, are you there? can you comment on the issues raised in this
thread regarding Ediff's use of tooltips?

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Eli Zaretskii <eliz@gnu.org> writes:

> When I try SPC now, it does move the mouse pointer to the Ediff
>frame, but only if the mouse is not on another Emacs frame (or on a
>window that belongs to another Windows program).

I didn't investigate this -- when I use ediff, the mouse is always on
an Emacs frame: either the Ediff frame, or the main Emacs frame.

>So I'm left wondering why would you have the mouse outside any frame
>at this point?

I don't know -- did I give the impression that I have the mouse
outside any frame?

>If I understood you correctly, we are discussing a situation when a
>user moves the mouse across the differences (displayed in an Emacs
>frame in two adjacent windows) while she reads the differences.

Exactly. I do `M-x ediff-buffers RET RET RET' -> the Ediff-frame pops
up and gets the `focus', I navigate with SPC and Backspace from
difference region to difference region, and in large difference
regions, I `tick off' the fine differences in the newer buffer by
moving the mouse from fine difference to fine difference *in the
current difference region*.

> I understood your arguments the first time,

I assumed that ;-)

> they just don't convince me.

Okay.
-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Eli Zaretskii]

> From: Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de>
> Date: Thu, 03 Nov 2005 18:37:15 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > When I try SPC now, it does move the mouse pointer to the Ediff
> >frame, but only if the mouse is not on another Emacs frame (or on a
> >window that belongs to another Windows program).
> 
> I didn't investigate this -- when I use ediff, the mouse is always on
> an Emacs frame: either the Ediff frame, or the main Emacs frame.
> 
> >So I'm left wondering why would you have the mouse outside any frame
> >at this point?
> 
> I don't know -- did I give the impression that I have the mouse
> outside any frame?

If the mouse is not outside any frame, I cannot reproduce what you
describe: my mouse pointer doesn't move when I press SPC.  So some
other factor must be at work here.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Christian Schlauer]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de>
>> Date: Thu, 03 Nov 2005 18:37:15 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > When I try SPC now, it does move the mouse pointer to the Ediff
>> >frame, but only if the mouse is not on another Emacs frame (or on a
>> >window that belongs to another Windows program).
>> 
>> I didn't investigate this -- when I use ediff, the mouse is always on
>> an Emacs frame: either the Ediff frame, or the main Emacs frame.
>> 
>> >So I'm left wondering why would you have the mouse outside any frame
>> >at this point?
>> 
>> I don't know -- did I give the impression that I have the mouse
>> outside any frame?
>
> If the mouse is not outside any frame, I cannot reproduce what you
> describe: my mouse pointer doesn't move when I press SPC.  So some
> other factor must be at work here.

You mean "If the mouse is inside any frame, I cannot reproduce what
you describe"?

I tried it again with "GNU Emacs 21.3.1 (i386-mingw-nt5.0.2195) of
2004-03-10 on NYAUMO", started with `runemacs -q' [1], and pressing
SPC in ediff-mode always moves the mouse back to the little ediff
frame, no matter if the mouse is over an Emacs frame or an underlying
Thunderbird frame or the ediff frame.

(Another question: Why are you interested in the mouse pointer jumps?
Do you suspect a bug somewhere? I ask because I am much more
interested in getting rid of the tooltips and I can't see where
exactly you are trying to get.)

Footnotes:
[1] I need to load site-start.el because that is where I tell Emacs
    where the Cygwin binaries (i.e., diff) are -- there is definitely
    no mouse-stuff in my site-start.el

-- 
Christian Schlauer

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Eli Zaretskii]

> From: Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de>
> Date: Fri, 04 Nov 2005 18:57:17 +0100
> 
> > If the mouse is not outside any frame, I cannot reproduce what you
> > describe: my mouse pointer doesn't move when I press SPC.  So some
> > other factor must be at work here.
> 
> You mean "If the mouse is inside any frame, I cannot reproduce what
> you describe"?

Yes.

> I tried it again with "GNU Emacs 21.3.1 (i386-mingw-nt5.0.2195) of
> 2004-03-10 on NYAUMO", started with `runemacs -q' [1], and pressing
> SPC in ediff-mode always moves the mouse back to the little ediff
> frame, no matter if the mouse is over an Emacs frame or an underlying
> Thunderbird frame or the ediff frame.

Doesn't happen to me, but I don't use Thunderbird.

> (Another question: Why are you interested in the mouse pointer jumps?

Because you seem to describe a behavior I don't see on my Windows
machine.  What I see causes the tooltips to pop quite rarely, so they
don't annoy me.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Kim F. Storm]

"Richard M. Stallman" <rms@gnu.org> writes:

>     > 1. Eliminate the help-echo properties on parts of diff hunks in
>     > Ediff mode.

> 1. What do others think?  Does (nearly) everyone agree it would be
> better to get rid of these tooltips?  If so, let's do it.

IMO, it is ok to drop them.

>
> 2. What would you think if it were even less frequent?
> For instance, in each Emacs session it would show the tooltip
> only 4 times.

That's unnecessarily complicated IMO.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Luc Teirlinck]

   For instance, the menu-bar item

     Visit New File

   has the tooltip

     Read and create a file or edit it

   Does the tooltip really impart any information that the item
   doesn't?

Even in this instance, the answer is yes, it does, but not as clearly
as it should.  "Visit New File" is confusing, because that is not what
the menu item does.  It runs `C-x C-f'.  In at least one other editor
(gedit) the `File->New' menu item _always_ creates a _new_ file
and asks you for a name when you want to save it.  It is somewhat
analogous to `C-x b' except that it always creates _new_ buffers
"Untitled 1", "Untitled 2" and so on, without prompting the user for a
buffer name (except on saving).

Hence one _definitely_ needs the help echo and it should even be more
explicit.  What about changing it to:

"Create a new file, or read an existing file, and edit it."

I believe however, that the change from "Open File" running `C-x C-f'
in 21.3 and earlier to the present "Visit New File" running `C-x C-f'
and "Open File" running a variant of `C-x C-f' with different
minibuffer completion must have been due to a discussion with a less
experienced Emacs users, where once again the participants in the
discussion completely misunderstood each other.  The change makes the
_names_ in the File menu more similar to the _names_ in less advanced
editors, but since the _functionality_ is very different, I doubt that
this is an improvement.  The fact that these two menu items do nearly
the same thing and have very different names is quite confusing too.
What is the difference between visiting a file and opening a file?
It also has the disadvantage that "Open File" means something
different depending on the Emacs version, again with the possibility
of confusing people.

What about changing the item names "Visit New File" into "Open New or
Existing File" and "Open File" into "Open Existing File".

That makes it clear that the second is a specialization of the first.

Sincerely,

Luc.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Richard M. Stallman]

    What about changing the item names "Visit New File" into "Open New or
    Existing File" and "Open File" into "Open Existing File".

I think the existing names are good.
I do not want to consider changing them again.

    Hence one _definitely_ needs the help echo and it should even be more
    explicit.  What about changing it to:

    "Create a new file, or read an existing file, and edit it."

That is rather long, but I think

    "Create a file, and edit it"

or

    "Specify new file's name, to edit the file"

would make more sense than the current help-echo.

Just because this command CAN access an existing file is no reason we
must design the help-echo to mention that.  A complete description of
the command's range of possible behavior is not its purpose.  Its
purpose is to steer users in the right direction.

In general, completeness is a mistaken goal in writing documentation.
Covering all possible ways of invoking a function, or all possible
values a variable might have, is usually just wasteful--of our time,
and the user's time.  We only want to describe the cases that *should
be used*.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Luc Teirlinck]

Richard Stallman wrote:

       "Specify new file's name, to edit the file"

   would make more sense than the current help-echo.

   Just because this command CAN access an existing file is no reason we
   must design the help-echo to mention that.

Explaining the strange stuff that happens if the user tries to type in
a file name containing question marks or spaces (as newbies often do)
is a good reason however.  Also, the user is probably going to worry
about what happens if he inadvertently enters the name of an existing
file.  Another good reason to tell him.  Also, people often use the
menu bar just to remember key sequences.  "Visit New File" is not the
correct description of `C-x C-f' which appears right next to it.

Of course, there is another way to solve these three problems.  Why
not bind that menu bar item to a command that is like find-file, but
disables file name completion (eliminating the nasty ?-space surprises).
Ideally, if the user specifies the name of an existing file (which was
probably unintentional or he would have selected "Open File", not
"Visit New File"), tell him that the file already exists and ask him
whether he really wants to open it or whether he wants to edit the name.

With these changes the name "Visit New File" and the new help echo you
propose above would actually be accurate.

Sincerely,

Luc.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Richard M. Stallman]

    Explaining the strange stuff that happens if the user tries to type in
    a file name containing question marks or spaces (as newbies often do)
    is a good reason however.

There is no room for so much explanation in a tooltip.  Sorry.
However, it could be that we should turn off wildcards for menu items.
If wildcards have the effect of confusing the beginners who use menus,
that may be a desirable change.

      "Visit New File" is not the
    correct description of `C-x C-f' which appears right next to it.

This is not worth thinking about.

The Emacs commands and the usual practices of menu bars are
conceptually incompatible.  No matter how we try fit them together,
there will be various such minor discrepancies.  Anything we do to
remove some will create others.  It is a waste of time to discuss it.

Please drop this issue.

Re: Better default values for tooltip padding and `tooltip-hide-delay'?

[Richard M. Stallman]

I will change some of these parameters.  Thanks.