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: [doug@bagley.org: Re: mouse-1-click-follows-link in diredsurprising]
Date: Tue, 4 Jul 2006 10:40:24 -0700	[thread overview]
Message-ID: <EIENLHALHGIMHGDOLMIMMEFCCJAA.drew.adams@oracle.com> (raw)
In-Reply-To: <E1FxkQz-0001xZ-Ty@fencepost.gnu.org>

[-- Attachment #1: Type: text/plain, Size: 4335 bytes --]

    Bagley argues that the file names in dired should be
    highlighted as links so as to avoid surprise.
    What do others think?

If by that you mean `face' highlighting, in addition to `mouse-face',
definitely *not*.

I've said before, and I'll say again:

There are buffers (Dired, *Buffer List*, *grep*, *Occur*,...) that are
link-dense (or potentially so). In addition, the text that is linked is
regular in appearance - for example, a table, each of whose entries is
linked. In most cases (all of the cases just cited), even if the table has
more than one column, there is only one link per row.

For such buffers:

1) We should *not* highlight the links (except via mouseover). The links are
known or predictable by virtue of the regularity of their positions.
Highlighting the links in such a buffer hinders, it does not help,
orientation and navigation.

2) When tabular (regular) buffers have only one link per row, regardless of
how many table columns there are, we should put the *mouse-face on the
entire row*, not just one of the columns (e.g. file name in Dired). That
lets you click anywhere on the row. You can keep your eye on a particular
column, because that is what you want to scan/read, and yet you can click
anywhere on the row (usually a single line). There is no need to put the
mouse exactly where you are looking. And you can move the mouse up and down,
highlighting different rows, without worrying about keeping the mouse within
a column. In particular, you can move the mouse vertically at the right
edge, without having mouseover highlighting skip over short rows.

The attached screenshot of Dired shows what I mean: you can click anywhere
on the row, and there is no `face' highlighting of links (there is only
`mouse-face' highlighting).

Full-row mouse highlighting also helps with visual alignment, when columns
of interest are far apart or are separated by empty entries. The principal
here is that of using a ruler with a parts list or catalog: the highlighting
helps you see everything that is in the same row. When a table row is
multi-line this is even more important: the highlighting shows what
constitutes a row.

Note that it is not only the density of links that determines whether the
above guidelines apply. The buffer must also be regular, so that users
already know where the links are. The link density causes the user to
discover the links (the mouse inevitably hits a link, showing it by
mouse-face and finger pointer). The tabular regularity lets the user predict
the link positions. A buffer that is dense in links but not regular -
Customize, perhaps - does not fit the guidelines: its links should be
highlighted with `face', not only `mouse-face', to help users find them.

Also, a buffer such as Dired that is tabular (regular) with a single link
per row is a candidate for these guidelines, even if it doesn't appear to be
very link-dense currently (with only one column linked). IOW, applying the
second guideline will make buffers like Dired link-dense. This increases
usability, (letting you click anywhere on a row and use mouseover to
highlight a row).

What about tabular data that has more than one link per row?
`list-faces-display' is an example of this. In this case, the first
guideline applies, but the second does not. Each linked entry (i.e. in each
column) should have mouse-face highlighting, but not face highlighting (it
DTRT currently).

If a buffer happened to have multiple columns, more than one of which is
linked, some adjacent columns could be mouse-face highlighted together, for
convenience. IOW, it could be convenient in some cases to join multiple
adjacent columns wrt linking and mouse-face. Imagine, for instance, if Dired
had an additional first column "More Info" that linked a Dired entry to a
buffer of additional information about the file. In that case, a row could
have two links (with mouse-face): one for column More Info and the other for
all of the other columns combined (~guideline #2).

I've never been able to convince anyone else on this score. Trying again...

Please don't `face' highlight links in Dired; mouseover is enough.

P.S. To come back to the OP - `mouse-1-click-follows-link' is a nuisance for
link-dense buffers (whether regular or not). I turn it off (nil). IMO, it
should be off by default in such buffers.

[-- Attachment #2: dired-mouseover.jpg --]
[-- Type: image/jpeg, Size: 53552 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

  parent reply	other threads:[~2006-07-04 17:40 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-04 12:55 [doug@bagley.org: Re: mouse-1-click-follows-link in dired surprising] Richard Stallman
2006-07-04 13:18 ` Chong Yidong
2006-07-04 17:40 ` Drew Adams [this message]
2006-07-05  2:24   ` [doug@bagley.org: Re: mouse-1-click-follows-link in diredsurprising] Miles Bader
2006-07-05  3:42     ` Dired coloring and other conveniences Drew Adams
2007-07-02  5:42       ` dired-details: show/hide file details in Dired Drew Adams
2007-07-02 13:04         ` Mathias Dahl
2007-07-02 13:46           ` Drew Adams
2007-07-02 20:50             ` Mathias Dahl
2007-07-02 21:04               ` Drew Adams
2007-07-02 14:02           ` add directory selection to the "compile" command lucatrv
2007-07-02 15:55             ` Denis Bueno
2007-07-04 18:38               ` lucatrv
2007-07-02 14:04         ` dired-details: show/hide file details in Dired Rob Giardina
2007-07-02 22:39           ` Richard Stallman
2007-07-02 22:53             ` Drew Adams
2007-07-02 23:01               ` Rob Giardina
2007-07-03  1:17               ` Stefan Monnier
2007-07-03  5:44                 ` Drew Adams
2007-07-05 13:41                   ` Stefan Monnier
2007-07-04  3:43               ` Richard Stallman
2007-07-04  3:53                 ` Rob Giardina
2007-07-05  1:30                   ` Richard Stallman
2007-07-04  5:51                 ` Drew Adams
2007-07-04 10:53                   ` Robert J. Chassell
2007-07-04 14:57                     ` Drew Adams
2007-07-04 17:10                     ` Robert J. Chassell
2007-07-04 20:00                       ` Drew Adams
2007-07-04 21:57                         ` Robert J. Chassell
2007-07-05  1:31                       ` Richard Stallman
2007-07-05  6:58                         ` Drew Adams
2007-07-05 11:38                           ` Robert J. Chassell
2007-07-05 20:34                             ` Richard Stallman
2007-07-05 20:49                               ` Drew Adams
2007-07-05 21:35                                 ` Robert J. Chassell
2007-07-08 22:24                                 ` Richard Stallman
2007-07-05 20:34                           ` Richard Stallman
2007-07-05  1:30                   ` Richard Stallman
2007-07-05  2:40                     ` Rob Giardina
2007-07-05 20:34                       ` Richard Stallman
2007-07-05  1:30                   ` Richard Stallman
2007-07-05  3:22                     ` Rob Giardina
2007-07-05 20:34                       ` Richard Stallman
2006-07-06 13:32     ` [doug@bagley.org: Re: mouse-1-click-follows-link in diredsurprising] Richard Stallman
2006-07-06 21:41       ` Miles Bader
2006-07-08 20:57         ` Richard Stallman
2006-07-08 21:24           ` Luc Teirlinck
2006-07-09 19:02             ` Richard Stallman
2006-07-08 21:35           ` Luc Teirlinck
2006-07-08 22:15           ` Luc Teirlinck
2006-07-09 19:02             ` Richard 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

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

  git send-email \
    --in-reply-to=EIENLHALHGIMHGDOLMIMMEFCCJAA.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.