From: Drew Adams <drew.adams@oracle.com>
To: Harald Hanche-Olsen <hanche@math.ntnu.no>, 23258@debbugs.gnu.org
Subject: bug#23258: 25.1.50; The docstring of with-eval-after-load needs improvement
Date: Sun, 10 Apr 2016 09:21:46 -0700 (PDT) [thread overview]
Message-ID: <6ba754ce-e37a-4334-a48c-64b55f506ed4@default> (raw)
In-Reply-To: <etPan.5709f5fd.7dff2e17.de73@math.ntnu.no>
> The docstring for with-eval-after-load gives only a cursory description
> of the FILE argument. The docstring of the wrapped function eval-after-
> load, however, is much more comprehensive. It should either be included
> in the docstring of with-eval-after-load, or the docstring for with-eval-
> after-load should refer the reader to eval-after-load for further
> details. (The latter option is far better, IMO.)
>
> As evidence of the harm done by the incomplete documentation, I offer
> this link:
>
> http://emacs.stackexchange.com/q/21540/962
+1 (Thank you, Harald.) Let me add a bit about this doc.
AFAICT, there was no great need for creating this macro
(and essentially telling users to prefer it over function
`eval-after-load'). The "need" seems to have been only the
fact that some users were not quoting arguments that they
did not want to have evaluated.
But having done that, whoever did it seems to have dropped
the ball wrt documenting it. At the least, its doc should
refer to `eval-after-load' (and vice versa presumably).
As for the changes that were made to the doc string of
`eval-after-load' at the same time:
1. This mystery sentence was added - at the very top, no less:
This function has a compiler macro.
I had to search the source code to find out what that is
meant to mean - means for a function to have a "compiler
macro", and even what a "compiler macro" is.
And having found property `compiler-macro' used in the
source code, I had to search the Elisp manual for that
(there is no index entry for it). Finally, I found some
light in node `Declare Form'.
It cannot be clear to readers of `C-h f eval-after-load'
what that mystery sentence is for. If we are going to
include mention of this we should use English to get across
the real point, which is presumably to say that a call to
the function might be expanded by the compiler in different
ways.
I admit that I still do not understand why we would tell
users this in `C-h f' output. And perhaps I still do not
fully grasp the message. What seems clear to me is that
most users will have NO CLUE what this mystery sentence
(again, at the top of the help output, no less) is trying
to tell them, much less why it is (or isn't) important.
2. FORM can now be a function, and what it can be is described
before the description of what FILE can be. These are out
of order. (OK, not very important.)
As for the doc in the Elisp manual: `eval-after-load' is no
longer even mentioned, except for these nodes: (1) `Hooks for
Loading`, (2) `Coding Conventions', and (3) `Named Features'.
The doc should be cleaned up to be coherent. And (IMHO) it
_should_ document `eval-after-load' - far more important than
documenting `with-eval-after-load'. Mentioning the latter
does not replace describing the former.
1. Node `Hooks for Loading` says:
Normally, well-designed Lisp programs should not use
‘eval-after-load’....
Perhaps it meant to say `with-eval-after-load' here?
If not, why not?
2. Node `Coding Conventions' says:
Avoid using ‘eval-after-load’ in libraries and packages
(*note Hooks for Loading::). This feature is meant for
personal customizations; using it in a Lisp program is
unclean...
Again, why only `eval-after-load' for such a caution, and
not (also) `with-eval-after-load'?
3. Node `Named Features' says:
The direct effect of calling ‘provide’ is if not already
in FEATURES then to add FEATURE to the front of that list
and call any ‘eval-after-load’ code waiting for it (*note
Hooks for Loading::).
Now clearly it is correct to speak of `eval-after-load'
here, and not `with-eval-after-load'. But is the same not
true pretty much everywhere? Ultimately, the _behavior_
is that of `eval-after-load' - `with-eval-after-load' is
only a wrapper.
Finally, the Emacs manual makes no reference to either the
macro or the function, except for this, in node `Foldout':
To use the Foldout package, you can type ‘M-x load-library
<RET> foldout <RET>’; or you can arrange for to do that
automatically by putting the following in your init file:
(eval-after-load "outline" '(require 'foldout))
Is that mention appropriate, or should it be removed?
What's so special about library `foldout.el' in this regard?
next prev parent reply other threads:[~2016-04-10 16:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-10 6:43 bug#23258: 25.1.50; The docstring of with-eval-after-load needs improvement Harald Hanche-Olsen
2016-04-10 16:17 ` Eli Zaretskii
2016-04-10 16:38 ` Harald Hanche-Olsen
2016-04-10 16:44 ` Eli Zaretskii
2016-04-10 16:21 ` Drew Adams [this message]
2016-04-10 16:41 ` Eli Zaretskii
[not found] <<etPan.5709f5fd.7dff2e17.de73@math.ntnu.no>
[not found] ` <<83mvp1h20l.fsf@gnu.org>
2016-04-10 16:26 ` Drew Adams
2016-04-10 16:42 ` Eli Zaretskii
[not found] ` <<6ba754ce-e37a-4334-a48c-64b55f506ed4@default>
[not found] ` <<83inzph0ve.fsf@gnu.org>
2016-04-10 18:14 ` Drew Adams
[not found] <<<etPan.5709f5fd.7dff2e17.de73@math.ntnu.no>
[not found] ` <<<83mvp1h20l.fsf@gnu.org>
[not found] ` <<84fc8455-9d8a-4ccd-b606-21749743cdb3@default>
[not found] ` <<83h9f9h0tt.fsf@gnu.org>
2016-04-10 18:49 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6ba754ce-e37a-4334-a48c-64b55f506ed4@default \
--to=drew.adams@oracle.com \
--cc=23258@debbugs.gnu.org \
--cc=hanche@math.ntnu.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.