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: hyperlinks in variable's value - links to libraries Date: Fri, 6 Jan 2006 09:10:49 -0800 Message-ID: References: <17341.63060.125701.419230@kahikatea.snap.net.nz> 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 1136571929 17965 80.91.229.2 (6 Jan 2006 18:25:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 6 Jan 2006 18:25:29 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 06 19:25:26 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EuwHE-000447-IA for ged-emacs-devel@m.gmane.org; Fri, 06 Jan 2006 19:25:25 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EuwJ1-0001FX-23 for ged-emacs-devel@m.gmane.org; Fri, 06 Jan 2006 13:27:15 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Euv91-00036Z-HR for emacs-devel@gnu.org; Fri, 06 Jan 2006 12:12:51 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Euv8z-00035P-9D for emacs-devel@gnu.org; Fri, 06 Jan 2006 12:12:49 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Euv8x-000354-GY for emacs-devel@gnu.org; Fri, 06 Jan 2006 12:12:48 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EuvAh-0003KO-Og for emacs-devel@gnu.org; Fri, 06 Jan 2006 12:14:37 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k06HAquS009584 for ; Fri, 6 Jan 2006 11:10:52 -0600 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 k06HApMw014372 for ; Fri, 6 Jan 2006 10:10:51 -0700 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw6-141-144-116-3.vpn.oracle.com [141.144.116.3]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k06HAor3014364 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 6 Jan 2006 10:10:51 -0700 Original-To: "Emacs-Devel" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <17341.63060.125701.419230@kahikatea.snap.net.nz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal 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:48798 Archived-At: > ;; Hyperlinks in variable's value are quite frequently > ;; inappropriate e.g C-h v features > ;; (help-xref-on-pp from (point)) > > I disagree with the "fix" of commenting out this > line - at the least, I would like such links to be an option. I commented it out, rather than remove it, in case someone came up with a better solution, Good idea. not for someone to lobby to revert it. I'm certainly not lobbying to just revert it. I would like to see: 1. It reverted, so *Help* buffers can once again link users to related source code and object (e.g. variable) descriptions. 2. *Libraries* also be linked, in addition to functions and variables - see the code I sent, as an example. This is especially useful for `C-h v features'. 3. An option be added, so users can skip adding *Help* links to save time, if they like. 4. In addition to #3, a button in *Help* to show links. If the option in #3 were turned off, then the buffer would be displayed without the time-consuming object links (variables, libraries, etc.), but you could still click a `Show Links' button to add the links. IOW, add the links only upon demand. 5. After links have been shown once, the button would change to `Hide Links', to enhance readibility (reduce visual clutter). Once the links have been calculated (`Show Links'), the link info would be kept - it would not be lost via `Hide Links' - so redisplay via `Show Links' would be fast. I'm especially interested in #2. I don't think it was in response to a report you made Maybe you're right. I can't find any message where I mentioned that (and Emacs bug reports don't go through my email client, so I get no copy of the bug-report msg, and I'm too lazy to search the emacs-pretest archive). and `features' was just an example, although I can't remember the others. The other you mentioned (2005-05-17, subject Forward button in help buffer) was `gud-minor-mode'. Many variables like mode-line-format or after-load-list have a lot of underlining, some of which isn't that helpful (a user is hardly likely to want click on concat or user-init-file) and it makes it harder to see what you're looking at. Visual clutter is not a reason to not link things; it is a reason to get rid of visual clutter. The solution to visual overload from underlining when a buffer is mainly links (i.e. link-dense) is to not have the face show that a link is present, but rely on mouseover to show that. If a buffer is truly link-dense, then users discover right away that things are linked, because the mouse is always over a link. But see below - *Help* is not a good candidate for this approach. If I didn't know what `concat' and `user-init-file' are, I might well want to click them to find out. Users are various, with different backgrounds, different needs, interacting in different contexts. I think its best not to lead users anywhere than up the garden path. Meaning? Example? The doc strings on the other hand can be more carefully crafted to DTRT. What's the connection? I want to see the list of features when I use `C-h v features'. How does rewriting the doc string affect the current discussion? > Although it can be slow, it is very useful: looking at `features' > should be an entry point to accessing the features listed. The links are still available on mouse-2 as help-follow, they're just not underlined or highlighted. That would be appropriate if all *Help* buffers were link-dense, so that random mouseover would show users that most things are linked. It's not appropriate for *Help* however, because most *Help* buffers are not link-dense. The main problem, for me, is that library names are not linked to libraries. That is the suggestion I'm making. Having a help-echo saying "mouse-2, RET: describe this function" while over a feature is not helpful IMO, a hinder-echo you could say. I have no stake in help-echoes. I too find them annoying often. A link should be indicated by a face (preferably blue underline), unless the buffer is always link-dense (and especially if the buffer is essentially a list or table). Dired, *grep*, and Buffer List are examples of such link-dense tables - there is no need for a face to indicate links in such buffers. Other buffers, including *Help* and *Info* should show links with a special face (underline).