nil has a plist, of course.

[Sebastian Freundt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> Sebastian Freundt writes:
>
>  > > Question: Should we *require* that customizations be in a group (ie,
>  > > defcustom barfs if there's no :group argument and (custom-current-group)
>  > > is nil)?  Or should we force `custom-current-group' to return something
>  > > global like 'xemacs rather than nil?  Or should we allow anti-social
>  > > customizations, that avoid all groups?
>
>  > How about a mild mixture between 2 and 1? Instead of barfing I think about
>  > a warning or something.
>
> What I was thinking is that *users* get the warning, but the *source
> code*, not a user configuration, is what needs fixing.  If we error,
> then it will get fixed, because users (presumably including the
> developer!) will be unable get work done.  If we're not going to force
> it to be fixed, then I think we should force the customization into a
> real group, where people will see it.
>
> Perhaps a byte-compiler warning would be suitable, then.  But many
> packages throw tons of warnings, and it would probably be ignored.
>
> What do you think?

After a whole day of grepping and investigating lisp code, I've come to
the conclusion that your pedantic approach is definitely the way to go.
There is no (wide-spread) code which is going to break suddenly.

The fallback is still a good idea for a, say, transition time.

Sebastian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.0 (GNU/Linux)

iD8DBQFFe0mTlMmhrILJOQ4RAvrTAJ0U3jNtKpTzEWBvFECGxdzzOiRAMgCfayD7
6gAW2ZE96pWdFBXv7AVkqT8=
=6Eek
-----END PGP SIGNATURE-----