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: Fri, 21 Oct 2005 22:23:14 -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 1129958684 26901 80.91.229.2 (22 Oct 2005 05:24:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 22 Oct 2005 05:24:44 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 22 07:24:38 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ETBr0-0008Lz-DG for ged-emacs-devel@m.gmane.org; Sat, 22 Oct 2005 07:23:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ETBqz-0006bB-IX for ged-emacs-devel@m.gmane.org; Sat, 22 Oct 2005 01:23:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ETBqr-0006b4-Ad for emacs-devel@gnu.org; Sat, 22 Oct 2005 01:23:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ETBqp-0006as-Nv for emacs-devel@gnu.org; Sat, 22 Oct 2005 01:23:29 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ETBqp-0006ap-Je for emacs-devel@gnu.org; Sat, 22 Oct 2005 01:23:27 -0400 Original-Received: from [148.87.122.31] (helo=rgminet02.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1ETBqp-0007ba-FN for emacs-devel@gnu.org; Sat, 22 Oct 2005 01:23:27 -0400 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet02.oracle.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id j9M5NPHt005165 for ; Fri, 21 Oct 2005 23:23:25 -0600 Original-Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9M5NOW0014865 for ; Fri, 21 Oct 2005 23:23:24 -0600 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw5-141-144-104-54.vpn.oracle.com [141.144.104.54]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id j9M5NNfZ014855 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 21 Oct 2005 23:23:24 -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:44553 Archived-At: > I think it is a mistake to put the `follow-link' property > on text areas that have no mouse-face=highlight. The > `highlight' face is a good warning that mouse-1 click will > try to follow links, and a missing `highlight' face > indicates that it is always safe to click mouse-1 > to relocate point. That is a valid point. Well, I'm not sure, I'd expect mouse-1 to have the exact same effect as mouse-2 no matter where I'm clicking... That is a valid point too. So maybe the mouse face should cover the whole line. Or perhaps -- though this could take more work -- the line number should also highlight, but separately. Either one would achieve both of the goals above. So I think the question is not whether to make mouse-1 to have the exact same effect as mouse-2, but why mouse-2 sensitive areas are bigger than areas with mouse-face=highlight in the *Occur* buffer. I recall that the reason for that was to reduce flicker (especially on large context areas in the *Occur* buffer). 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. - People accidentally followed links by clicking mouse-1, trying to set point. The second point, in particular, was I think the reason we reduced the hot zone from a full-line link. 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). That is, do not use underlining for the link text, but underline it when the mouse is on the link. I would still argue this. Here is some of the earlier exchange: A common practice used on Web pages with tables or lists that are dense with similar links in similar places is to _not_ use underlining. That is, in a long list where each list item is a link, and where the list is the main thing on the page, underlining is often foregone because it is unnecessary and would be distracting. Users can easily figure out that each line is a link - mouseover anywhere within the list (the page) highlights a link. If compile and grep buffers had full-line links, the links would be easier to access, they would help with visual alignment (like using a ruler in a parts catalog), and there would be no need to underline them. Mouseover highlighting would suffice, and the mouseover highlighting could itself be underlining, to reduce noise. I see. However, we don't want mouse-1 to be active on the whole line, for other reasons. I think the current set of places where mouse-1 is active is the right set. The question that remains is only whether to underline those places. In the current discussion, what is the reason for a distinction between the line number and the rest of the line? Richard suggests that part of the reason is to show the boundary between the line number and the rest. I don't see that as a problem or recall that being mentioned before. With only mouse-2 to follow links, I don't think there was a call to reduce the link size. Is there a mouse-2 behavior difference clicking one or the other? I think the main reason we reduced the hot zone was because you might want to set point with mouse-1, and it was thought that reducing the size of the mouse-1 link would cut down on the mistaken-follow problem. Either we have a good solution for dealing with mouse-1 in general - being able to either set point (even in link text) or follow a link - or we do not. If we do, then I don't see the point of the extra "help" in this regard offered by treating line numbers differently. If we don't, then let's fix that design, rather than trying to give it a little extra help here and there.