unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de>
Subject: Re: Better default values for tooltip padding and `tooltip-hide-delay'?
Date: Tue, 25 Oct 2005 21:23:05 +0200	[thread overview]
Message-ID: <djm0mc$6g4$1@sea.gmane.org> (raw)
In-Reply-To: u4q79q0gd.fsf@gnu.org

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

  reply	other threads:[~2005-10-25 19:23 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-17 15:10 Better default values for tooltip padding and `tooltip-hide-delay'? Christian Schlauer
2005-07-17 19:30 ` Drew Adams
2005-07-18  6:43   ` Frank Schmitt
2005-09-30 17:04     ` Christian Schlauer
2005-09-30 21:16       ` Jason Rumney
2005-09-30 23:03         ` Frank Schmitt
2005-10-01 13:17           ` Jason Rumney
2005-10-01 13:49           ` Luc Teirlinck
2005-10-03 16:27           ` Kevin Rodgers
2005-10-01  1:19         ` Daniel Brockman
2005-10-01  8:08           ` Andreas Schwab
2005-10-01 14:38             ` Daniel Brockman
2005-10-01 17:19               ` Andreas Schwab
2005-10-01 21:25                 ` Daniel Brockman
2005-10-01 22:33                   ` Andreas Schwab
2005-10-02 14:43             ` Stefan Monnier
2005-10-02 15:04               ` Andreas Schwab
2005-10-03 18:49               ` Christian Schlauer
2005-10-03 20:17                 ` Lennart Borgman
2005-10-03 22:22                 ` Jason Rumney
2005-10-04 18:14                   ` Christian Schlauer
2005-10-04 21:27                     ` Jason Rumney
2005-10-05 17:30                       ` Christian Schlauer
2005-10-07 10:30                         ` Christian Schlauer
2005-10-05 22:45                       ` Richard M. Stallman
2005-10-04  5:02                 ` Richard M. Stallman
2005-10-01 23:25         ` Richard M. Stallman
2005-10-03 18:35         ` Christian Schlauer
2005-10-03 20:32           ` Stefan Monnier
2005-10-04 18:35             ` Christian Schlauer
2005-10-04 19:47               ` Stefan Monnier
2005-10-04 18:51           ` Richard M. Stallman
2005-10-04 20:05             ` Christian Schlauer
2005-10-05 17:32               ` Christian Schlauer
2005-10-05 18:11                 ` David Kastrup
2005-10-04 21:38             ` Jason Rumney
2005-10-04 23:11               ` Andreas Schwab
2005-10-04 23:15                 ` Lennart Borgman
2005-10-05  8:10                   ` Andreas Schwab
2005-10-05 17:34                     ` Christian Schlauer
2005-10-05 22:45               ` Richard M. Stallman
2005-10-08 16:49                 ` Christian Schlauer
2005-10-09  3:24                   ` Stefan Monnier
2005-10-09 18:16                   ` Richard M. Stallman
2005-10-09 21:32                     ` Drew Adams
2005-10-09 21:42                       ` Lennart Borgman
2005-10-10 15:14                       ` Stefan Monnier
2005-10-11 19:06 ` Christian Schlauer
2005-10-11 20:48   ` Chong Yidong
2005-10-11 23:20     ` Luc Teirlinck
2005-10-12 21:33       ` Christian Schlauer
2005-10-12 21:43         ` Lennart Borgman
2005-10-13  0:51         ` Luc Teirlinck
2005-10-14 16:24           ` Christian Schlauer
2005-10-13 20:10         ` Richard M. Stallman
2005-10-21 17:30           ` Christian Schlauer
2005-10-22  4:18             ` Richard M. Stallman
2005-10-22 11:02               ` Eli Zaretskii
2005-10-25 19:23                 ` Christian Schlauer [this message]
2005-10-26  6:39                   ` Eli Zaretskii
2005-10-27 18:15                     ` Christian Schlauer
2005-10-27 19:17                       ` Eli Zaretskii
2005-10-27 21:05                         ` Christian Schlauer
2005-10-28  7:34                           ` Eli Zaretskii
2005-11-03 17:37                             ` Christian Schlauer
2005-11-04 10:30                               ` Eli Zaretskii
2005-11-04 17:57                                 ` Christian Schlauer
2005-11-04 21:34                                   ` Eli Zaretskii
2005-10-22 23:07               ` Kim F. Storm
2005-10-11 23:46     ` Luc Teirlinck
2005-10-13  4:53       ` Richard M. Stallman
2005-10-14  4:02         ` Luc Teirlinck
2005-10-14 17:37           ` Richard M. Stallman
2005-10-13  4:53   ` Richard M. Stallman

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to='djm0mc$6g4$1@sea.gmane.org' \
    --to=cs-muelleimer-rubbish.bin@arcor.de \
    --cc=cs-usenet@arcor.de \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).