Re: follow-link in grep buffer

[David Kastrup]

Richard Stallman <address@hidden> writes:

>     In order not to confuse people too much, I really would want to
>     suggest strongly that we remap double-click to mouse-2 unconditionally
>     by default (where a "stronger" mouse-2 binding exists), and also map
>     mouse-1 to the same when the special "link" property is present.
>
> I do not see any sense in this proposal.  That idea for double-click
> seems completely inconsistent with the overall scheme that we have
> adopted.

The "overall scheme" that we have adopted historically is that any
hyperlink or action is done with mouse-2.  That is perfectly
consistent and nobody has argued that it should be removed, The
problem that we are trying to address here is that

a) it is also completely unexpected to new users,
b) mouse-2 is inconvenient on a _lot_ of touch pads and mice and
often has to be done by chording.

Outside of the world of Emacs, triggering actions has traditionally
been done by double-clicking mouse-1.  Remapping this double click
will give new users _one_ sort of behavior they are accustomed to from
both MacIntosh and Windows applications, as well as a lot of X11
dialogs (where double clicking usually means select and take a choice
directly, like in a file dialog). It will also give experienced users
with a two-button device a more convenient way to trigger an action.

One common action triggered nowadays is following links.  In browsers
and increasingly also on desktop objects, the trend has been going to
do this action with a single mouse-1 click.  Since mouse-1 is rather
commonly used for setting point in Emacs, having large areas behave
like that in Emacs does not seem appropriate, even while Customize
buttons and similarly sharply confined objects are likely to be
recognized as something where one would not want to place point.
Using a special link property on them could achieve the remapping of
mouse-1 only on those areas.  Something that looks like a button is a
candidate for single click, and so is a hyperlink marked as a cross
reference.

That's two simple additional rules: a mouse-triggerable action can be
additionally to the old mouse-2 binding also be triggered with a
double-click on mouse-1, and on specially marked links, the same
action can be done with even a single mouse-1 click.

That is all.

If you take a look at the complexity of the other approaches that have
been suggested, like making a single click follow links, and a double
click set point (in strict violation to the Emacs Lisp guidelines for
double clicks), and with half a dozen exceptions like "don't follow
link if pressed for longer than this" and "don't follow link if we
have the first click in a frame" and "don't follow link if we have the
first click in the window", the recipe I propose does

a) need no special treatment of the first click into a window: if one
explicitly aims at a small button, the guess "follow link" is
reasonable.  If one aims at a larger actionable area, the default
action of "set point" does no harm.

b) is consistent with the double-click action policy set out in the
Elisp manual: the double-click action must work sensibly even if the
single-click action has already been triggered.

c) does not need special treatment of a double-click into a window: if
the double-click is passed by the window-manager, then it is
reasonable to take the action even when the frame or window did not
have selection and/or focus previously.

The additional possibilities for triggering actions on areas with
doubleclicking mouse-1, and actions on specially marked, narrowly
confined buttons/linked with singleclicking mouse-1, are just two
additional possibilities/rules in addition to the old "mouse-2 for
triggering anything" rule that is already violated, say, in Customize.

My proposal is consistent with the double-click guidelines, it
consists of just two rules that are easily accessible to a novice, it
requires no special hold-longer times (for which we have no suitable
descriptive keyboard events anyway, so you could not use C-h k or C-h
w to find out about them), it requires no special treatment of
first-click-to-frame/windoe and it provides functionality in a manner
way more common in the world outside of Emacs than our current
consistent but unusual and often inconvenient mouse-2.

That you can't see _any_ sense in this proposal, in contrast to the
complex, timing-dependent, rule-intensive, trick-requiring (like
drag-if-you-don't-want-to-trigger-action) policy-violating,
delayed-action-requiring other schemes that have both been proposed as
well as implemented, I find somewhat surprising.

I was of the opinion that at least _some_ sense might have been
detectable in my proposal.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum