RE: master 2a7488d: Add support for displaying short documentation for function groups

[Drew Adams]

> > But you also said that you think we cannot provide such links
> > automatically.  And my response to that is that we can.  And I have.
> 
> We can in theory, but it would be too inefficient, as you said yourself.
> I think that checking the indexes of the sixty info files whenever a
> *Help* buffer is opened is not feasible.

That's not what happens.

The default behavior is to use `info-lookup-symbol'.
That's immediate.  It produces the link in *Help*
immediately, and when you click the link it
immediately goes to one of the manuals.

An alternative behavior also immediately produces
the link in *Help*.  But when you click the link
it accesses the Indexes of the manuals and takes
you to an Info Index with links to the manuals.
This alternative can give you a link to more than
one manual.  That's its advantage, but at the cost
of index lookups when you click the link.

Again, that's not the default behavior.

> >> See also the following manual chapters: for interactive use, see
> >> `(emacs) Buffers'; for Emacs Lisp programming use, see `(elisp)
> >> Buffers'.
> >
> > the `manuals' link gives you an Info Index buffer
> > with these two links:
> >
> > * kill-buffer [elisp]:   (elisp)Killing Buffers. (line 31)
> > * kill-buffer [emacs]:   (emacs)Kill Buffer. (line 22)
> >
> > I think those are more appropriate targets than your `Buffers' nodes.
> 
> I do not think so.  Remember that what triggered my proposal was a
> question by RMS: how to make manuals easier to access by newcomers.  If
> you provide these newcomers with three similar versions of the same
> information (the docstring of kill-buffer, the documentation of
> kill-buffer in the Emacs manual, the documentation of kill-buffer in the
> Emacs Lisp manual), they will not see the point of reading the manuals.
> If you point them to the beginning of a chapter, they will see something
> different, in which they can expect to (and will) find information about
> the context of the command or function, for example, what the related
> concepts are, and what other related functions can do.  A manual is a
> manual, not a dictionary.

We disagree about what manual pages the *Help* on
a command should link to.  And so far, at least,
the manual Indexes agree with me about this.  And
if the Indexes are ever changed to take you to the
chapter and not the more specific node, then the
same solution I proposed will do what you want.

IOW, the link should reflect our indexing.

> > And the inefficiency I referred to is likely from my insufficient
> > knowledge of using `info-lookup'.
> 
> I do not think so, but I would be happy to be proven wrong.  It seems to
> me that searching the indexes of sixty info files takes time.

With `help-fns+.el' users can control which manuals
to use.  And so can any library code: pick the
manuals to use according to some context etc.

`info-lookup-symbol' is _very_ quick.  Assuming it
can be made to work well with additional manuals,
which some have said is the case, and assuming it
can be made to return links to multiple manuals,
there would presumably be no naive index-lookup
such as what my code currently does.