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 11:44:41 -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 1109360928 10507 80.91.229.2 (25 Feb 2005 19:48:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 25 Feb 2005 19:48:48 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 25 20:48:48 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D4lRr-0005Ue-6w for ged-emacs-devel@m.gmane.org; Fri, 25 Feb 2005 20:48:31 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D4ljb-000342-LM for ged-emacs-devel@m.gmane.org; Fri, 25 Feb 2005 15:06:47 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D4ljE-00031o-2Z for emacs-devel@gnu.org; Fri, 25 Feb 2005 15:06:24 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D4ljC-00030t-10 for emacs-devel@gnu.org; Fri, 25 Feb 2005 15:06:23 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D4ljB-00030f-He for emacs-devel@gnu.org; Fri, 25 Feb 2005 15:06:21 -0500 Original-Received: from [148.87.122.32] (helo=rgminet03.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1D4lVF-0001Ir-E3 for emacs-devel@gnu.org; Fri, 25 Feb 2005 14:51:57 -0500 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by rgminet03.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j1PJiiBc009053 for ; Fri, 25 Feb 2005 14:46:40 -0500 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 j1PJiiWL019990 for ; Fri, 25 Feb 2005 12:44:44 -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 j1PJihBR019956 for ; Fri, 25 Feb 2005 12:44:44 -0700 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 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 X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:33809 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33809 > 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. For one thing, this is visually distracting. Our highlight color is pretty brutal. For buttons, this is fine, for active lines, this is too much. For that reason, I use underline for mouse-face highlighting in such buffers. > 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. The mouse highlighting we have makes the line pretty unreadable. That is ok for buttons: you usually are aware what they are for before you move to their confined area. But it is too heavy for whole lines. Agreed - see above. The proper highlighting to use is our choice (and then it's the user's choice). I agree that mouseover highlighting of entire-line entries should be subtle, not overwhelming. I use underline. Ideally, I would love to be able to use underlining _without removing any font-lock highlighting_; that is, simply underline the text when you point to it, without changing any of its other properties. That's the behavior in most Web browsers. I'm not sure if that's easy to do, or even feasible, in Emacs, however. > - It makes it easier to click an entry - just click anywhere on the > line. Good grief. In a dired buffer, I most often need to to some directory editing operation: renaming, moving, viewing with a special application. If there is no place in the whole buffer where a simple mouse-1 will be able to place point, this is a terrible nuisance. I am not sure I'd want to have even just the file name mouse-1-buttonized, let alone the whole line. 1. Currently I do not have mouse-1 follow links, so I have no pb in this regard. I agree that if one cannot easily set point, that is a major problem. 2. I specifically said that in such buffers it is very important to be able to easily set point with the mouse. I said, about such buffers: "the main mouse action is not to set point, but setting point is still an important action (e.g. in Dired)." 3. Describing behavior like this doesn't communicate it well. You really need to try it (or have a good imagination). Also, it's hard to think outside of one's habitual box - that is, our habits can often convince us that any change is undesirable. > 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. That pretty much destroys the ability for simple editing without using smartass tricks like long clicks or drags. See above. I use mouse-1 to set point currently, as usual (no double-clicking). If we changed mouse-1 to follow links, then I would double-click to set point - or I would forego mouse-1-follows-links. "Simple editing" would not be affected detrimentally by what I or Kim described, and such buffers are not for non-simple editing. This is not an interface I want to have to explain to anybody. We want an interface that does _not_ need explaining - especially wrt basic mouse operations such as following links and setting point. I think this behavior would be fairly intuitive and easy to discover - no special explanation would be needed. Keep in mind, too, that Emacs novices already need to learn much trickier mouse manipulations (double-click and triple-click to select, mouse-1 plus mouse-3 to select, etc.). How did you learn all that? You probably read it in Info. Well, what I'm talking about is a lot less to explain than all that. And, more importantly, it probably would be discovered and not need explaining at all (unlike mouse-1 plus mouse-3 to select etc.). > 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 Terrible. If I tell that to any new Emacs users, they'll shake their heads and leave Emacs alone. And when you tell them about mouse-1 plus mouse-3 and all the rest? I don't mind if you configure your own editor in such a backward way that makes the simple operations difficult, I appreciate that you don't mind. but you won't see me applauding this choice even if you managed to convinve a majority that this is not insane. Please - du calme - it's just food for thought. I doubt I'll convince anyone, but that doesn't imply that I'm wrong. I've been wrong before, and I've been right before and unable to convince others - that's life. This is just a discussion; no one is shooting your grandmother. Personally, I find the full-line highlighting so useful that if forced to choose, I'll probably choose not to have mouse-1 follow links in such buffers. _I_ might not mind double-clicking to set point in such buffers, but if you barf at the thought, well, we might have different taste. > I don't think this would be too bad. I think it would be terrible. I can't explain such behavior to _any_ newbie. If we need to have you explain such things to newbies, then, yes, we're in deep doo-doo. The basics of our UI should be straightforward, discoverable, and self explanatory - so you will be able to retire from the lecture circuit ;-). ("Lesson 17: Introduction to the Emacs Mouse, Part III" - sheesh!) It is fine if you have the possibility to configure it this way, and the possibility to tell people how convenient you find it and they should try it as well, but I won't accept something so completely backward from all customary defaults with no apparent advantage without screaming all the while. Uh, have you had your coffee this morning, David? To make one thing clear, again: I find full-line links in buffers like Dired convenient, yes. I invite others to try it, yes. No, it doesn't require any explaining. I have not used full-line links at the same time as using mouse-1 to follow links, so I have not experienced any problems in that regard. Once we introduce mouse-1 linking, any of the compromises we have been discussing might require some explaining. I don't see double-click vs any of the other means of setting point being less intuitive or requiring more explanation. I threw out double-click-to-set-point this morning as another possibility to think about. I don't think any of the "solutions" mentioned so far are wonderful, or I wouldn't have tossed this one into the ring for consideration. Please _don't_ think in the category "what would be most convenient for me, even if by a hairline". Rather try thinking "what would be most convenient to _explain_ for me". Ease of explanation is important. Ease of use (convenience) and discovery is even more important. If people ask you "Why for heaven's sake does it do that?", you should have a very convincing answer, or you are doing something wrong. Agreed. In contrast, with a scheme like your, I'd be ashamed to explain, and I would not have anything close to a convincing answer to "Why for heaven's sake does it do that?". And "That's just the way it does it. Take it or leave it." is not what I like to offer as an explanation. I wouldn't want you to feel ashamed on my behalf. And far be it from me to say "take it or leave it." Let me say, instead, "please take it and think about it" - that's all. You've obviously thought about it, and you reject it; that's OK by me. > 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. Which is why double clicking anywhere on the line is perfect for following a link. Or setting point ;-). Again, honestly I don't know how inconvenient double-clicking to set point or follow a link would be - I'd have to try it. I do know that I prefer the full-line mouseover in buffers with full-line entries, and I'll keep that behavior in my own Emacs, whatever I decide to choose for following links vs setting point. > 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. So let us choose the worst? No, let us find the best, whatever that may be. Let us find the easiest to use, easiest to discover, easiest to explain, most flexible approach that differs least from a) behavior elsewhere in Emacs and b) behavior in other apps. Amen. > 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. Sure. They'll just switch to a different editor. Heavens! Lecturing about vi or TextPad is no fun at all! > 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?) If you read in the coding guidelines you'll find that a double-click action should _add_ to a single click action so that the single click action can be executed immediately, without delay or other disturbances. Uh, what's the connection with what I wrote? > - It should be at least as easy to follow a link as to set > point. For a button-like link. But not for whole lines. For any link, it should be at least as easy to follow a link as to set point - especially in 'buffers that are primarily "view" buffers, as opposed to "edit".' Regardless of the shape and size of the hot zone. > 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. dired buffers are used for quite more than just selecting a file to view. Yes, they are.