From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: follow-link in grep buffer Date: Fri, 25 Feb 2005 19:09:57 +0100 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1109354918 23767 80.91.229.2 (25 Feb 2005 18:08:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 25 Feb 2005 18:08:38 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 25 19:08:38 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D4jrj-0000KH-S0 for ged-emacs-devel@m.gmane.org; Fri, 25 Feb 2005 19:07:09 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D4k9X-0004GO-9r for ged-emacs-devel@m.gmane.org; Fri, 25 Feb 2005 13:25:27 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D4k8r-0004ES-Ul for emacs-devel@gnu.org; Fri, 25 Feb 2005 13:24:46 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D4k8q-0004Da-7C for emacs-devel@gnu.org; Fri, 25 Feb 2005 13:24:44 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D4k8q-0004DQ-0o for emacs-devel@gnu.org; Fri, 25 Feb 2005 13:24:44 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D4juZ-0002nE-5Q for emacs-devel@gnu.org; Fri, 25 Feb 2005 13:09:59 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1D4juY-0001Fj-CJ; Fri, 25 Feb 2005 13:09:58 -0500 Original-To: "Drew Adams" In-Reply-To: (Drew Adams's message of "Fri, 25 Feb 2005 08:37:36 -0800") 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:33807 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33807 "Drew Adams" writes: > 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. 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. Personally, I could imagine a two-fold system: decent highlighting for non-mouse1-links (that need mouse-2 or a double click), brutal highlighting for really active areas where mouse-1 already has an effect. > 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. > - 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. > 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. This is not an interface I want to have to explain to anybody. > 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. I don't mind if you configure your own editor in such a backward way that makes the simple operations difficult, but you won't see me applauding this choice even if you managed to convinve a majority that this is not insane. > I don't think this would be too bad. I think it would be terrible. I can't explain such behavior to _any_ newbie. 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. 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". 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. Putting the scrollbar to the left in an Emacs window has a convincing answer. Left is where the bulk of the text action is in a left-to-right script. That is one example where Emacs differs from the rest of the world for a _good_ reason. I can explain that. And it is something that I would be proud to explain, showing people how Emacs developers use their brain. 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. > 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. > 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? > 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. > 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. > - 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. > 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. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum