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