RE: mouse-1-click-follows-link

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

    > There seems to be an increasing trend to make Emacs look and act like
    > a web browser in all contexts, making it frustrating to use for text
    > editing purposes.  Setting the point is basic functionality, and I
    > shouldn't have to cross my fingers, double tap, hold, turn around and
    > touch my nose to do it.

    I'm more and more inclined to agree.

    I think the mouse-1-clock-follows-link behavior should be used
    (by default)
    at most at a few well-tested placed.  E.g. custom (where it's already
    working this way in 21.4 AFAIK), help, info.  But not grep, not
    compile, ...

    The idea of having mouse-1-clock-follows-link activated by default is to
    make it easier for beginners accustomed to web browsers more
    than to text
    editors, and maybe that makes sense, but we shouldn't overstate
    this case
    either: the number of users we can expect to win thanks to this
    minor detail
    is likely to be vanishingly small.  It's not like the
    mouse-2-follows-link
    convention is the only "unusual" UI aspect of Emacs.

    So maybe turning it on for a handful of cases makes sense.  And keeping
    a more intrusive option may also make sense for people whose
    system makes it
    hard to generate a mouse-2 event.  But the current setup has
    tricked me too
    many times already.  I know I can turn it off, but we should be
    careful not
    to alienate our fervent disciples.

I too have no problem with different default values for mouse-1-follows-link
in different buffers. Some will scream "inconsistent", but that's OK by me.

The default could be nil in buffers like grep, compilation, and dired, and
non-nil in buffers like Info, Help, Apropos, and Customize. Major modes
could define an appropriate value. With time and user feedback, we could
refine the fit.

What about the default value (setq-default) for buffers/modes that don't
specify either behavior? We could just try non-nil and see what happens
(users would let us know quickly enough). On the other hand, it probably
makes more sense to use non-nil only for the cases where we generally agree
that it makes sense, and use nil for setq-default.