Re: nil has a plist, of course.

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?

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.0 (GNU/Linux) iD8DBQFFe0mTlMmhrILJOQ4RAvrTAJ0U3jNtKpTzEWBvFECGxdzzOiRAMgCfayD7 6gAW2ZE96pWdFBXv7AVkqT8= =6Eek -----END PGP SIGNATURE-----