From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: follow-link in grep buffer Date: Fri, 25 Feb 2005 12:12:20 +0100 Message-ID: References: <16922.19947.785134.975378@farnswood.snap.net.nz> <16926.51952.150749.303780@farnswood.snap.net.nz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1109331872 10690 80.91.229.2 (25 Feb 2005 11:44:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 25 Feb 2005 11:44:32 +0000 (UTC) Cc: Nick Roberts , rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 25 12:44:31 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D4dtL-0003St-RL for ged-emacs-devel@m.gmane.org; Fri, 25 Feb 2005 12:44:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D4eB5-0003O6-M6 for ged-emacs-devel@m.gmane.org; Fri, 25 Feb 2005 07:02:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D4dkZ-00065H-Og for emacs-devel@gnu.org; Fri, 25 Feb 2005 06:35:16 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D4dkW-00064a-9E for emacs-devel@gnu.org; Fri, 25 Feb 2005 06:35:14 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D4dkU-00061K-Gu for emacs-devel@gnu.org; Fri, 25 Feb 2005 06:35:11 -0500 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.34) id 1D4dOO-0000Bt-Qk for emacs-devel@gnu.org; Fri, 25 Feb 2005 06:12:21 -0500 Original-Received: (qmail 30133 invoked from network); 25 Feb 2005 11:12:18 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 25 Feb 2005 11:12:18 -0000 Original-To: David Kastrup In-Reply-To: (David Kastrup's message of "Fri, 25 Feb 2005 10:46:14 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:33789 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33789 David Kastrup 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 http://www.cua.dk