From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nick Roberts Newsgroups: gmane.emacs.devel Subject: RE: hyperlinks in variable's value - links to libraries Date: Sat, 7 Jan 2006 11:35:54 +1300 Message-ID: <17342.61642.178052.3991@kahikatea.snap.net.nz> 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 1136587041 4723 80.91.229.2 (6 Jan 2006 22:37:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 6 Jan 2006 22:37:21 +0000 (UTC) Cc: Emacs-Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 06 23:37:19 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 1Ev0Cs-0007Sj-Hn for ged-emacs-devel@m.gmane.org; Fri, 06 Jan 2006 23:37:11 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ev0Ef-0007G2-Rk for ged-emacs-devel@m.gmane.org; Fri, 06 Jan 2006 17:39:01 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ev0EQ-0007Cz-SG for emacs-devel@gnu.org; Fri, 06 Jan 2006 17:38:47 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ev0EP-0007BL-Kq for emacs-devel@gnu.org; Fri, 06 Jan 2006 17:38:46 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ev0EN-0007B0-WE for emacs-devel@gnu.org; Fri, 06 Jan 2006 17:38:45 -0500 Original-Received: from [202.37.101.8] (helo=viper.snap.net.nz) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Ev0GC-0005IL-IG for emacs-devel@gnu.org; Fri, 06 Jan 2006 17:40:37 -0500 Original-Received: from kahikatea.snap.net.nz (p193-tnt1.snap.net.nz [202.124.110.193]) by viper.snap.net.nz (Postfix) with ESMTP id 9845F739EBC; Sat, 7 Jan 2006 11:36:42 +1300 (NZDT) Original-Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 0807C8459; Sat, 7 Jan 2006 11:35:54 +1300 (NZDT) Original-To: "Drew Adams" In-Reply-To: X-Mailer: VM 7.19 under Emacs 22.0.50.42 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:48804 Archived-At: > 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'. It still doesn't know what its looking at. It would link the first match which would in many cases would still be to the function. Also the variable features is a list of features, not libraries e.g text-properties, overlay base64 are provided in bindings.el > 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. Another option! Another button! The idea is to make it easier, not harder to navigate the links. > 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. Kept where? The help buffer is generally regenerated through the [back] button. ... > 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. Sounds too complicated to me. Also confusing to the user who won't understand why the visual cues are changing. > 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. Its a tangent from finding out about after-load-list. > I think its best not to lead users anywhere than up the garden path. > > Meaning? I don't agree with you. > Example? What you are suggesting. > 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? If a link is inappropriate, quotes aren't used in the doc string. Preceding the symbol name with the keyword `variable', 'function' etc ensures that the correct link is made. > > 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. If the doc strings were marked up for links in the indiscriminate way that variable values are , every `if' and `or' would be linked. Nick