[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
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
Re: follow-link in grep buffer, David Kastrup, 2005/02/21
Re: follow-link in grep buffer, Lennart Borgman, 2005/02/21
Re: follow-link in grep buffer, Richard Stallman, 2005/02/22
- Re: follow-link in grep buffer, Nick Roberts, 2005/02/25
- Re: follow-link in grep buffer, David Kastrup, 2005/02/25
- Re: follow-link in grep buffer,
Kim F. Storm <=
- Re: follow-link in grep buffer, Stefan Monnier, 2005/02/25
- Re: follow-link in grep buffer, Lennart Borgman, 2005/02/25
- Re: follow-link in grep buffer, Kim F. Storm, 2005/02/25
- Re: follow-link in grep buffer, Andreas Schwab, 2005/02/25
- Re: follow-link in grep buffer, Kim F. Storm, 2005/02/25
- Re: follow-link in grep buffer, David Kastrup, 2005/02/25
- Re: follow-link in grep buffer, Reiner Steib, 2005/02/26
- Re: follow-link in grep buffer, Richard Stallman, 2005/02/26
Re: follow-link in grep buffer, Stefan Monnier, 2005/02/25
Re: follow-link in grep buffer, David Kastrup, 2005/02/25