bug#16271: warn about quoted const's in defcustom

bug#16271: warn about quoted const's in defcustom

[Glenn Morris]

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.

bug#16271: warn about quoted const's in defcustom

[Lars Ingebrigtsen]

Glenn Morris <rgm@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

bug#16271: warn about quoted const's in defcustom

[Drew Adams]

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

bug#16271: warn about quoted const's in defcustom

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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

bug#16271: warn about quoted const's in defcustom

[Andreas Schwab]

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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#16271: warn about quoted const's in defcustom

[Lars Ingebrigtsen]

Andreas Schwab <schwab@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

bug#16271: warn about quoted const's in defcustom

[Drew Adams]

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