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: finger-pointer curser as default for mouse-face text Date: Tue, 26 Oct 2004 11:55:25 -0700 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1098816965 1078 80.91.229.6 (26 Oct 2004 18:56:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 26 Oct 2004 18:56:05 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 26 20:55:52 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CMWU4-0001pr-00 for ; Tue, 26 Oct 2004 20:55:52 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CMWbl-0005Ry-OK for ged-emacs-devel@m.gmane.org; Tue, 26 Oct 2004 15:03:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CMWbV-0005P4-P7 for emacs-devel@gnu.org; Tue, 26 Oct 2004 15:03:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CMWbV-0005OP-0U for emacs-devel@gnu.org; Tue, 26 Oct 2004 15:03:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CMWbU-0005OJ-Qs for emacs-devel@gnu.org; Tue, 26 Oct 2004 15:03:32 -0400 Original-Received: from [148.87.2.201] (helo=inet-mail1.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CMWTl-000795-42 for emacs-devel@gnu.org; Tue, 26 Oct 2004 14:55:33 -0400 Original-Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.191.12]) by inet-mail1.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i9QIw3CR020023 for ; Tue, 26 Oct 2004 11:58:04 -0700 (PDT) Original-Received: from rgmgw3.us.oracle.com (localhost [127.0.0.1]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i9QItT1Z011660 for ; Tue, 26 Oct 2004 12:55:29 -0600 Original-Received: from dradamslap (dhcp-amer-csvpn-gw1-141-144-68-72.vpn.oracle.com [141.144.68.72]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id i9QItSHm011632 for ; Tue, 26 Oct 2004 12:55:28 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-reply-to: Importance: Normal 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:28989 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28989 1. We can no doubt find a good way to let click mouse-1 be used to follow links and push action buttons - and still let it be used as it is now (99.99%). We've discussed several possibilities, and we can discuss more and settle on a good design. Already, IMO, acceptable approaches have been discussed, but there is no reason not to scrutinize the issue more before we make a change. David is right that whatever design we choose should not be based only on how current code happens to be implemented; it should make sense as a design, not just as a coding workaround. 2. Default behavior - One of the main reasons to make this fairly major change to longstanding Emacs behavior is to bring Emacs behavior in line with what users experience elsewhere. [This is not an argument for aligning Emacs to every convention existing outside Emacs, but when a convention is reasonable and fairly compatible, then it can at least be _considered_ for possible adoption.] This conventional behavior is especially important for _new_ Emacs users. It makes sense, if we make this change to Emacs, to make the new behavior the _default_ behavior. Let experienced Emacs users turn it off, if they like, but let new Emacs users find it on by default. It would be silly to require new users to somehow discover how to achieve this conventional behavior. Emacs lovers often enjoy discovering not-so-obvious Emacs features, but the standard, simple stuff should be obvious for newbies. Sometimes we seem to be taking the view that if a candidate change is recognized as very useful but it isn't 100% pluggable or it interferes with current behavior or implementation a tiny bit, then the proper course of action is to add it to Emacs, but turn it off. IMO, whether a feature should be on or off by default should be determined first by whether or not it is useful to most users and it might not be discovered by them if off by default. An argument for 100% correctness in 100% of contexts is appropriate to consider, but as a secondary argument - it should generally not be the main criterion for whether something is on by default. If something is _very_ broken, then it probably shouldn't be added at all. If something is, say, 1/10 broken and cannot easily be fixed, then one could argue for adding it only as a non-default option, but if functionality and performance are close to 100%, then the main argument for defaulting should be in terms of usefulness. [Yes, there are also arguments for not turning on something that will interfere with minimal operation (e.g. -nw), and, yes, those arguments can trump the main argument about useful service to most users. But sometimes such minimal operation can be cantoned within, say, a command-line option, so that the default behavior can be different in this case.] 3. Time-delay - Without having tried the time-delay implementation, my guess is that it would be an acceptable solution. The longer delay should be used for the less common behavior in Emacs - and for the behavior that is less common (inexistant?) outside of Emacs. IOW, the normal, short click behavior of mouse-1 should be to follow a link (or to click a button); the longer "click" should set point or drag or whatever within the link text. As far as an action button (or an active image or image map) is concerned, I see little reason for this exceptional mouse-1 behavior there; such behavior should be reserved for links - which is one more reason that the long "click" should _not_ be the link-follow action. Again, we should be looking for the best design in the wider context of UI conventions that have grown up around us - not looking for ways to minimize impact on experienced Emacs users or on the current Emacs implementation. 4. Modifier-key - I still think that a keyboard modifier would be an acceptable alternative if, for some reason (or in some contexts), the time-delay approach had drawbacks. Someone argued that it would be hard to remember. In that case, that is a further argument that setting point & dragging within link text must be a rare activity: if it were common, you would have no problem remembering the key sequence. For instance, if you use M-mouse-1 often for secondary selection then you have no trouble remembering it; if you use it rarely, then you might forget it. Also (slightly off-topic), doesn't it make more sense to use modifier keys for operations that you might want to _repeat_ by just holding down the modifier key? What's the point of having, say, S-mouse-1 call up a font-selection dialog box (mouse-set-font)? There are a limited number of modifier keys - why would we "waste" them on operations that cannot be repeated? (Yes, that can be an argument against using a modifier with mouse-1 for selecting link text - so be it. The latter still makes more sense to me than calling up a dialog box.) 5. Alternatives - Since we have several alternative ways to achieve the current mouse-1 behavior within link text, I don't see a good argument for not moving forward with the change we're discussing. These alternatives might be slightly less convenient than just clicking mouse-1 for this relatively rare need (selecting text within a link), but so what? If you can accomplish this need in any of a number of ways, what's the big pb? So far, we've considered these acceptable alternatives, the first of which already exists: - use the keyboard (set mark; move point) - press mouse-1 a little longer - click mouse-1 with a modifier (e.g. C-S-mouse-1) Drew