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

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

[Drew Adams]

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) ...)

Shouldn't custom.el, which defines `defcustom', load wid-edit.el? How else
can :type reasonably deal with types such as `color' that are defined in
wid-edit.el?

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

[Richard Stallman]

    Shouldn't custom.el, which defines `defcustom', load wid-edit.el?

No!  We don't want to load wid-edit.el all the time.
We only load that when people start to make widgets.

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

[Lennart Borgman (gmail)]

Richard Stallman wrote:
>     Shouldn't custom.el, which defines `defcustom', load wid-edit.el?
> 
> No!  We don't want to load wid-edit.el all the time.
> We only load that when people start to make widgets.

I do not know what you want at the moment, but I have this comment in 
color-test-sent.el

   (require 'wid-edit) ;; for widget-convert, but why is not that in 
widget.el?

Is it widget-convert you want, or?

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

[Drew Adams]

>     Shouldn't custom.el, which defines `defcustom', load wid-edit.el?
>
> No!  We don't want to load wid-edit.el all the time.
> We only load that when people start to make widgets.

But it means that `defcustom' does not recognize those built-in Emacs types
that wid-edit.el defines. Does it make sense that `defcustom' does not
recognize a predefined type such as `color' during the evaluation of its
:type sexp? For most Emacs users and Elisp programmers, :type is a
`defcustom' thing, not a widget thing - that's where they run into it.

`defcustom' predefined types are also widgets, and some of those are defined
in wid-edit.el.  custom.el doesn't stand on its own. Users, including
programmers, will expect `defcustom' types to be known by, well,
`defcustom'.

To repeat my question:

>> How else can [defcustom's] :type reasonably deal with types such
>> as `color' that are defined in wid-edit.el?

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

[Drew Adams]

> >     Shouldn't custom.el, which defines `defcustom', load wid-edit.el?
> >
> > No!  We don't want to load wid-edit.el all the time.
> > We only load that when people start to make widgets.
>
> I do not know what you want at the moment, but I have this comment in
> color-test-sent.el
>
>    (require 'wid-edit) ;; for widget-convert, but why is not that in
>                        ;; widget.el?
>
> Is it widget-convert you want, or?

No. See my reply to Richard. I am not calling `widget-convert' or engaging
in any explicit widgetry at all. I just wrote a simple `defcustom'.

All I want is for `defcustom's :type expression to recognize the standard
types that are defined for Emacs by wid-edit.el - for example, `color'. It's
not a good thing for standard types not to be recognized by :type.

How the problem is fixed is a different problem. That you might not want to
load all of wid-edit.el unnecessarily is understandable. But it's not a
reason not to solve the problem (perhaps in another way).

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

[Richard Stallman]

    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.

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.

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

[Richard Stallman]

    What type does it record? See the example I gave (repeated below). defcustom
    _evaluates_ the :type sexp you give it.

Which is nearly always a constant.

     That means the defcustom needs to
    recognize the set of basic types at that time, in order to eval that sexp.

It just records the value.  It doesn't have to check it at all.

    > 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)
    >  ...)

That is a very strange thing to do.  If it works, ok.
If it doesn't, that isn't a bug.