RE: hyperlinks in variable's value - links to libraries

[Nick Roberts]

 > 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