unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: 36478@debbugs.gnu.org
Subject: bug#36478: 26.2; Doc strings with "This function has a compiler macro..." and "This function does not change global state"
Date: Tue, 2 Jul 2019 11:05:18 -0700 (PDT)	[thread overview]
Message-ID: <13f5f7df-9017-45a0-986f-8b1a4ee0e9bd@default> (raw)

`C-h f zerop' tells you this:

 zerop is a compiled Lisp function in 'subr.el'.

 (zerop NUMBER)

 This function has a compiler macro 'zerop--anon-cmacro'.

 Return t if NUMBER is zero.
 This function does not change global state, including the match data.

Why on earth would we put that info about the function having a compiler
macro before the first doc string line?

What does it even mean?  Searching for "compiler macro" in the Elisp
manual I find mention of it (in passing only) in node `Defining
Functions', but no definition of it.  And there's no index entry for it,
AFAICT.  Reading that node, I still don't know what "compiler macro"
really means.  Perhaps it means code that inlines a function definition
at byte-compilation time?

That whole node `Defining Functions' is pretty much incomprehensible
now, with the additions about ...inline....  Compare node `Inline
Functions', which is quite clear.

For example:

  Functions defined via 'define-inline' have several advantages with
  respect to macros defined by 'defsubst' or 'defmacro'...

Huh? `defsubst' defines macros?  I don't think so.

I think a node should probably be dedicated to `define-inline' or to
whatever it does.  The concepts really need to be developed.  Putting
this, whatever it is, in with `defun' in the main node about defining
functions does users, especially newbies, a disservice.

The help for a function (e.g. `zerop') should, after showing the
signature, start with the doc string, which says what the function does.
The help should not start by providing peripheral info about the
function.  Putting this info first doesn't follow Emacs longstanding
help convention.

Not to mention that if you click that `zerop--anon-cmacro' link you get
this:

 zerop--anon-cmacro is a compiled Lisp function in 'subr.el'.

 (zerop--anon-cmacro _ NUMBER)

 Not documented.

What's more: if you click the `subr.el' link you get nowhere that tells
you anything about `zerop--anon-cmacro' - there are no occurrences of
`zerop--anon-cmacro' in that file.

Wunderbar.  Thanks for the help, Emacs!

This is a real mess - doesn't help users.  Instead, it gets in their
way.  Please DTRT.  Either get rid of such obscurantism or put it at the
end of the `C-h f' output and fix its useless links.

---

In addition, why do we automatically add the following sentence to the
help (without even an intervening blank line), as if it were the second
doc-string line:

 This function does not change global state, including the match data.

Who asked for that?  Which functions get that added to their doc
strings?  Every function for which that's true?  I doubt that, and if
I'm right then the fact that some functions do get that added is
misleading.


In GNU Emacs 26.2 (build 1, x86_64-w64-mingw32)
 of 2019-04-13
Repository revision: fd1b34bfba8f3f6298df47c8e10b61530426f749
Windowing system distributor `Microsoft Corp.', version 10.0.17134
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''





             reply	other threads:[~2019-07-02 18:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-02 18:05 Drew Adams [this message]
2019-07-02 19:41 ` bug#36478: 26.2; Doc strings with "This function has a compiler macro..." and "This function does not change global state" Eli Zaretskii
2019-07-04  1:34 ` Richard Stallman
2022-02-02 18:55 ` Lars Ingebrigtsen
     [not found] <<13f5f7df-9017-45a0-986f-8b1a4ee0e9bd@default>
     [not found] ` <<83r278cjho.fsf@gnu.org>
2019-07-02 20:13   ` Drew Adams
2019-07-04  1:35     ` Richard Stallman

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=13f5f7df-9017-45a0-986f-8b1a4ee0e9bd@default \
    --to=drew.adams@oracle.com \
    --cc=36478@debbugs.gnu.org \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).