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

[Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de>]

"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