Re: doc elisp intro cross reference fixes

[Luc Teirlinck]

Per Abrahamsen wrote:

   I'd vote (0): if there is no group specified, don't put it in any
   group.

That is exactly what I described under (1).

   The option may very well end up in a group anyway (explicit call to
   custom-add-to-group or the second argument to defgroup), but if it
   doesn't don't worry about it.

I somehow forgot about those possibilities.  There is, at closer
reading, indeed nothing, even in the current Elisp manual, that says
that a defcustom should have a :group.  The manual seems to suggest
that every option should wind up in at least one group (which can
indeed be achieved in a variety of ways, it does not have to be done
by specifying :group), and even that suggestion could be reversed.

   Having options that aren't in any group doesn't break anything, and
   we have already spend way to much energy on this non-problem.

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.

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.

Sincerely,

Luc.