GNU bug report logs - #79208
[PATCH] (setq-default,setopt): Warn about unknown vars.

Previous Next

To reply to this bug, email your comments to 79208 AT debbugs.gnu.org.

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

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] (setq-default,setopt): Warn about unknown vars.
Date: Sun, 10 Aug 2025 13:05:08 +0200

[Message part 1 (text/plain, inline)]

Tags: patch

Hi,

This patch makes the byte-compiler (and by extension, Flymake), emit
warnings when setq-default and setopt are used to set the value of
unknown variables, similarly to the warnings we get with setq.

Ideally we should do something similar for setq-local, but AFAICT that
requires a different solution due to different implementation details.

[0001-setq-default-setopt-Warn-about-unknown-vars.patch (text/patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eshel Yaron <me <at> eshelyaron.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 79208 <at> debbugs.gnu.org
Subject: Re: bug#79208: [PATCH] (setq-default,
 setopt): Warn about unknown vars.
Date: Sun, 10 Aug 2025 14:59:37 +0300

> Date: Sun, 10 Aug 2025 13:05:08 +0200
> From:  Eshel Yaron via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> This patch makes the byte-compiler (and by extension, Flymake), emit
> warnings when setq-default and setopt are used to set the value of
> unknown variables, similarly to the warnings we get with setq.
> 
> Ideally we should do something similar for setq-local, but AFAICT that
> requires a different solution due to different implementation details.

Stefan, any comments?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: 79208 <at> debbugs.gnu.org
Subject: Re: bug#79208: [PATCH] (setq-default,
 setopt): Warn about unknown vars.
Date: Mon, 11 Aug 2025 04:53:21 -0400

> This patch makes the byte-compiler (and by extension, Flymake), emit
> warnings when setq-default and setopt are used to set the value of
> unknown variables, similarly to the warnings we get with setq.

I think this is probably OK for `setq-default` but for `setopt` I'm not
sure it's a good idea: `setopt` is expected to be rarely used in ELisp
packages and more often in user init files.  User init files normally
lack the "needed" `require`s to silence those warnings, so it risks just
increasing the amount of false positives.

We should try and come up with some way for the byte-compiler to emit
useful warnings when compiling init files, but AFAIK we don't have
that yet.

> Ideally we should do something similar for setq-local, but AFAICT that
> requires a different solution due to different implementation details.

Adding the warning for `setq-local` risks a similar problem: it's fairly
common for major modes to `setq-local` some vars for optional
third-party packages, which may not even be installed.  AFAIK we don't
really have a good answer for those problems either, the only "solution"
we have would be `with-suppressed-warnings`.


        Stefan

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 79208 <at> debbugs.gnu.org
Subject: Re: bug#79208: [PATCH] (setq-default,
 setopt): Warn about unknown vars.
Date: Mon, 11 Aug 2025 13:11:14 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> This patch makes the byte-compiler (and by extension, Flymake), emit
>> warnings when setq-default and setopt are used to set the value of
>> unknown variables, similarly to the warnings we get with setq.
>
> I think this is probably OK for `setq-default` but for `setopt` I'm not
> sure it's a good idea: `setopt` is expected to be rarely used in ELisp
> packages and more often in user init files.  User init files normally
> lack the "needed" `require`s to silence those warnings, so it risks just
> increasing the amount of false positives.

Indeed, it's likely to surface false positives, and we should try to
minimize those.  But especially in init files, it's important to warn
about typos in variable names, because users are more likely to be left
puzzled by such a mistake than people doing more serious development.

> We should try and come up with some way for the byte-compiler to emit
> useful warnings when compiling init files, but AFAIK we don't have
> that yet.
>
>> Ideally we should do something similar for setq-local, but AFAICT that
>> requires a different solution due to different implementation details.
>
> Adding the warning for `setq-local` risks a similar problem: it's fairly
> common for major modes to `setq-local` some vars for optional
> third-party packages, which may not even be installed.  

Hmm, is it really a different situation from setq?

> AFAIK we don't really have a good answer for those problems either,
> the only "solution" we have would be `with-suppressed-warnings`.

What about declaring these variables with unary defvar forms?
(Not perfect either, of course, but it is also a solution, no?)


Thanks,

Eshel

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: 79208 <at> debbugs.gnu.org
Subject: Re: bug#79208: [PATCH] (setq-default,
 setopt): Warn about unknown vars.
Date: Tue, 12 Aug 2025 04:09:57 -0400

>> I think this is probably OK for `setq-default` but for `setopt` I'm not
>> sure it's a good idea: `setopt` is expected to be rarely used in ELisp
>> packages and more often in user init files.  User init files normally
>> lack the "needed" `require`s to silence those warnings, so it risks just
>> increasing the amount of false positives.
> Indeed, it's likely to surface false positives, and we should try to
> minimize those.  But especially in init files, it's important to warn
> about typos in variable names, because users are more likely to be left
> puzzled by such a mistake than people doing more serious development.

I know.  It would be good to make it work, but currently in a "well"
written init file, nothing is `require`d so the only `setopt` for which
we'll get correct warnings are those applied to those variables that
are preloaded.  🙁

>> We should try and come up with some way for the byte-compiler to emit
>> useful warnings when compiling init files, but AFAIK we don't have
>> that yet.

When the init file uses `use-package` we could arrange for the macro to
eagerly load the configured packages (but only when the init file is
compiled), which should fix that at least for `use-package` users.

>>> Ideally we should do something similar for setq-local, but AFAICT that
>>> requires a different solution due to different implementation details.
>> Adding the warning for `setq-local` risks a similar problem: it's fairly
>> common for major modes to `setq-local` some vars for optional
>> third-party packages, which may not even be installed.  
> Hmm, is it really a different situation from setq?

My impression is that the proportion of `setq-local` applied to
variables of non-`require`d package is higher than for `setq`, yes.

>> AFAIK we don't really have a good answer for those problems either,
>> the only "solution" we have would be `with-suppressed-warnings`.
> What about declaring these variables with unary defvar forms?
> (Not perfect either, of course, but it is also a solution, no?)

Indeed, that's another solution, but suffers from the same kind of
inconveniences (e.g. when writing such `defvar`s or
`with-suppressed-warnings`, I usually copy the name of the var from its
use rather than from its definition, so any typo just gets duplicated
and I won't be notified when the var becomes obsolete/renamed/deleted).


        Stefan

Previous Next

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