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

[Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>]

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

>
> So far, we have _VERY_ few manually provided links. Nothing is stopping 
> someone from proposing adding this or that link manually.  Still, we 
> have very few, so far.
>

It was the meaning of my proposal.  Now it has to be done, of course. 
But for this there needs to be an agreement that it's a good thing to do.

>> For example, the docstring of kill-buffer would have two links, one to 
>> (info "(emacs)Buffers") and another one to (info "(elisp)Buffers"), 
>> with some explanation.  For example:
>>
>> See also the following manual chapters: for interactive use, see 
>> `(emacs) Buffers'; for Emacs Lisp programming use, see `(elisp) 
>> Buffers'.
>
> And for `kill-buffer' 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.

>
> They're different, yes, but not profoundly different.
>

It depends how you define profound ;-)

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