hyperlinks in variable's value - links to libraries

hyperlinks in variable's value - links to libraries

[Drew Adams]

Between April and June 2005, the code in help-fns.el that defines
`describe-variable' had this line commented out, with this comment:

;; Hyperlinks in variable's value are quite frequently
;; inappropriate e.g C-h v <RET> features <RET>
;; (help-xref-on-pp from (point))

mea culpa - I think I might have been the one to report the bug that the
links in the value of `features' were inappropriate. What I said, however,
was that they should instead be links to the libraries, not links to
something else that happened to have the same name as a library (which was
the "inappropriate" part).

In any case, I disagree with the "fix" of commenting out this line - at the
least, I would like such links to be an option.

In fact, I have a tiny library that does only this: add links to libraries.
This is the entire library (below). I'd suggest it or the equivalent as a
patch. However, adding such links can be slow, so I would like to see an
option for adding links to libraries.

Although it can be slow, it is very useful: if you're checking `features',
for instance (though this is not the only place such links would appear),
you want to know not only if a given library has been loaded, but you (I, at
least) sometimes want to then open one of those libraries. IOW, looking at
`features' should be an entry point to accessing the features listed.

Needless to say, if `describe-variable' is not changed back by uncommenting
that line, I'll also need to add a redefinition of `describe-variable' to my
little library...

---8<--------------------

