From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: follow-link not on mouse-face
Date: Fri, 21 Oct 2005 22:23:14 -0700 [thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICEEMICNAA.drew.adams@oracle.com> (raw)
In-Reply-To: <E1ETApk-0001iV-Tv@fencepost.gnu.org>
> I think it is a mistake to put the `follow-link' property
> on text areas that have no mouse-face=highlight. The
> `highlight' face is a good warning that mouse-1 click will
> try to follow links, and a missing `highlight' face
> indicates that it is always safe to click mouse-1
> to relocate point.
That is a valid point.
Well, I'm not sure, I'd expect mouse-1 to have the exact
same effect as mouse-2 no matter where I'm clicking...
That is a valid point too.
So maybe the mouse face should cover the whole line.
Or perhaps -- though this could take more work -- the line number
should also highlight, but separately. Either one would achieve both
of the goals above.
So I think the question is not whether to make mouse-1 to have the
exact same effect as mouse-2, but why mouse-2 sensitive areas are
bigger than areas with mouse-face=highlight in the *Occur* buffer.
I recall that the reason for that was to reduce flicker (especially
on large context areas in the *Occur* buffer).
I think part of the reason may have been to help show the boundary
between the line number and the line contents. That is why I suggest
that each of these parts of the line could highlight separately.
I may be mistaken, but my recollection was that people argued that:
- Highlighting the whole line was too garish and interfered with
readability. Juri mentions flicker too, which is perhaps related.
- People accidentally followed links by clicking mouse-1, trying to set
point.
The second point, in particular, was I think the reason we reduced the hot
zone from a full-line link.
I argued for highlighting the whole line (for ease of use with the mouse and
to help visual alignment, as in using a ruler with a phone book), but doing
so with only (mouseover) underlining, to avoid the problem of heavy-handed
highlighting (flicker and TOO MUCH NOISE). That is, do not use underlining
for the link text, but underline it when the mouse is on the link. I would
still argue this.
Here is some of the earlier exchange:
A common practice used on Web pages with tables or lists that
are dense with similar links in similar places is to _not_
use underlining.
That is, in a long list where each list item is a link, and
where the list is the main thing on the page, underlining is
often foregone because it is unnecessary and would be
distracting. Users can easily figure out that each line is a
link - mouseover anywhere within the list (the page)
highlights a link.
If compile and grep buffers had full-line links, the links
would be easier to access, they would help with visual
alignment (like using a ruler in a parts catalog), and there
would be no need to underline them. Mouseover highlighting
would suffice, and the mouseover highlighting could itself
be underlining, to reduce noise.
I see. However, we don't want mouse-1 to be active on the whole line,
for other reasons. I think the current set of places where mouse-1 is
active is the right set. The question that remains is only whether
to underline those places.
In the current discussion, what is the reason for a distinction between the
line number and the rest of the line? Richard suggests that part of the
reason is to show the boundary between the line number and the rest. I don't
see that as a problem or recall that being mentioned before.
With only mouse-2 to follow links, I don't think there was a call to reduce
the link size. Is there a mouse-2 behavior difference clicking one or the
other?
I think the main reason we reduced the hot zone was because you might want
to set point with mouse-1, and it was thought that reducing the size of the
mouse-1 link would cut down on the mistaken-follow problem.
Either we have a good solution for dealing with mouse-1 in general - being
able to either set point (even in link text) or follow a link - or we do
not. If we do, then I don't see the point of the extra "help" in this regard
offered by treating line numbers differently. If we don't, then let's fix
that design, rather than trying to give it a little extra help here and
there.
next prev parent reply other threads:[~2005-10-22 5:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-21 11:59 follow-link not on mouse-face Juri Linkov
2005-10-21 13:39 ` Kim F. Storm
2005-10-21 13:47 ` Romain Francoise
2005-10-21 13:58 ` Romain Francoise
2005-10-21 16:02 ` Juri Linkov
2005-10-22 4:18 ` Richard M. Stallman
2005-10-22 5:23 ` Drew Adams [this message]
2005-10-23 4:42 ` Richard M. Stallman
2005-10-23 5:34 ` Drew Adams
2005-10-22 12:14 ` Romain Francoise
2005-10-23 4:42 ` Richard M. Stallman
2005-10-23 8:44 ` David Kastrup
2005-10-23 10:19 ` Romain Francoise
2005-10-24 1:00 ` Richard M. Stallman
2005-10-24 6:22 ` Romain Francoise
2005-10-24 23:43 ` Juri Linkov
2005-10-25 6:01 ` Romain Francoise
2005-10-25 14:26 ` Drew Adams
2005-10-25 15:57 ` David Kastrup
2005-10-25 20:27 ` Richard M. Stallman
2005-10-25 20:54 ` Romain Francoise
2005-10-25 20:59 ` Juri Linkov
2005-10-27 1:31 ` Richard M. Stallman
2005-10-27 18:22 ` Romain Francoise
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=DNEMKBNJBGPAOPIJOOICEEMICNAA.drew.adams@oracle.com \
--to=drew.adams@oracle.com \
/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).