From: Ruijie Yu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Drew Adams <drew.adams@oracle.com>
Cc: "63410@debbugs.gnu.org" <63410@debbugs.gnu.org>
Subject: bug#63410: 30.0.50; [FR] Optionally allow defcustom to check type for standard value
Date: Wed, 10 May 2023 22:51:14 +0800 [thread overview]
Message-ID: <sdvmt2c9r4t.fsf@netyu.xyz> (raw)
In-Reply-To: <SJ0PR10MB5488220DD9597357CE80230FF3779@SJ0PR10MB5488.namprd10.prod.outlook.com>
Drew Adams <drew.adams@oracle.com> 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
next prev parent reply other threads:[~2023-05-10 14:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-10 5:22 bug#63410: 30.0.50; [FR] Optionally allow defcustom to check type for standard value Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-10 13:36 ` Drew Adams
2023-05-10 14:51 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-05-10 15:40 ` Eli Zaretskii
2023-05-11 2:25 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-11 14:08 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sdvmt2c9r4t.fsf@netyu.xyz \
--to=bug-gnu-emacs@gnu.org \
--cc=63410@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
--cc=ruijie@netyu.xyz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).