Re: follow-link in grep buffer

[Kim F. Storm]

David Kastrup <address@hidden> writes:

>> 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.

This really hasn't anything to do with focus-follows-mouse.

What if you set mouse-autoselect-window ?


In any case, I agree that last modification isn't perfect, and
I'll think about what to do.



>
> 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).

IMO, this has nothing to do with the default of
mouse-1-click-follows-link.  It is a problem of those modes which
basically make large parts of a buffer mouse-2 click-able and then
uses a too primitive form of the `follow-link' functionality.

So grep and gnus should not just say that mouse-1 blindly maps to
mouse-2.

> 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.

If so, it is a bug.

The code specifically tests to see if there is a second click within
double-click-time and generates a double click rather than two
separate clicks.

>
> 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.

So change grep and gnus...


-- 
Kim F. Storm <address@hidden> http://www.cua.dk