RE: Shouldn't custom.el load wid-edit.el?

[Drew Adams]

>     But it means that `defcustom' does not recognize those
>     built-in Emacs types that wid-edit.el defines.
>
> What do you mean, "recognize"?  In what sense does `defcustom' need to
> "recognize" a type?  All it does is record the type to be used if and
> when you try to DO something with the variable later.  That is when
> we want wid-edit.el to be loaded.

What type does it record? See the example I gave (repeated below). defcustom
_evaluates_ the :type sexp you give it. That means the defcustom needs to
recognize the set of basic types at that time, in order to eval that sexp.
(It's not unlikely that the sexp for a :type involves existing types.)

Here again is the example:

> I did this, to let some code work also in older Emacs versions
> that don't define type `color':
>
> (defcustom... :type (if (get 'color 'widget-type)
>                         'color
>                       'string)
>  ...)
>
> I was surprised to find that in Emacs 22 also the type was `string'.
>
> The problem was that the widget `color' is defined in
> wid-edit.el, which was not loaded. So I now do this, which
> seems a bit heavy-handed for user code:
>
> (defcustom... :type (if (and (require 'wid-edit nil t)
>                              (get 'color 'widget-type))
>                         'color
>                       'string)
>  ...)

IOW, it is currently up to the user to teach defcustom what its own basic
:type's are (that is, what the Emacs basic types are) so that it can eval
the :type sexp. Shouldn't it be the other way around - shouldn't defcustom
be helping the user in this regard?

I think the problem is this: types in Emacs, and the type-checking code, are
currently packaged up with the Widget UI and the Customize UI code.

You are right that code that deals with creating and managing widgets as UI
thingies should not need to be loaded until we actually need to create and
use those UI thingies. The problem is that we should be able to use types
and check them, regardless of whether (that is, before) we make use of such
a UI.

IOW, I agree with the logical separation you mention wrt load time, but, to
do that and also still make types available normally, the code would need to
be refactored. Unless someone is up to that task, we should just load
wid-edit.el for defcustom to be able to interpret :type sexps with knowledge
of Emacs types. Currently, defcustom is not dealing with a full deck.