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: follow-link not on mouse-face Date: Sat, 22 Oct 2005 22:34:19 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1130045710 24671 80.91.229.2 (23 Oct 2005 05:35:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 23 Oct 2005 05:35:10 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 23 07:35:09 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ETYVD-0003KC-Kk for ged-emacs-devel@m.gmane.org; Sun, 23 Oct 2005 07:34:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ETYVD-0000z7-21 for ged-emacs-devel@m.gmane.org; Sun, 23 Oct 2005 01:34:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ETYV3-0000ys-FL for emacs-devel@gnu.org; Sun, 23 Oct 2005 01:34:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ETYV2-0000yg-RW for emacs-devel@gnu.org; Sun, 23 Oct 2005 01:34:29 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ETYV2-0000yd-Mj for emacs-devel@gnu.org; Sun, 23 Oct 2005 01:34:28 -0400 Original-Received: from [141.146.126.229] (helo=agminet02.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1ETYV2-0005SL-Jc for emacs-devel@gnu.org; Sun, 23 Oct 2005 01:34:28 -0400 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet02.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9N5hrw1032092 for ; Sun, 23 Oct 2005 00:43:53 -0500 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9N5YQEx030322 for ; Sat, 22 Oct 2005 23:34:26 -0600 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw6-141-144-112-49.vpn.oracle.com [141.144.112.49]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id j9N5YPFd030308 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 22 Oct 2005 23:34:26 -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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 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:44601 Archived-At: I think part of the reason may have been to help show the boundary between the line number and the line contents. That is why I suggest that each of these parts of the line could highlight separately. I may be mistaken, but my recollection was that people argued that: - Highlighting the whole line was too garish and interfered with readability. Juri mentions flicker too, which is perhaps related. I am not sure we are talking about the same thing. I am talking about mouse-face highlighting. Is mouse-face highlighting of the whole line what people considered "garish"? I think we're talking about the same thing - I too am talking about mouse-face highlighting. I'm not sure this was an _important_ argument in the previous discussion. In any case, it was not my argument. - People accidentally followed links by clicking mouse-1, trying to set point. Are you saying that the purpose of not doing mouse-highlighting on the line number was so that Mouse-1 on the line number would not visit that occurrence? I thought that was the reason, yes. I could be mistaken, but my recollection is that people wanted to cut down on the amount of text that was linkable by mouse-1, because of accidental link-following when trying to just set point. I don't have a particular recollection about *Occur*; I'm speaking of the general discussion about mouse-1, links, mouse-face, and dense-link buffers such as *Occur* and *grep*. If so, this has been changed since. Mouse-1 on the line number DOES visit that occurrence, and that's part of the background of the current complaint. Perhaps I misunderstand the current issue. Anyway, I am not sure it makes sense to say that you wanted to "set point". Because clicking with Mouse-1 on the occur buffer DOES set point. Then it visits the occurrence in the other window. That was just my way of saying that (I believe) some people naturally expected mouse-1 to _only_ set point in (at least some parts of) buffers like *Occur* and not _also_ visit the linked occurrence - that is, to have the behavior of mouse-1 when it is not on a link. There was a big discussion about not being able to click (mouse-1) anywhere without accidentally following some link, and I think the solution decided on (which I didn't agree with) was to reduce the link size - at least for mouse-1. As, I think, a typical example, Stefan said: The problem is that if I need to place point at a particular location I just click there without paying much attention to the mouse-face (or I might notice the mouse-face but too late to interrupt the action). Others can speak up, if I'm not recollecting correctly or the previous discussion is not particularly germane here. I argued for highlighting the whole line (for ease of use with the mouse and to help visual alignment, as in using a ruler with a phone book), but doing so with only (mouseover) underlining, to avoid the problem of heavy-handed highlighting (flicker and TOO MUCH NOISE). I am not sure what change you are arguing for. Is the change just a matter of which face is used for the mouse-face highlighting? To use `underline' instead of `highlight'? Yes. That is, _if_ there is judged to be no problem using mouse-1 and getting mistaken link followings. If there is such a problem, then let's fix that problem, instead of fiddling with the size of links for mouse-1 only (so it becomes different from mouse-2) as a workaround for the accidental link-following problem. Using underlining vs normal mouse-face does not solve the mouse-1 mistaken link problem - if that is a problem. But it does solve the perceived problem that there is too much link highlighting (garishness, flicker) in a buffer dense with links. IOW, I argue for full-line links, and offer to "calm the game" by using underlining for mouse-face in such buffers. I see. However, we don't want mouse-1 to be active on the whole line, for other reasons. Does anyone remember what those reasons were? I don't. I don't either. I quoted you from 6/27/2005, subject "Underlining in compile.el". You also said on 6/17: "I'm aware that currently there are too large areas for mouse-1 clicking in grep buffers.". The "thread" was quite long, and actually included more than one subject line, including, especially, "mouse-1-click follows link". The general discussion involved grep and compilation buffers as well as occur. I don't recall if different behavior was decided for these different buffers. I argued for similar link behavior (whatever that might be) in all of these buffers which are essentially tables of rows (and sometimes columns): Buffer List, Dired, compilation, occur... And I argued for users to be able to click anywhere on the row to effect the action (e.g. follow a link) - unless different columns have different actions. I believe I'm in the minority (perhaps a minority of one) on this, but since (I guess) the issue is still there and being debated again, I restated my view.