emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: master 2a7488d: Add support for displaying short documentation for f


From: Gregory Heytings
Subject: RE: master 2a7488d: Add support for displaying short documentation for function groups
Date: Mon, 12 Oct 2020 16:50:44 +0000
User-agent: Alpine 2.22 (NEB 394 2020-01-19)



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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]