Re: follow-link in grep buffer

[David Kastrup <dak@gnu.org>]

Nick Roberts <nickrob@snap.net.nz> writes:

>  >     The grep buffer is an example. If I try to place the cursor anywhere on
>  >     a line before the end of a match, the associated file pops up in
>  >     another buffer. However I might just want to select that window to
>  >     resize it.
>  > 
>  > When you found this not to your taste, were you aware about the aspect
>  > that Mouse-1 does not follow links if you move the mouse at all?
>
> No. I wasn't aware of that. With the default setting, the user would have to
> move the mouse and release it within 350 milliseconds for it to have any
> effect. I  think must be quite hard to do.
>
>  > Is that method of avoiding the problem adequate?
>
> My preferences remained unchanged but I also think it must be
> confusing for a novice user. Before I was aware of the time limit, I
> didn't understand why clicking mouse-1 sometimes popped to a new
> buffer and other times didn't.

I am afraid that the same is the case here.  I have
focus-follows-mouse set here by default in the window manager, so I
don't expect clicks that don't do anything.  The current behavior
(where a window change does not follow links at all) is more confusing
than the previous one.

Kim, I am aware that you hate double clicks.  However, for the
I-hate-something proponents there is always the possibility of using
customize to change the default.

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.  This
property would only be present in clearly "clickable" situations such
as buttons or Info references, but not where there is basically normal
text with clickable properties (like in a grep buffer or in the
headers of gnus buffers).

A double click can never be confused with a "click just to shift
point/focus".  It is conveniently available on even single-key mouses
and its behavior does not need 5 sentences to explain.  The confusion
potential is just with mark-word, and that is tolerable in clickable
situations.

The current scheme also steals the potential to double-click, anyway,
since the first short click already follows the link, and a
double-click by click and hold long, then leave the button very short
and click again, this time short...  that's not something you manage
if you are not a piano player, anyway.

It's nice if everything else we have tried out is available as a
customizable option, but by default, I think we should remap only the
double click when not asked for, and the normal single click (of _any_
duration) when asked for.

Secret timing differences and stuff like that are much too subtle
_unless_ the user configured them himself, in which case he'd know
about them.

That is the default behavior of most applications, and I don't see
that the alternatives we have tried so far would be so much better as
to warrant getting people used to them instead.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum