From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: mouse-1-click-follows-link Date: Wed, 15 Jun 2005 09:26:14 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1118852729 23042 80.91.229.2 (15 Jun 2005 16:25:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 15 Jun 2005 16:25:29 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 15 18:25:21 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Diag6-00066G-BZ for ged-emacs-devel@m.gmane.org; Wed, 15 Jun 2005 18:23:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DialL-00075H-4a for ged-emacs-devel@m.gmane.org; Wed, 15 Jun 2005 12:29:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DiakH-0006tw-Cs for emacs-devel@gnu.org; Wed, 15 Jun 2005 12:28:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DiakC-0006rH-Pi for emacs-devel@gnu.org; Wed, 15 Jun 2005 12:28:01 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DiakC-0006qw-Dr for emacs-devel@gnu.org; Wed, 15 Jun 2005 12:28:00 -0400 Original-Received: from [148.87.122.30] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1Diak7-0007oW-Co for emacs-devel@gnu.org; Wed, 15 Jun 2005 12:27:55 -0400 Original-Received: from rgminet01.oracle.com (localhost [127.0.0.1]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j5FGQGlv019353 for ; Wed, 15 Jun 2005 10:26:16 -0600 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j5FGQFMr019304 for ; Wed, 15 Jun 2005 10:26:15 -0600 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j5FGQEkE012709 for ; Wed, 15 Jun 2005 10:26:14 -0600 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw300.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j5FGQE3s012693 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 15 Jun 2005 10:26:14 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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 Xref: news.gmane.org gmane.emacs.devel:38892 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:38892 Summary: (1) mouse-1-click-follows-link: it should be `nil' everywhere. (I've changed my opinion.) (2) We should change the link mouseover pointer. (3) Hot-zone extent should not be based on a supposed tradeoff between setting point and following a link. That's a red herring. Reasons below. Here's where we are now: mouse-1-click-follows-link is nicely defined to satisfy everyone, I think. You can turn off mouse-1 link sensitivity completely or activate it on: 1) short (fast) click, 2) long (slow) click, or 3) double-click. Good job. What we've *not* come to agreement on yet: 1) Whether the behavior should always be the same in each buffer or should possibly vary by buffer. If the latter, should this be user-changeable (e.g. local values) or not? 2) What the default value should be. If we allow local values, this means both a) the default global value and b) the default local values for different categories of standard buffers (e.g. those dense with links, like Dired, vs those sparse with links, like Info). Our options include `nil' (mouse-1 doesn't follow links at all), +integer (fast click follows link), -integer (slow click follows link), and `double' (double-click follows link). Here's what I said before: My opinion: 1. Users should be able to have different behaviors in different buffers, in this regard. 2. The global (default) value should be `nil': mouse-1 should be insensitive to links by default. 3. The default value for buffers that are sparse with hot spots (e.g. Info, Help, Customize) should be 100 ms (fast click follows link). 4. The default value for buffers that are dense with hot spots (e.g. Dired, grep, compilation) and for which users will likely want to set point occasionally should be `double' (double-click follows link). 5. The default value for buffers that are dense with hot spots, but for which users don't need to set point at all (eg. Buffer List) should be 100 ms (fast click follows link). (There are probably few such standard buffers.) (1) I've changed my opinion on #4 and #5. By default, the value should be `nil' everywhere: mouse-1 should *not* follow links. Reasons: a. mouse-2 as yank is not needed on a link, so mouse-2 is a perfect choice for following links. That was surely behind the original design, and it remains the best argument for mouse-2. Having mouse-1 sometimes follow a link and sometimes set point (e.g. via different delays), in the same buffer, always involves some UI tradeoffs (fast-click, slow-click, double-click). That's OK, but it should not be the _default_ behavior anywhere. b. With mouse-1-click-follows-links, especially if we allow local values, everyone can do what he wants, wherever he wants. This includes people who use mice without mouse-2. IOW, even if mouse-2 is the default for links, users can choose instead to use mouse-1 in various ways for linking. Previously, users could not easily switch to mouse-1; now they can. c. Newbies will discover mouse-2 for links soon enough. They will need to discover it for yanking, anyway; it is no harder to learn it for linking. Up front, we should: (i) Tell them about mouse-2 for linking. (ii) Suggest they try it for a while ("try it; you'll like it"). (iii) Tell them they can change it: mouse-1-click-follows-link. d. It is not difficult to go back and forth between mouse-2 for linking in Emacs and mouse-1 in other apps. We all do it all the time. The argument that people are "used to mouse-1 for linking" is countered by c plus d - there are two aspects to it. (2) As I said in October, and which led to Kim coming up with using mouse-1 for linking, we should change the finger-pointer cursor over links. The index-finger pointer _suggests_ using mouse-1. That pointer is commonly used by Web browsers to indicate that the pointer is over a hyperlink or an action button, so that's presumably the reason it is now used in Emacs for the same thing. However, in common Web browsers, the mouse button to activate such a link or button is mouse-1, not mouse-2. What bugs me is that the index-finger pointer suggests to me to use mouse-1, because the index finger (wired, in my head, to mouse-1) is the one doing the pointing. RMS and Kim both thought I was asking to use mouse-1 for links. I was only suggesting to change the mouseover pointer. RMS wrote: Mouse-1 can't do that. Mouse-1 in Emacs is a general Emacs command that is meanigful anywhere in the buffer. Anyway, this is not the time to change features. Kim came up with a patch to use mouse-1 for links, and we were off and running. I wrote: > My point was not that using mouse-2 is not good. I think mouse-2 > should remain the way to click links and buttons in Emacs... But we went with mouse-1 for links, because it is "common user interface practice" and some people don't have a mouse-2. So far: 1) Let's use mouse-2 for links, by default. 2) Let's change the link pointer from an index-finger. My last point: (3) We should make decisions about the extent (and placement) of hot zones (links, buttons) based on other criteria, besides a tradeoff between setting point and following a link - that is a red herring. We should design hot zones assuming that there is no problem setting point: assume that mouse-1 sets point and mouse-2 activates hot spots. So, in particular, I repeat that full-line links are better for buffers like grep, compilation, and Dired, because of the alignment aid and ease of use they provide. If Emacs doesn't do this by default, it should at least provide an easy way for users to get this behavior. To repeat: 8. Users should be able to have full-line hot zones for buffers that are essentially lists of links. This includes grep, compilation, and Dired. RMS has apparently decided to reduce the hot-zone size for grep. I prefer full-line links. It would be good for users to be able to customize this, regardless of the default behavior. IOW, because of the recent move to mouse-1 following links (even potentially), we are now losing full-line links in grep. People accidentally followed links (me too), so the hot zones are now being reduced to alleviate this problem. I don't agree with that solution to the problem, but all I would ask for is a way for users to get back the full-line link behavior. Mouse-1 is extremely customizable now via mouse-1-click-follows-links, but the hot-zone extent is not customizable at all, without rewriting the grep/compile code.