RE: mouse-1-click-follows-link

[Drew Adams]

Summary: 

(1) mouse-1-click-follows-link: it should be `nil' everywhere. (I've
    changed my opinion.)

(2) We should change the link mouseover pointer.

(3) Hot-zone extent should not be based on a supposed tradeoff between
    setting point and following a link. That's a red herring.

Reasons below. Here's where we are now:

    mouse-1-click-follows-link is nicely defined to satisfy everyone,
    I think.  You can turn off mouse-1 link sensitivity completely or
    activate it on: 1) short (fast) click, 2) long (slow) click, or 3)
    double-click. Good job.
    
    What we've *not* come to agreement on yet:
    
    1) Whether the behavior should always be the same in each buffer
    or should possibly vary by buffer. If the latter, should this be
    user-changeable (e.g.  local values) or not?
    
    2) What the default value should be. If we allow local values,
    this means both a) the default global value and b) the default
    local values for different categories of standard buffers
    (e.g. those dense with links, like Dired, vs those sparse with
    links, like Info).
    
    Our options include `nil' (mouse-1 doesn't follow links at all),
    +integer (fast click follows link), -integer (slow click follows
    link), and `double' (double-click follows link).
     
Here's what I said before: 
    
    My opinion:
    
    1. Users should be able to have different behaviors in different
    buffers, in this regard.
    
    2. The global (default) value should be `nil': mouse-1 should be
    insensitive to links by default.

    3. The default value for buffers that are sparse with hot spots
    (e.g. Info, Help, Customize) should be 100 ms (fast click follows
    link).
    
    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.

b. With mouse-1-click-follows-links, especially if we allow local
   values, everyone can do what he wants, wherever he wants. This
   includes people who use mice without mouse-2. IOW, even if mouse-2
   is the default for links, users can choose instead to use mouse-1
   in various ways for linking. Previously, users could not easily
   switch to mouse-1; now they can.

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. 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.

d. It is not 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. The argument that people are "used to mouse-1 for linking" is
   countered by c plus d - there are two aspects to it.

(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.

    That pointer is commonly used by Web browsers to indicate that the
    pointer is over a hyperlink or an action button, so that's
    presumably the reason it is now used in Emacs for the same thing.
    
    However, in common Web browsers, the mouse button to activate 
    such a link or button is mouse-1, not mouse-2. What bugs me is 
    that the index-finger pointer suggests to me to use mouse-1, 
    because the index finger (wired, in my head, to mouse-1) is the 
    one doing the pointing.

RMS and Kim both thought I was asking to use mouse-1 for links. I was
only suggesting to change the mouseover pointer. RMS wrote:

    Mouse-1 can't do that.  Mouse-1 in Emacs is a general Emacs
    command that is meanigful anywhere in the buffer.

    Anyway, this is not the time to change features.

Kim came up with a patch to use mouse-1 for links, and we were off and
running. I wrote:

   > My point was not that using mouse-2 is not good. I think mouse-2
   > should remain the way to click links and buttons in Emacs...

But we went with mouse-1 for links, because it is "common user
interface practice" and some people don't have a mouse-2.

So far: 1) Let's use mouse-2 for links, by default. 2) Let's change
the link pointer from an index-finger. 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.
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.

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. If Emacs doesn't do this by default,
it should at least provide an easy way for users to get this
behavior. 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.