all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.

  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

* 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 external index

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

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