;; REPLACES ORIGINAL IN `help-mode.el'.
;; Buttonizes names of libraries also.
;; To see the effect, try `C-h v features', and click on a library name.
;;
(defun help-xref-on-pp (from to)
  "Add xrefs for symbols in `pp's output between FROM and TO."
  (if (> (- to from) 5000) nil
    (with-syntax-table emacs-lisp-mode-syntax-table
      (save-excursion
	(save-restriction
	  (narrow-to-region from to)
	  (goto-char (point-min))
	  (condition-case nil
	      (while (not (eobp))
		(cond
		 ((looking-at "\"") (forward-sexp 1))
		 ((looking-at "#<") (search-forward ">" nil 'move))
		 ((looking-at "\\(\\(\\sw\\|\\s_\\)+\\)")
		  (let* ((sym (intern-soft (match-string 1)))
			 (type (cond ((fboundp sym) 'help-function)
				     ((or (memq sym '(t nil))
					  (keywordp sym))
				      nil)
				     ((and sym (boundp sym))
				      'help-variable)
                                     ((and sym (locate-library (symbol-name
sym)))
                                      'help-library))))
		    (when type (help-xref-button 1 type sym)))
		  (goto-char (match-end 1)))
		 (t (forward-char 1))))
	    (error nil)))))))

(define-button-type 'help-library
  :supertype 'help-xref
  'help-function #'(lambda (x) (find-library (symbol-name x)))
  'help-echo (purecopy "mouse-2, RET: find this library"))

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

[Drew Adams]

Resending. Shall I assume no one is interested?

      ;; Hyperlinks in variable's value are quite frequently
      ;; inappropriate e.g C-h v <RET> features <RET>
      ;; (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.
    
    Although it can be slow, it is very useful: looking at `features'
    should be an entry point to accessing the features listed.    

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

[Stefan Monnier]

> Resending. Shall I assume no one is interested?

>       ;; Hyperlinks in variable's value are quite frequently
>       ;; inappropriate e.g C-h v <RET> features <RET>
>       ;; (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.
    
>     Although it can be slow, it is very useful: looking at `features'
>     should be an entry point to accessing the features listed.    

I originally coded up the help-xref-on-pp feature.

I think it was a good feature, except that it didn't work quite right: it
sometimes added "spurious" xrefs and other times missed good xrefs.
Also it significantly slows down the construction of the *Help* text, so
much so that we had to put an arbitrary limit (hard coded at 5000 chars
right now) above which the highlighting is disabled.

So I added another feature, which is that clicking mouse-2 anywhere in the
buffer (not just on a visually announced xref with mouse-face highlight and
everything) will try to interpret the symbol under point as a var-name,
fun-name, or face-name.  This has the advantage of working no matter how
large the output is.  It also works in the docstrings where the author forgot
to mark symbols with `...'.
The main disadvantage of course is the lack of visual cue which makes this
feature barely known.


        Stefan

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

[Lennart Borgman]

Stefan Monnier wrote:

>So I added another feature, which is that clicking mouse-2 anywhere in the
>buffer (not just on a visually announced xref with mouse-face highlight and
>everything) will try to interpret the symbol under point as a var-name,
>fun-name, or face-name.  This has the advantage of working no matter how
>large the output is.  It also works in the docstrings where the author forgot
>to mark symbols with `...'.
>The main disadvantage of course is the lack of visual cue which makes this
>feature barely known.
>  
>
And that it does not work from the keyboard. Could it perhaps be made to 
work from the keyboard too?

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

[Drew Adams]

    >       ;; Hyperlinks in variable's value are quite frequently
    >       ;; inappropriate e.g C-h v <RET> features <RET>
    >       ;; (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.

    >     Although it can be slow, it is very useful: looking at `features'
    >     should be an entry point to accessing the features listed.

    I originally coded up the help-xref-on-pp feature. I think it was a
    good feature, except that it didn't work quite right: it
    sometimes added "spurious" xrefs and other times missed good xrefs.

Yes. And some of the spurious xrefs were library names that were instead
linked to descriptions of a variable or function with the same name.

    Also it significantly slows down the construction of the *Help* text,

Definitely.

    so much so that we had to put an arbitrary limit (hard coded at 5000
chars
    right now) above which the highlighting is disabled.

I think that's not a very good solution (arbitrary limit). See my other
message, where I propose adding the links only upon demand.

    So I added another feature, which is that clicking mouse-2
    anywhere in the buffer (not just on a visually announced xref with
    mouse-face highlight and everything) will try to interpret the symbol
    under point as a var-name, fun-name, or face-name.  This has the
    advantage of working no matter how large the output is.

I don't understand how this helps much. Are you saying that a lot of time
was spent actually adding the link faces (i.e. highlighting)? What I was
referring to was the time needed to look up the link destinations - in the
case of linking to libraries, `locate-library' can take a while.

    It also works in the docstrings where the author forgot
    to mark symbols with `...'. The main disadvantage of course is the
    lack of visual cue which makes this feature barely known.

Yes, that usability limitation is pretty important. I think having a `Show
Links' button would be a better solution: 1) The user would know (could be
informed ahead of time) that the link display might take a moment. 2) The
resulting links would be visible (e.g. underlined).

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

[Stefan Monnier]

>     So I added another feature, which is that clicking mouse-2
>     anywhere in the buffer (not just on a visually announced xref with
>     mouse-face highlight and everything) will try to interpret the symbol
>     under point as a var-name, fun-name, or face-name.  This has the
>     advantage of working no matter how large the output is.

> I don't understand how this helps much. Are you saying that a lot of time
> was spent actually adding the link faces (i.e. highlighting)? What I was
> referring to was the time needed to look up the link destinations - in the
> case of linking to libraries, `locate-library' can take a while.

When you middle-click, there's only one symbol to lookup, so even if it
takes "a while" it's instantaneous.  OTOH when you have to add xrefs
everywhere, you have to look at every single symbol and do the work there.

>     It also works in the docstrings where the author forgot
>     to mark symbols with `...'. The main disadvantage of course is the
>     lack of visual cue which makes this feature barely known.

> Yes, that usability limitation is pretty important.

I think the lack of keyboard and menu bindings is more important and easier
(aka trivial) to fix.
Note also that if you're looking at the value of `features' and feel like
visiting the library that provide "toto", you may want to simply do M-x
find-library RET toto RET.  It's not like adding xrefs is crucial, it's just
a convenience.


        Stefan

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

[Nick Roberts]

 > Resending. Shall I assume no one is interested?
 > 
 >       ;; Hyperlinks in variable's value are quite frequently
 >       ;; inappropriate e.g C-h v <RET> features <RET>
 >       ;; (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, not for someone to lobby to revert it.  I don't think it was
in response to a report you made and `features' was just an example, although
I can't remember the others.

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.

I think its best not to lead users anywhere than up the garden path.  The doc
strings on the other hand can be more carefully crafted to DTRT.

 >     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.  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.

Nick

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

[Drew Adams]

     >       ;; Hyperlinks in variable's value are quite frequently
     >       ;; inappropriate e.g C-h v <RET> features <RET>
     >       ;; (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).

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

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

[Drew Adams]

     > 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

Yes, of course. However, in practice, it works quite well. The problem of
multiple names of different types is pretty well handled by ordering
(priority) - see the code I sent. The problem of multiple features with
different names is not a problem in practice either, because those features
simply don't end up with links. Only features that are the names of
libraries are linked (to those libraries). That's 99+% of the features, BTW.

I've used this for quite a while, and I have yet to notice any problem.
Generally, you don't find a mix of other (e.g. variable, function) names
with library names. I'd encourage people to just try it, to see whether or
not it is worth it. By "worth it", I mean worth adding an option - not
forcing people to have links to libraries.

     > 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!

Yes.

    The idea is to make it easier, not harder

Precisely.

    to navigate the links.

Huh? If there are no links, then, it's hardly easier to navigate them (or
perhaps it is, vacuously ;-)).

Screaming that another option or button complicates things is a fine general
argument but a silly argument in any specific context. Just what is made
easier by the addition of the links, an option, and a toggle button? Just
what is made more difficult by their addition? It's a judgement call, of
course. It's worth discussing (weighing), IMO.

     > 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.

I think you're confusing caching a *Help* buffer for navigation forward and
backward (something I did not propose - but I wouldn't be against it) with
what I did propose: retaining the link information in the buffer as
displayed - that is, for the same *Help* screen text - across toggling of
the `Show/Hide Links' button. There are several ways that could be done. The
idea is simply to keep the links and faces there, but disable them (links)
and hide them (faces). Navigating to a different *Help* screen (different
text) would result in regeneration.

The cost for adding links is in calculating the link destinations and
creating the text properties or overlays. Once that's done, the links could
remain, but their appearance and enabling could be "neutralized", at no
added cost.

     ...
     >     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.

It's common on Web pages. If your mouse is always over one link or another
(e.g. in an image map or a dense table listing), and the mouseover indicates
it is a link, you don't need the text to be underlined without mouseover.

It may sound complicated to you, but thousands of ordinary folk seem to have
no problem with it everyday. It may be complicated to describe, but not to
use.

     > 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.

Sorry, I don't follow you at all - I have no idea what you're talking about.

     >     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.

Leading someone down the garden path means leading them astray - deceiving
them. How does what I suggest lead users astray? Please state your argument
more clearly; I'm not following you.

     >     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.

Are you perhaps saying that it is easier to just identify the terms to be
linked as those that are quoted, rather than trying to also link some terms
that are not quoted? That's certainly true. I don't know how well the trial
of linking variable etc. names worked - I haven't seen problems with it, but
I imagine there could be some. Maybe we need to experiment with it more.

    Preceding the symbol name with the keyword `variable', 'function' etc
    ensures that the correct link is made.

"Ensures"? No. It can help - but you can also get some anomalies with that
approach. Trying to insert links automatically in natural-language text is
bound to have some hiccups, no matter how it is done - I suppose we agree on
that. I haven't seen problems in practice, but I'm sure there would be some.
The question is whether such problems would outweigh the benefit. And see
below, on stopwords.

IIUC, you are mainly discussing ways to implement linking - how to identify
the proper text to which to apply a link. I am mainly discussing the value
of linking to libraries from their names. Different ways to identify the
proper names could be examined.

If nothing else, even if it were done as a one-off exception, I would like
to see the features that are also library names be linked to their libraries
when I do `C-h v features'. The value would be the same as having a link on
the library name in a function or variable description.

     >      >     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.

So, have a simple stopwords list. This is by no means an unsurmountable
problem. A surprisingly small stoplist filters out most insignificant
English words when indexing; the stopwords list for a programming language
would be much tinier yet.

Plus, I assume that we wouldn't choose to link from more than one occurrence
of the same word in the same *Help* buffer. That is, even without a
stoplist, only the first `if' and `or' would be linked.

And, again, I don't really care that much about linking symbol names other
than libraries. Just as you can click the word `abbrev' in "Defined in
abbrev" at the end of *Help* for `C-h v abbrev-mode', so I like being able
to click a library name in the value displayed by `C-h v features'. There is
no "every `if' and `or' would be linked" in that case.

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

[Nick Roberts]

 >     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
 > 
 > Yes, of course. However, in practice, it works quite well...

I don't think it does.

 > The problem of multiple names of different types is pretty well handled by
 > ordering (priority) - see the code I sent.

When I tried it it linked to a function if there was one, and only to a
library if there was no function with the same name.

 ...
 > Screaming that another option or button complicates things is a fine general
 > argument but a silly argument in any specific context.

I wasn't screaming but I probably I will end up doing so if I carry on, so
I'll stop now.

Nick

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

[Drew Adams]

     > Yes, of course. However, in practice, it works quite well...

    I don't think it does.

     > The problem of multiple names of different types is pretty
     > well handled by ordering (priority) - see the code I sent.

    When I tried it it linked to a function if there was one, and only to a
    library if there was no function with the same name.

Yes. I found that works well, in practice. The priority could be changed, of
course, but a function foo in a library foo is generally a tighter focus, so
a better bet on average.

This is the way the code already worked, for dealing with function and
variable names. I just added library names.

As I said, mixes of either function or variable names and library names are
uncommon in *Help* buffers. You might get the occasional foo function or
variable being linked to, instead of foo library, in the `features' list,
but that is not a big problem, because you still end up in the library code
(via one more link, "defined in foo").