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 21:27:34 +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 1109363950 19767 80.91.229.2 (25 Feb 2005 20:39:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 25 Feb 2005 20:39:10 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 25 21:39:09 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D4mEn-0008DD-Qm for ged-emacs-devel@m.gmane.org; Fri, 25 Feb 2005 21:39:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D4mWc-0007Mo-E2 for ged-emacs-devel@m.gmane.org; Fri, 25 Feb 2005 15:57:26 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D4mUd-0006XX-B0 for emacs-devel@gnu.org; Fri, 25 Feb 2005 15:55:23 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D4mUc-0006X2-6y for emacs-devel@gnu.org; Fri, 25 Feb 2005 15:55:22 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D4mTH-0005jv-C8 for emacs-devel@gnu.org; Fri, 25 Feb 2005 15:53:59 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D4m3k-0003n3-Mt for emacs-devel@gnu.org; Fri, 25 Feb 2005 15:27:36 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1D4m3j-00069q-PP; Fri, 25 Feb 2005 15:27:36 -0500 Original-To: "Drew Adams" In-Reply-To: (Drew Adams's message of "Fri, 25 Feb 2005 11:44:41 -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:33813 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33813 "Drew Adams" writes: > 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. Look, you are arguing for an interface you are not even using yourself. Whenever I explain why a particular default is horrible, you say "Oh, I have configured something different myself currently". This leads nowhere. > 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. I disagree. > Keep in mind, too, that Emacs novices already need to learn much > trickier mouse manipulations (double-click and triple-click to > select, One does not need to learn that. One gets along fine without it. > mouse-1 plus mouse-3 to select, Again, dragging mouse-1 just works. The default behavior will get you rolling without surprises, even though you miss out on features. > 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 can tell them the _advantages_ of the separate mouse-3 thing (which is much more friendly on the sinews than dragging), and in particular mouse-3 deletion. If they can't remember it, they still will be able to everything necessary, only more cumbersome. I have no problems with pointing out available additional convenience. I have a problem with pointing out unexpected complications. > 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 seem to be a complete failure at communicating my opinion. Taste is not a question here. One of the great things of Emacs is that it can be configured to accommodate almost any taste and need. We are talking about a default setting here: and that does not need to be tasteful, but obvious and generally useful and consistent. And "I find it nice that if I reconfigure the highlighting face that as a side effect I get in dired an orientation line" has nothing to do whatsoever with consistency. We don't want the behavior in dired to be surprisingly different from the rest by default, and we don't want to have some moderately convenient choice for dired (and I disagree with your assessment even just in dired) to make all the rest less logical and convenient. It is ok to add options to dired to make it able to achieve such effects for a user with particular desires. But the defaults should be consistent and predictable even for newcomers if there are not very strong reasons against that. > 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. No? It does not require explaining that you can't do anything useful with the mouse in dired in an obvious way without the buffer disappearing? Because every possible location is a link? > 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. Sigh. The current point of discussion is double-click versus single click in connection with buttons and linkable areas. We won't get far by "I have not experienced any problems with the setup I am proposing because I have not used it yet" kind of arguments. > Once we introduce mouse-1 linking, any of the compromises we have > been discussing might require some explaining. We _have_ introduced mouse-1 linking. That is what is in CVS. That is what we are talking about. > > 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? If the single click follows a link, and a double click sets point, you can't obey the single click before waiting for the double click to expire since undoing the link following is not expedient. In contrast, you can immediately set point on a single click even before knowing whether this click will actually turn into a double click. The Emacs Lisp manual says the following in (info "(elisp) Repeat Events") [...] When the user performs a double click, Emacs generates first an ordinary click event, and then a double-click event. Therefore, you must design the command binding of the double click event to assume that the single-click command has already run. It must produce the desired results of a double click, starting from the results of a single click. This is convenient, if the meaning of a double click somehow "builds on" the meaning of a single click--which is recommended user interface design practice for double clicks. So it is rather obvious that even if there were not "prior art" for having a double click invoke an object-related action, and a single click just set point inside of an addressable area, the choice between those assignments is not arbitrary. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum