nil has a plist, of course.
Sebastian Freundt
hroptatyr at sxemacs.org
Thu Dec 7 13:33:16 EST 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
"Stephen J. Turnbull" <stephen at xemacs.org> writes:
> Aidan Kehoe writes:
>
> > And on two non-vanilla invocations of mine it’s non-nil. These seem like
> > bugs:
>
> Easy to reproduce:
>
> (with-temp-buffer ;; let's not be visting a file
> (defcustom junk nil "junk custom")
> (assq 'junk (cadr (object-plist nil))))
> => (junk custom-variable)
>
> Easy to prevent:
>
> (with-temp-buffer
> (defgroup trash-group nil "just for laughs")
> (defcustom trash nil "trash custom")
> (cons (assq 'trash (cadr (object-plist nil)))
> (assq 'trash (cadr (object-plist 'trash-group)))))
> => (nil trash custom-variable)
>
> 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?
>
> I think option 2 is probably safest and least invasive, although the
> pedant in me hankers after option 1. Option 3 strikes me as rather
> risky given the general fragility of customize.
How about a mild mixture between 2 and 1? Instead of barfing I think about
a warning or something.
Sebastian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.0 (GNU/Linux)
iD8DBQFFeF57lMmhrILJOQ4RAuFbAJ9emMRwm/EPB7VOnSmCv9gE3nlTSQCgiPFM
sNJGPvRa2FaTiNpc9tYXqZw=
=5fx/
-----END PGP SIGNATURE-----
More information about the XEmacs-Beta
mailing list