GNU bug report logs - #79380
31.0.50; Flymake does not check Elisp code anymore

Previous Next

Full log

View this message in rfc822 format

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 79380 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#79380: 31.0.50; Flymake does not check Elisp code anymore
Date: Thu, 04 Sep 2025 18:24:08 +0200

Thanks for taking a look at this problem!

Spencer Baugh <sbaugh <at> janestreet.com> writes:
> On Thu, Sep 4, 2025, 12:03 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>> > From: Spencer Baugh <sbaugh <at> janestreet.com>
>> > Date: Thu, 4 Sep 2025 11:45:12 -0400
>> > Cc: mail <at> daniel-mendler.de, 79380 <at> debbugs.gnu.org
>> >
>> >  Shouldn't the tests of the value of the user option use stringp
>> >  instead of null?
>> >
>> > Is that the convention?  I always feel like it's better to test for null
>> explicitly, so that if the user sets the
>> > variable to a symbol or list or something they get an error which can
>> help them track down their mistake.
>>
>> I don't think this is about conventions.  In this specific case, any
>> value that is not a string will signal an error in
>> elisp-flymake-byte-compile--executable, exactly like nil did in the
>> patch that was installed.  So I think any value that is not a string
>> should be handled as nil (in addition to the checking of strings that
>> the code already does).
>>
>
> Yes, my suggestion is that signaling an error is good because it shows that
> the user's configuration is wrong.

I agree that signaling an error would be good. As an alternative you
could do it explicitly. Check against nil to use the defaults, check
stringp for a user defined path and throw an explicit error in the other
cases.

Daniel

Previous Next

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