Daniel Mendler writes: > Thanks for taking a look at this problem! > > Spencer Baugh writes: >> On Thu, Sep 4, 2025, 12:03 PM Eli Zaretskii wrote: >>> > From: Spencer Baugh >>> > Date: Thu, 4 Sep 2025 11:45:12 -0400 >>> > Cc: mail@daniel-mendler.de, 79380@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. Right, even better. Like this: