Re: mouse-1-click-follows-link

[Daniel Brockman <daniel@brockman.se>]

"Drew Adams" <drew.adams@oracle.com> writes:

> Here's what I said before: 

[...]

>     4. The default value for buffers that are dense with hot spots
>     (e.g. Dired, grep, compilation) and for which users will likely
>     want to set point occasionally should be `double' (double-click
>     follows link).
>     
>     5. The default value for buffers that are dense with hot spots,
>     but for which users don't need to set point at all (eg. Buffer
>     List) should be 100 ms (fast click follows link). (There are
>     probably few such standard buffers.)
>
> (1) I've changed my opinion on #4 and #5. By default, the value
> should be `nil' everywhere: mouse-1 should *not* follow links.
>
> Reasons:
>
> a. mouse-2 as yank is not needed on a link, so mouse-2 is a
>    perfect choice for following links. That was surely behind the
>    original design, and it remains the best argument for mouse-2.
>    Having mouse-1 sometimes follow a link and sometimes set point
>    (e.g. via different delays), in the same buffer, always involves
>    some UI tradeoffs (fast-click, slow-click, double-click).
>    That's OK, but it should not be the _default_ behavior anywhere.

Why does it matter what the ``default'' behavior is?  Buffers don't
contain links by ``default.''

[...]

> c. Newbies will discover mouse-2 for links soon enough. They will
>    need to discover it for yanking, anyway; it is no harder to learn
>    it for linking.

Except that mouse-2 is used for yank in almost all other applications
that run under X, so users will already be familiar with this binding.

I realize that Windows users are another story.

>    Up front, we should:
>
>    (i)   Tell them about mouse-2 for linking.
>    (ii)  Suggest they try it for a while ("try it; you'll like it").
>    (iii) Tell them they can change it: mouse-1-click-follows-link.

Or we could just make the obvious binding the default (which we have,
of course, already done).

Don't get me wrong:  I don't have anything against trying to push
users into changing their preferences to the better.  It's just that I
don't consider this preference to be better.

However, I'm all for making the Dvorak input method the default and
telling users what you suggested: ``try it; you'll like it!''

> d. It is not difficult to go back and forth between mouse-2 for
>    linking in Emacs and mouse-1 in other apps.

That's a totally subjective statement.  Here, I'll make another:

It _is_ difficult to go back and forth between mouse-2 for linking in
Emacs and mouse-1 in other apps.

>    We all do it all the time.

So what?  You've had years to get used to it.  I do lots of things all
the time that I wouldn't expect a random person to be comfortable with
doing the way I do, yet they aren't ``difficult.''

>    The argument that people are "used to mouse-1 for linking" is
>    countered by c plus d - there are two aspects to it.

It isn't countered by c (because people who use X are already familiar
with mouse-2 for yanking), and it isn't countered by d (because the
fact that using another binding is not difficult once you're used to
it doesn't change the fact that people are already used to mouse-1).

So I don't see how the argument is countered by ``c plus d.''

> (2) As I said in October, and which led to Kim coming up with using
> mouse-1 for linking, we should change the finger-pointer cursor over
> links. The index-finger pointer _suggests_ using mouse-1.

Actually, that's another good reason for using mouse-1.  The only good
ways to indicate that something is a link is to (a) underline the
text, and (b) change the pointer to a hand when it hovers the text.
Both of these also strongly indicate that mouse-1 follows the link.

So what do you suggest we use to indicate that something is a link
that you follow using mouse-2?  Overlining the text and changing the
pointer to a foot?

[...]

> My last point:
>
> (3) We should make decisions about the extent (and placement) of hot
> zones (links, buttons) based on other criteria, besides a tradeoff
> between setting point and following a link - that is a red herring.

Only if we switch back to using mouse-2 for following links.

> We should design hot zones assuming that there is no problem setting
> point: assume that mouse-1 sets point and mouse-2 activates
> hot spots.

This is a hypothetical discussion, based on the assumption that we
will change the binding for following links back to mouse-2.

The equivalent discussion based upon reality would assume that some
people will be using mouse-1, and others will be using mouse-2.

> So, in particular, I repeat that full-line links are better for
> buffers like grep, compilation, and Dired, because of the alignment
> aid and ease of use they provide.

I don't understand the alignment thing.  What is that all about?

> If Emacs doesn't do this by default, it should at least provide an
> easy way for users to get this behavior.

That sounds reasonable.

> To repeat:
>
>     8. Users should be able to have full-line hot zones for buffers
>     that are essentially lists of links. This includes grep,
>     compilation, and Dired. RMS has apparently decided to reduce the
>     hot-zone size for grep. I prefer full-line links. It would be
>     good for users to be able to customize this, regardless of the
>     default behavior.
>     
>     IOW, because of the recent move to mouse-1 following links (even
>     potentially), we are now losing full-line links in grep. People
>     accidentally followed links (me too), so the hot zones are now
>     being reduced to alleviate this problem.
>     
>     I don't agree with that solution to the problem, but all I would
>     ask for is a way for users to get back the full-line link
>     behavior. Mouse-1 is extremely customizable now via
>     mouse-1-click-follows-links, but the hot-zone extent is not
>     customizable at all, without rewriting the grep/compile code.

Would it be enough if every such mode had a local setting for this?

-- 
Daniel Brockman <daniel@brockman.se>