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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: 79208 <at> debbugs.gnu.org
Subject: 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.