RE: mouse-1-click-follows-link

["Drew Adams" <drew.adams@oracle.com>]

     > > Some like grep, seem to cover a lot of the buffer.  I'm not saying
     > > that you can't get round it, just that it requires thought.
     >
     > Good point.  I'm much less sure that it's good in the case of grep.
     > Maybe it could work to put a little jump button next to each entry,
     > instead of using each whole line as a link?  Though that wouldn't be
     > good for keyboard users...  What if there was a button for clicking,
     > but you could also press RET anywhere on a line to follow the link?

    In the compilation buffer mouse-face (and therefore mouse-1) only works
    on the file and line number while mouse-2 and RET work for the
    whole line.

    It would help if grep also worked this way.

I disagree. My opinion:

1) mouse-1, RET, and mouse-2 should all behave similarly. What's good for
mouse-2 is good for mouse-1 too. The challenge is to find the right default
behavior (trade-off/compromise).

2) The entire line should be the hot zone (no "button"). Makes it very easy
to scan lines and align text anywhere on the line with the proper hot zone.
No need for your eye to move between the text (anywhere on the line) and the
hot zone.

3) The grep behavior (full-line hot zone) should hold also for the
compilation buffer (compilation and grep should behave similarly).

4) mouse-1 should follow links by default, for the reasons others have given
(even though I, myself, might choose to turn this off).

5) The delay for mouse-1 to set point should be short, by default, so it is
not inconvenient to set point with mouse-1. The current default delay is too
long. Users will naturally click very quickly to follow a link, and if they
click too slowly, they will quickly learn to click quicker (or consult the
doc to change the delay value). Clicking a little too slowly unintentionally
(i.e. when intending to follow a link) will just set point, which is benign.

6) The default (emacs -q) value for mouse-1-click-follows-link is apparently
450 ms. The doc string says that the value (not the default value, but the
value) is 350 ms, which is incorrect. The doc string should be corrected, so
that it does not use a hard-coded value.