On Thu, Sep 4, 2025, 12:03 PM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Spencer Baugh <sbaugh@janestreet.com>
> 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.