Sebastian Freundt writes:
> Question: Should we *require* that customizations be in a group
> 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
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?
XEmacs-Beta mailing list