Re: doc elisp intro cross reference fixes

[Stefan Monnier]

> If nothing else, there is still one problem we have to take care of,
> namely the change mentioned in the NEWS:

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

> This change should be reversed.

> Not only does it not take custom-add-to-group and the second argument
> to defcustom into account, it clearly assumes that even the most
> inappropriate group is better than no group whatsoever.

It was made not for the case where the author forgot the :group (which is
a rare and unimportant occurence AFAIK), but for the case where the author
is tired of putting the redundant :group argument for his package
foo-mode.el which begins by declaring a group `foo' and then goes on to
declare a couple defcustoms which obviously can only belong in the `foo'
group unless stated otherwise.
As for the case where the author explicitly wanted the defcustom
to not be in any group, I think this is unusual enough that it deserves
a more explicit way to express it.  For example by specifying something
like `:group 'nogroup' or `:group nil'.

> If somebody would have chosen a group for `eval-expression-print-level',
> `kill-read-only-ok' or `yank-excluded-properties', using one of the
> alternative (and documented) possibilities, then there would have been
> no reason to put them in the "paren-blinking" group too, just to make
> absolutely sure that they are in at least one group.  Seeing such options
> in the "paren-blinking" group would be confusing to the Custom user.

1 - I see no reason whatsoever to use something else than :group
    in those cases (it's a preloaded file after all).  Better yet,
    only using custom-add-to-group or listing the things in the defgroup
    would IMHO be bad style.
    Custom-add-to-group is typically used internally (by code that extracts
    it from the defcustom as in autoload.el for example).
    And explicit lists in defgroup are usually only used to
    add pre-existing defcustoms (which typically already belong to some other
    group) to a new group.
2 - Maybe the code you want to remove should indeed by amended so it
    does not try to "guess" in the case where there have been several
    defgroups in the file already.


        Stefan