> 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
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
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
either: the number of users we can expect to win thanks to this
is likely to be vanishingly small. It's not like the
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
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.