RE: finger-pointer curser as default for mouse-face text

[Drew Adams]

1. We can no doubt find a good way to let click mouse-1 be used to follow
links and push action buttons - and still let it be used as it is now
(99.99%). We've discussed several possibilities, and we can discuss more and
settle on a good design. Already, IMO, acceptable approaches have been
discussed, but there is no reason not to scrutinize the issue more before we
make a change. David is right that whatever design we choose should not be
based only on how current code happens to be implemented; it should make
sense as a design, not just as a coding workaround.


2. Default behavior - One of the main reasons to make this fairly major
change to longstanding Emacs behavior is to bring Emacs behavior in line
with what users experience elsewhere. [This is not an argument for aligning
Emacs to every convention existing outside Emacs, but when a convention is
reasonable and fairly compatible, then it can at least be _considered_ for
possible adoption.]

This conventional behavior is especially important for _new_ Emacs users.
It makes sense, if we make this change to Emacs, to make the new behavior
the _default_ behavior. Let experienced Emacs users turn it off, if they
like, but let new Emacs users find it on by default. It would be silly to
require new users to somehow discover how to achieve this conventional
behavior. Emacs lovers often enjoy discovering not-so-obvious Emacs
features, but the standard, simple stuff should be obvious for newbies.

Sometimes we seem to be taking the view that if a candidate change is
recognized as very useful but it isn't 100% pluggable or it interferes with
current behavior or implementation a tiny bit, then the proper course of
action is to add it to Emacs, but turn it off. IMO, whether a feature should
be on or off by default should be determined first by whether or not it is
useful to most users and it might not be discovered by them if off by
default.

An argument for 100% correctness in 100% of contexts is appropriate to
consider, but as a secondary argument - it should generally not be the main
criterion for whether something is on by default. If something is _very_
broken, then it probably shouldn't be added at all. If something is, say,
1/10 broken and cannot easily be fixed, then one could argue for adding it
only as a non-default option, but if functionality and performance are close
to 100%, then the main argument for defaulting should be in terms of
usefulness.

[Yes, there are also arguments for not turning on something that will
interfere with minimal operation (e.g. -nw), and, yes, those arguments can
trump the main argument about useful service to most users. But sometimes
such minimal operation can be cantoned within, say, a command-line option,
so that the default behavior can be different in this case.]


3. Time-delay - Without having tried the time-delay implementation, my guess
is that it would be an acceptable solution. The longer delay should be used
for the less common behavior in Emacs - and for the behavior that is less
common (inexistant?) outside of Emacs.

IOW, the normal, short click behavior of mouse-1 should be to follow a link
(or to click a button); the longer "click" should set point or drag or
whatever within the link text. As far as an action button (or an active
image or image map) is concerned, I see little reason for this exceptional
mouse-1 behavior there; such behavior should be reserved for links - which
is one more reason that the long "click" should _not_ be the link-follow
action.

Again, we should be looking for the best design in the wider context of UI
conventions that have grown up around us - not looking for ways to minimize
impact on experienced Emacs users or on the current Emacs implementation.


4. Modifier-key - I still think that a keyboard modifier would be an
acceptable alternative if, for some reason (or in some contexts), the
time-delay approach had drawbacks. Someone argued that it would be hard to
remember. In that case, that is a further argument that setting point &
dragging within link text must be a rare activity: if it were common, you
would have no problem remembering the key sequence. For instance, if you use
M-mouse-1 often for secondary selection then you have no trouble remembering
it; if you use it rarely, then you might forget it.

Also (slightly off-topic), doesn't it make more sense to use modifier keys
for operations that you might want to _repeat_ by just holding down the
modifier key? What's the point of having, say, S-mouse-1 call up a
font-selection dialog box (mouse-set-font)? There are a limited number of
modifier keys - why would we "waste" them on operations that cannot be
repeated? (Yes, that can be an argument against using a modifier with
mouse-1 for selecting link text - so be it. The latter still makes more
sense to me than calling up a dialog box.)


5. Alternatives - Since we have several alternative ways to achieve the
current mouse-1 behavior within link text, I don't see a good argument for
not moving forward with the change we're discussing. These alternatives
might be slightly less convenient than just clicking mouse-1 for this
relatively rare need (selecting text within a link), but so what? If you can
accomplish this need in any of a number of ways, what's the big pb? So far,
we've considered these acceptable alternatives, the first of which already
exists:

 - use the keyboard (set mark; move point)
 - press mouse-1 a little longer
 - click mouse-1 with a modifier (e.g. C-S-mouse-1)

 Drew