-----BEGIN PGP SIGNED MESSAGE-----
"Stephen J. Turnbull" <stephen(a)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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.0 (GNU/Linux)
-----END PGP SIGNATURE-----
XEmacs-Beta mailing list