[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: follow-link in grep buffer

From: Kim F. Storm
Subject: Re: follow-link in grep buffer
Date: Fri, 25 Feb 2005 12:12:20 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

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

> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]