Subject: bug#63410: 30.0.50; [FR] Optionally allow defcustom to check type for standard value

From: Ruijie Yu <[email-masked]>
Date: Wed, 10 May 2023 22:51:14 +0800

Drew Adams <[email-masked]> writes:

>> Similar to `setopt' introduced in 29, which warns when a variable gets
>> assigned a value with an incorrect type, I hope `defcustom' can
>> (optionally) check that the standard value of a customizable variable is
>> correct.  This would help external as well as internal package authors
>> to catch errors on the types.
>
> Not sure I understand.  Doesn't it do that already,
> showing "mismatch" next to the default value if it
> doesn't match the type definition?

Yes, it does, but I think it is not "automated" enough, since you would
have to go over the variables one at a time.

My request is that Emacs should (optionally, maybe behind a defcustom,
or configure, or cli flag, etc.) warn you warn a defcustom's standard
value does not match its declared type.  Since a similar warning is
already in place for `setopt', I don't think it is farfetched to request
`defcustom' to follow suit.

Alternatively, or in addition to the above, maybe provide a
function/command that checks types for a group+subgroups, or for all
defined customizable variables.  Again, this would help package authors
to catch typing errors which would otherwise be quite difficult to
catch.

As I mentioned upthread, using `setopt' directly like the following
snippet is unnecessarily expensive: it calls the :set function of a
customizable variable, where the only thing we want is to check its
type.

```emacs-lisp
(defcustom expensive-var t
  :type 'string
  :set (lambda (n v)
         (dotimes (_ 424242) 'expensive)
         (set n v)))
(setopt expensive-var expensive-var)
;; warns the user that the type is correct, but only after spending a
;; long time in the :set function
```

-----

Let me also explain the reason behind this request.  I have encountered
this scenario multiple times, where when I `setopt' something for a
customizable variable according to its docs, I get a warning saying that
the type is incorrect.  Examples of this scenario include eshell, mu4e,
and pyim.

Seeing this type of warning would prompt me to examine the entire
package in which the warning occurs.  I would have to rgrep the entire
package, and examine the types of each defcustom one-by-one, fixing all
type errors along the way.  When I encounter difficult-to-parse types I
would do the `(setopt var var)' method to save time and brain cells.

And here comes my feature request.  We have the warning in `setopt'; we
have some visual indication in the customization view; and I want to
have one more: to know when a defcustom call defines a wrongly-typed
standard value.

-- 
Best,

RY