Re: doc elisp intro cross reference fixes

[Luc Teirlinck]

Stefan Monnier wrote:

   > In emacs-21.3, (defcustom a 4 "c") will give `a' value 4, but `a' will
   > not get a custom group and `customize-variable RET a' will say:

   > "Variable a cannot be customized"

   > (user-variable-p a) in emacs-21.3 returns nil

   Glad to see this is fixed in Emacs-CVS.

It is definitely not "fixed".  First there is a decision to be made on
whether (defcustom myvar myval "mydoc") without any keywords is
stylistically legitimate or not, and if yes, in which situations.  If
the anwer is no, the compiler could issue a warning, which it
currently does not.  If the answer is yes, various other things would
need to be done, on which I would elaborate if "yes" would seem to be
the likely decision.

Currently the Elisp manual says that a defcustom should have at least
a :group and a :type keyword.

The NEWS contains:

    ** defcustom and other custom declarations now use a default group
    (the last group defined in the same file) when no :group was given.

But this seems just like an extremely unreliable heuristic to try to
remedy bugs and omissions on an automated basis, which, of course,
can not yield reliable results.

Of the four current members of the `nil' group,
`ada-tight-gvd-integration' seems to clearly belong in the ada group
and either `nnimap-authinfo-file' and `nnimap-prune-cache' belong in a
new nnimap group and `nntp-authinfo-file' belongs in a new `nntp'
group or maybe they are sufficiently related to nnmail to go into the
nnmail group.  (I do not know, but somebody who knows more about that
stuff than I do will know.  Should we not contact the respective
maintainers?)  As long as these options stay in the `nil' group, we
could quite as well give them defvars.  Most users will browse the ada
or gnus groups (and subgroups) and never find out about their
existence.

Maybe that `nil' group is useful to catch bugs, but could it
legitimately be non-empty?

Sincerely,

Luc.