GNU bug report logs - #16271
warn about quoted const's in defcustom

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16271 in the body.
You can then email your comments to 16271 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #3 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: submit <at> debbugs.gnu.org
Subject: warn about quoted const's in defcustom
Date: Fri, 27 Dec 2013 21:20:36 -0500

Package: emacs
Severity: wishlist

The argument of a `const' (or `other') inside a defcustom type should
(almost always) not be quoted. Yet people keep doing it.
It would be nice if there was some way to warn about this.

Message #6 received at 16271 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 16271 <at> debbugs.gnu.org
Subject: Re: bug#16271: warn about quoted const's in defcustom
Date: Tue, 10 May 2022 18:32:16 +0200

Glenn Morris <rgm <at> gnu.org> writes:

> The argument of a `const' (or `other') inside a defcustom type should
> (almost always) not be quoted. Yet people keep doing it.
> It would be nice if there was some way to warn about this.

Yes, that would be nice, so I've now implemented it.  However, there's
one false positive:

(defcustom erc-button-alist
  '(('nicknames 0 erc-button-buttonize-nicks erc-nick-popup 0)

[...]

                (choice :tag "Matches"
                        regexp
                        (variable :tag "Variable containing regexp")
                        ;; FIXME It really does mean 'nicknames
                        ;; rather than just nicknames.
                        (const :tag "Nicknames" 'nicknames))

And this really means 'nicknames.  Anybody got any suggestions how to
work around that?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 16271 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Glenn Morris <rgm <at> gnu.org>
Cc: "16271 <at> debbugs.gnu.org" <16271 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#16271: warn about quoted const's in defcustom
Date: Tue, 10 May 2022 16:41:15 +0000

> > The argument of a `const' (or `other') inside a defcustom type should
> > (almost always) not be quoted. Yet people keep doing it.
> > It would be nice if there was some way to warn about this.
> 
> Yes, that would be nice, so I've now implemented it.  However, there's
> one false positive:
> 
> (defcustom erc-button-alist
>   '(('nicknames 0 erc-button-buttonize-nicks erc-nick-popup 0)
> ...
>       (choice :tag "Matches"
>               regexp
>               (variable :tag "Variable containing regexp")
>               ;; FIXME It really does mean 'nicknames
>               ;; rather than just nicknames.
>               (const :tag "Nicknames" 'nicknames))
> 
> And this really means 'nicknames.  Anybody got any suggestions how to
> work around that?

Don't work around it.
Don't try to warn not to quote.

In (elisp) `Composite Types', (1) mention that
you typically do not want to quote, and (2)
show an example of the exception, with a quote,
saying what the behavior is in that case.

Warnings are not appropriate here, and will
likely confuse.  Making the case clear in the
doc is helpful.

Message #14 received at 16271 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 16271 <at> debbugs.gnu.org
Subject: Re: bug#16271: warn about quoted const's in defcustom
Date: Wed, 11 May 2022 12:53:24 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> And this really means 'nicknames.  Anybody got any suggestions how to
> work around that?

I just changed that form, since it seemed pretty nonsensical anyway.

I've now pushed this checker to Emacs 29, and it found a handful of
wrongly quoted symbols, which I've also fixed.

However, as the 'nicknames thing shows, there may be legitimate usages
of the 'foo form, so perhaps the checker should be hidden behind a user
option.  But I guess we'll find out.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #19 received at 16271 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 16271 <at> debbugs.gnu.org
Subject: Re: bug#16271: warn about quoted const's in defcustom
Date: Wed, 11 May 2022 14:32:43 +0200

On Mai 11 2022, Lars Ingebrigtsen wrote:

> I just changed that form, since it seemed pretty nonsensical anyway.

Doesn't that break existing customisations?

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #22 received at 16271 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 16271 <at> debbugs.gnu.org
Subject: Re: bug#16271: warn about quoted const's in defcustom
Date: Wed, 11 May 2022 15:02:26 +0200

Andreas Schwab <schwab <at> linux-m68k.org> writes:

> Doesn't that break existing customisations?

Yup; I've now added some compat code which should fix this, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #25 received at 16271 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Glenn Morris <rgm <at> gnu.org>
Cc: "16271 <at> debbugs.gnu.org" <16271 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#16271: warn about quoted const's in defcustom
Date: Wed, 11 May 2022 14:21:59 +0000

> > And this really means 'nicknames.  Anybody
> > got any suggestions how to work around that?

Suggestions given.  And ignored.

> I just changed that form, since it seemed pretty
> nonsensical anyway.

Clearly that doesn't solve the problem at all.

The problem is not the existence of that code
in Emacs.  The problem is the lack of good
help regarding the possible values.

And a quoted symbol (more generally, a quoted
sexp) is perfectly fine as a value, here.
Not typical, but fine.

Whether vanilla Emacs code contains such an
example is 100% irrelevant.  Removing that
code in order to avoid a warning message is,
well, misguided.

That just masks/hides the problem.

But it also points to the fact that using a
_warning_ to solve the problem is misguided.

The problem is insufficient communication to
users of what the possible values are.

And in particular, that (1) you typically use
a value without quoting it, AND (2) you can
use a quoted sexp if you in fact want the
value that's used to be a quoted sexp.

To communicate that information a warning is
(1) inappropriate - there's nothing to "warn"
about, and (2) insufficient - no simple
warning text will make clear what's involved.

There's _no substitute_ for documenting this
properly in the manual.  Include an example.

That there's no substitute for documenting
this in the manual doesn't mean that other
help can't also be provided somehow, somewhere.
But not a _warning_.  That's counter-productive
and misleading.

> I've now pushed this checker to Emacs 29, and 
> it found a handful of wrongly quoted symbols,
> which I've also fixed.

If they were truly wrongly quoted, great.
But irrelevant to fixing this problem, which
is one of helping users understand.

Misses the point altogether.  It doesn't tell
users about either of (1) and (2).  Instead,
it suggests something else - that there's
actually something to _warn_ about.

> However, as the 'nicknames thing shows, there
> may be legitimate usages of the 'foo form, so
> perhaps the checker should be hidden behind a
> user option.

Of course there are legitimate uses.  And no,
nothing about this should be hidden behind a
user option.

> But I guess we'll find out.

Maybe in another decade or two this will get
handled properly.  Or not.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.