From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: follow-link in grep buffer Date: Fri, 25 Feb 2005 08:37:36 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1109349436 4436 80.91.229.2 (25 Feb 2005 16:37:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 25 Feb 2005 16:37:16 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 25 17:37:15 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D4iSJ-000080-Ug for ged-emacs-devel@m.gmane.org; Fri, 25 Feb 2005 17:36:45 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D4ik6-0000Iw-Dj for ged-emacs-devel@m.gmane.org; Fri, 25 Feb 2005 11:55:06 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D4ijT-00008B-1g for emacs-devel@gnu.org; Fri, 25 Feb 2005 11:54:27 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D4ijJ-0008VF-SR for emacs-devel@gnu.org; Fri, 25 Feb 2005 11:54:19 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D4ijJ-0008Um-NZ for emacs-devel@gnu.org; Fri, 25 Feb 2005 11:54:17 -0500 Original-Received: from [141.146.126.231] (helo=agminet04.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1D4iUG-0003yN-HT for emacs-devel@gnu.org; Fri, 25 Feb 2005 11:38:45 -0500 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j1PGbcnK016531 for ; Fri, 25 Feb 2005 08:37:38 -0800 Original-Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j1PGbc5s007314 for ; Fri, 25 Feb 2005 09:37:38 -0700 Original-Received: from dradamslap (dhcp-amer-csvpn-gw1-141-144-65-188.vpn.oracle.com [141.144.65.188]) by rgmgw1.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j1PGbcn1007297 for ; Fri, 25 Feb 2005 09:37:38 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: 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:33803 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33803 If we have specific problems in certain modes, let's fix those modes (e.g. in grep that you have to click on the file:line part of a line to jump). Just to add one more permutation to our list of contortions ;-) - I would like to see modes like Dired and Grep and Buffer List make the entire line, which is in fact the entire entry, clickable and mouse-highlightable, as I think I mentioned before. The reasons are: - It makes it much easier to "scan" with the mouse, seeing what lines up with what. This is like using a ruler to scan entries in a large table or phone book. - It makes it easier to click an entry - just click anywhere on the line. I've used this behavior for decades in my own Emacs, and I find it useful. Anyway, I mention this now because of Kim's suggestion, above, which moves a bit in the opposite direction. IOW, I don't want to see the hot zone _reduced_ or limited in buffers like grep, I instead want to see the entire entry (which is the entire line) become the hot zone. Assuming that I were able to convince others about this (;-)), what would that mean wrt mouse bindings? In buffers like these (Dired, grep, Buffer List), the main mouse action is not to set point, but setting point is still an important action (e.g. in Dired). I don't have a brilliant suggestion, but I wonder if it wouldn't be reasonable, in such buffers, to reverse one approach mentioned already: - mouse-1 follows the link (which, to me, should be the whole line) - double-click mouse-1 sets point I don't think this would be too bad. In such buffers we do need to set point sometimes, and we sometimes want to create a region, but we don't usually need to double-click to select a word. We could always drag to create a region (I do that in my Dired buffers). Of course, there is the argument that this won't be intuitive to users, but I think we'll be up against such an argument no matter what we choose. After all, being able to both a) follow a link and b) set point is not that common. Another argument against this might be that a too-slow double-click would mess up the user, mistakenly following the link. I think users can deal with this. In Windows, a simple GUI dialog lets you set the double-click interval (speed), and this setting applies to all applications. (BTW, Do we pick up this Windows setting in Emacs, to use as our double-click delay?) Kim's time delay is also a good approach to the mouse-1/mouse-2 problem, and it is also standard behavior in many apps (the argument that users will never discover it is overstated, IMO). There would be no problem in adopting both approaches simultaneously (to set point: either double-click or hold mouse-1 pressed a little longer). That might sound paradoxical, but it's perhaps the easiest behavior to explain (and discover): to follow a link, use a single short click; anything else sets point. Whatever we choose, we have these requirements: - It should be at least as easy to follow a link as to set point. In buffers that are primarily "view" buffers, as opposed to "edit", it is tolerable if setting point is not quite as easy as following a link. - It shouldn't be too hard to discover or perform either action. - There should not be any disastrous consequences of making a mistake. WRT having the first mouse-click set the focus (a suggestion Stefan and I each made): Yes, that would be done only if the window didn't already have the focus. No, it wouldn't apply if you choose to have the focus automatically follow the mouse. I think that first-click-focuses suggestion makes sense, regardless of what other conventions we adopt - that is, it should be adopted even if we also choose to use double-click (or whatever) to set point.