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

Previous Next

To reply to this bug, email your comments to 79380 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: bug-gnu-emacs <at> gnu.org
Cc: Spencer Baugh <sbaugh <at> janestreet.com>
Subject: 31.0.50; Flymake does not check Elisp code anymore
Date: Wed, 03 Sep 2025 23:29:49 +0200

If elisp-flymake-byte-compile-executable is nil (the default), the
absolute file predicate fails and as a result Flymake does not check
Elisp anymore:

(file-name-absolute-p elisp-flymake-byte-compile-executable)

Workaround:

(setq elisp-flymake-byte-compile-executable "emacs")

In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.49, cairo version 1.18.4) of 2025-09-03
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: Debian GNU/Linux 13 (trixie)

Configured using:
 'configure --prefix=$HOME/.local/share/emacs
 --without-compress-install --with-tree-sitter --with-native-compilation
 --with-dbus --without-selinux --without-threads --disable-gc-mark-trace
 --without-gsettings --without-gpm --with-cairo --with-cairo-xcb
 --with-xinput2 --with-x-toolkit=gtk3 --without-toolkit-scroll-bars
 'CFLAGS=-O3 -mtune=native -march=native''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG LIBOTF LIBSYSTEMD
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 TIFF TREE_SITTER WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM
XRANDR GTK3 ZLIB

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 79380 <at> debbugs.gnu.org
Subject: Re: bug#79380: 31.0.50; Flymake does not check Elisp code anymore
Date: Thu, 04 Sep 2025 10:38:32 -0400

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

Daniel Mendler <mail <at> daniel-mendler.de> writes:
> If elisp-flymake-byte-compile-executable is nil (the default), the
> absolute file predicate fails and as a result Flymake does not check
> Elisp anymore:
>
> (file-name-absolute-p elisp-flymake-byte-compile-executable)

Apologies, I accidentally posted an old version of the patch which was
then installed.  The attached should fix it.  Please try it (and then
feel free to push it if it works).

[0001-Fix-null-values-of-elisp-flymake-byte-compile-execut.patch (text/x-patch, inline)]

From 425e3f4ab95faf7c0e4a749e0c428f4c05f32cfa Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Thu, 4 Sep 2025 10:36:17 -0400
Subject: [PATCH] Fix null values of elisp-flymake-byte-compile-executable

* lisp/progmodes/elisp-mode.el
(elisp-flymake-byte-compile--executable): Properly check for
nil. (bug#79380)
---
 lisp/progmodes/elisp-mode.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index e8344852829..c6951810c3e 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -2301,13 +2301,14 @@ elisp-flymake-byte-compile--executable
   "Return absolute file name of the Emacs executable for flymake byte-compilation."
   (let ((filename
          (cond
+          ((null elisp-flymake-byte-compile-executable) nil)
           ((file-name-absolute-p elisp-flymake-byte-compile-executable)
            elisp-flymake-byte-compile-executable)
           ((stringp elisp-flymake-byte-compile-executable)
            (when-let* ((pr (project-current)))
              (file-name-concat (project-root pr)
                                elisp-flymake-byte-compile-executable))))))
-    (if (file-executable-p filename)
+    (if (and filename (file-executable-p filename))
         filename
       (when elisp-flymake-byte-compile-executable
         (message "No such `elisp-flymake-byte-compile-executable': %s"
-- 
2.43.7

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

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

> Cc: 79380 <at> debbugs.gnu.org
> Date: Thu, 04 Sep 2025 10:38:32 -0400
> From:  Spencer Baugh via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Daniel Mendler <mail <at> daniel-mendler.de> writes:
> > If elisp-flymake-byte-compile-executable is nil (the default), the
> > absolute file predicate fails and as a result Flymake does not check
> > Elisp anymore:
> >
> > (file-name-absolute-p elisp-flymake-byte-compile-executable)
> 
> Apologies, I accidentally posted an old version of the patch which was
> then installed.  The attached should fix it.  Please try it (and then
> feel free to push it if it works).
> 
> >From 425e3f4ab95faf7c0e4a749e0c428f4c05f32cfa Mon Sep 17 00:00:00 2001
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Date: Thu, 4 Sep 2025 10:36:17 -0400
> Subject: [PATCH] Fix null values of elisp-flymake-byte-compile-executable
> 
> * lisp/progmodes/elisp-mode.el
> (elisp-flymake-byte-compile--executable): Properly check for
> nil. (bug#79380)
> ---
>  lisp/progmodes/elisp-mode.el | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
> index e8344852829..c6951810c3e 100644
> --- a/lisp/progmodes/elisp-mode.el
> +++ b/lisp/progmodes/elisp-mode.el
> @@ -2301,13 +2301,14 @@ elisp-flymake-byte-compile--executable
>    "Return absolute file name of the Emacs executable for flymake byte-compilation."
>    (let ((filename
>           (cond
> +          ((null elisp-flymake-byte-compile-executable) nil)
>            ((file-name-absolute-p elisp-flymake-byte-compile-executable)
>             elisp-flymake-byte-compile-executable)
>            ((stringp elisp-flymake-byte-compile-executable)
>             (when-let* ((pr (project-current)))
>               (file-name-concat (project-root pr)
>                                 elisp-flymake-byte-compile-executable))))))
> -    (if (file-executable-p filename)
> +    (if (and filename (file-executable-p filename))
>          filename
>        (when elisp-flymake-byte-compile-executable
>          (message "No such `elisp-flymake-byte-compile-executable': %s"
> -- 
> 2.43.7

Shouldn't the tests of the value of the user option use stringp
instead of null?

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79380 <at> debbugs.gnu.org, mail <at> daniel-mendler.de
Subject: Re: bug#79380: 31.0.50; Flymake does not check Elisp code anymore
Date: Thu, 4 Sep 2025 11:45:12 -0400

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

On Thu, Sep 4, 2025, 11:33 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Cc: 79380 <at> debbugs.gnu.org
> > Date: Thu, 04 Sep 2025 10:38:32 -0400
> > From:  Spencer Baugh via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >
> > Daniel Mendler <mail <at> daniel-mendler.de> writes:
> > > If elisp-flymake-byte-compile-executable is nil (the default), the
> > > absolute file predicate fails and as a result Flymake does not check
> > > Elisp anymore:
> > >
> > > (file-name-absolute-p elisp-flymake-byte-compile-executable)
> >
> > Apologies, I accidentally posted an old version of the patch which was
> > then installed.  The attached should fix it.  Please try it (and then
> > feel free to push it if it works).
> >
> > >From 425e3f4ab95faf7c0e4a749e0c428f4c05f32cfa Mon Sep 17 00:00:00 2001
> > From: Spencer Baugh <sbaugh <at> janestreet.com>
> > Date: Thu, 4 Sep 2025 10:36:17 -0400
> > Subject: [PATCH] Fix null values of elisp-flymake-byte-compile-executable
> >
> > * lisp/progmodes/elisp-mode.el
> > (elisp-flymake-byte-compile--executable): Properly check for
> > nil. (bug#79380)
> > ---
> >  lisp/progmodes/elisp-mode.el | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
> > index e8344852829..c6951810c3e 100644
> > --- a/lisp/progmodes/elisp-mode.el
> > +++ b/lisp/progmodes/elisp-mode.el
> > @@ -2301,13 +2301,14 @@ elisp-flymake-byte-compile--executable
> >    "Return absolute file name of the Emacs executable for flymake
> byte-compilation."
> >    (let ((filename
> >           (cond
> > +          ((null elisp-flymake-byte-compile-executable) nil)
> >            ((file-name-absolute-p elisp-flymake-byte-compile-executable)
> >             elisp-flymake-byte-compile-executable)
> >            ((stringp elisp-flymake-byte-compile-executable)
> >             (when-let* ((pr (project-current)))
> >               (file-name-concat (project-root pr)
> >
>  elisp-flymake-byte-compile-executable))))))
> > -    (if (file-executable-p filename)
> > +    (if (and filename (file-executable-p filename))
> >          filename
> >        (when elisp-flymake-byte-compile-executable
> >          (message "No such `elisp-flymake-byte-compile-executable': %s"
> > --
> > 2.43.7
>
> 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.

>

[Message part 2 (text/html, inline)]

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

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

> 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).

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79380 <at> debbugs.gnu.org, mail <at> daniel-mendler.de
Subject: Re: bug#79380: 31.0.50; Flymake does not check Elisp code anymore
Date: Thu, 4 Sep 2025 12:20:14 -0400

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

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.

>

[Message part 2 (text/html, inline)]

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

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: Re: 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

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

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

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

Daniel Mendler <mail <at> daniel-mendler.de> writes:

> 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.

Right, even better.  Like this:

[0001-Fix-null-values-of-elisp-flymake-byte-compile-execut.patch (text/x-patch, inline)]

From 7801088c56a2c06fd3cd598f64343598911b76da Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Thu, 4 Sep 2025 10:36:17 -0400
Subject: [PATCH] Fix null values of elisp-flymake-byte-compile-executable

* lisp/progmodes/elisp-mode.el
(elisp-flymake-byte-compile-executable): Improve defcustom type.
(elisp-flymake-byte-compile--executable): Properly check for
nil. (bug#79380)
---
 lisp/progmodes/elisp-mode.el | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index e8344852829..b660eb74c05 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -2292,7 +2292,7 @@ elisp-flymake-byte-compile-executable
 If nil, or if the file named by this does not exist, Flymake will
 use the same executable as the running Emacs, as specified by the
 variables `invocation-name' and `invocation-directory'."
-  :type 'file
+  :type '(choice (const :tag "Running Emacs executable" nil) file)
   :group 'lisp
   :version "31.1")
 
@@ -2301,13 +2301,16 @@ elisp-flymake-byte-compile--executable
   "Return absolute file name of the Emacs executable for flymake byte-compilation."
   (let ((filename
          (cond
-          ((file-name-absolute-p elisp-flymake-byte-compile-executable)
-           elisp-flymake-byte-compile-executable)
+          ((null elisp-flymake-byte-compile-executable) nil)
           ((stringp elisp-flymake-byte-compile-executable)
-           (when-let* ((pr (project-current)))
-             (file-name-concat (project-root pr)
-                               elisp-flymake-byte-compile-executable))))))
-    (if (file-executable-p filename)
+           (if (file-name-absolute-p elisp-flymake-byte-compile-executable)
+               elisp-flymake-byte-compile-executable
+             (when-let* ((pr (project-current)))
+               (file-name-concat (project-root pr)
+                                 elisp-flymake-byte-compile-executable))))
+          (t (error "Invalid `elisp-flymake-byte-compile-executable': %s"
+                    elisp-flymake-byte-compile-executable)))))
+    (if (and filename (file-executable-p filename))
         filename
       (when elisp-flymake-byte-compile-executable
         (message "No such `elisp-flymake-byte-compile-executable': %s"
-- 
2.43.7

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 79380 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79380: 31.0.50; Flymake does not check Elisp code anymore,
 [PATCH] Fix null values of elisp-flymake-byte-compile-executable
Date: Fri, 05 Sep 2025 14:26:49 -0400

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

Spencer Baugh <sbaugh <at> janestreet.com> writes:
> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>
>> 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.
>
> Right, even better.  Like this:

Ping, I'd like to install this patch to fix the breakage on master.

Here's an updated version since Eli separately pushed the fix to the
defcustom.

[0001-Fix-null-values-of-elisp-flymake-byte-compile-execut.patch (text/x-patch, inline)]

From b8028967538aec545b6082bb295229b142490710 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Thu, 4 Sep 2025 10:36:17 -0400
Subject: [PATCH] Fix null values of elisp-flymake-byte-compile-executable

* lisp/progmodes/elisp-mode.el
(elisp-flymake-byte-compile-executable): Improve defcustom type.
(elisp-flymake-byte-compile--executable): Properly check for
nil. (bug#79380)
---
 lisp/progmodes/elisp-mode.el | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index aebc93d1ddb..df9af7d83bd 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -2303,13 +2303,16 @@ elisp-flymake-byte-compile--executable
   "Return absolute file name of the Emacs executable for flymake byte-compilation."
   (let ((filename
          (cond
-          ((file-name-absolute-p elisp-flymake-byte-compile-executable)
-           elisp-flymake-byte-compile-executable)
+          ((null elisp-flymake-byte-compile-executable) nil)
           ((stringp elisp-flymake-byte-compile-executable)
-           (when-let* ((pr (project-current)))
-             (file-name-concat (project-root pr)
-                               elisp-flymake-byte-compile-executable))))))
-    (if (file-executable-p filename)
+           (if (file-name-absolute-p elisp-flymake-byte-compile-executable)
+               elisp-flymake-byte-compile-executable
+             (when-let* ((pr (project-current)))
+               (file-name-concat (project-root pr)
+                                 elisp-flymake-byte-compile-executable))))
+          (t (error "Invalid `elisp-flymake-byte-compile-executable': %s"
+                    elisp-flymake-byte-compile-executable)))))
+    (if (and filename (file-executable-p filename))
         filename
       (when elisp-flymake-byte-compile-executable
         (message "No such `elisp-flymake-byte-compile-executable': %s"
-- 
2.43.7

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 79380 <at> debbugs.gnu.org, mail <at> daniel-mendler.de
Subject: Re: bug#79380: 31.0.50; Flymake does not check Elisp code anymore,
 [PATCH] Fix null values of elisp-flymake-byte-compile-executable
Date: Sat, 06 Sep 2025 09:59:43 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 79380 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>
> Date: Fri, 05 Sep 2025 14:26:49 -0400
> 
> > Right, even better.  Like this:
> 
> Ping, I'd like to install this patch to fix the breakage on master.

I was waiting for Daniel to test the patch and say that there are no
further issues with it.

Daniel, please chime in and ack.

> Here's an updated version since Eli separately pushed the fix to the
> defcustom.

Thanks.  However, the log message still says the defcustom is being
modified, which the patch doesn't do.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79380 <at> debbugs.gnu.org, Spencer Baugh <sbaugh <at> janestreet.com>
Subject: Re: bug#79380: 31.0.50; Flymake does not check Elisp code anymore,
 [PATCH] Fix null values of elisp-flymake-byte-compile-executable
Date: Sat, 06 Sep 2025 12:08:46 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: 79380 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>
>> Date: Fri, 05 Sep 2025 14:26:49 -0400
>> 
>> > Right, even better.  Like this:
>> 
>> Ping, I'd like to install this patch to fix the breakage on master.
>
> I was waiting for Daniel to test the patch and say that there are no
> further issues with it.
>
> Daniel, please chime in and ack.

Works for me, yes.

But there is still a small inconsistency in the patch. If the defcustom
is set to an invalid type there will be an error. But if it is set to an
invalid executable we will get a warning. Is this desired?

I suggest to error in both cases to avoid false Flymake errors if the
executable is configured incorrectly, and maybe also flatten the
conditionals (getting rid of the case-of-case). I would have written
something like this:

(defun elisp-flymake-byte-compile--executable ()
  "Return absolute file name of the Emacs executable for flymake byte-compilation."
  (pcase elisp-flymake-byte-compile-executable
    (`nil (expand-file-name invocation-name invocation-directory))
    ((and (pred stringp) file)
     (when-let* (((not (file-name-absolute-p file)))
                 (pr (project-current)))
       (setq file (expand-file-name file (project-root pr))))
     (unless (file-executable-p file)
       (error "No such `elisp-flymake-byte-compile-executable': %s" file))
     file)
    (file (error "Invalid `elisp-flymake-byte-compile-executable': %S" file))))

>> Here's an updated version since Eli separately pushed the fix to the
>> defcustom.
>
> Thanks.  However, the log message still says the defcustom is being
> modified, which the patch doesn't do.

Daniel

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 79380 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79380: 31.0.50; Flymake does not check Elisp code anymore,
 [PATCH] Fix null values of elisp-flymake-byte-compile-executable
Date: Sat, 06 Sep 2025 11:14:24 -0400

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

Daniel Mendler <mail <at> daniel-mendler.de> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>>> Cc: 79380 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>
>>> Date: Fri, 05 Sep 2025 14:26:49 -0400
>>> 
>>> > Right, even better.  Like this:
>>> 
>>> Ping, I'd like to install this patch to fix the breakage on master.
>>
>> I was waiting for Daniel to test the patch and say that there are no
>> further issues with it.
>>
>> Daniel, please chime in and ack.
>
> Works for me, yes.
>
> But there is still a small inconsistency in the patch. If the defcustom
> is set to an invalid type there will be an error. But if it is set to an
> invalid executable we will get a warning. Is this desired?

That was deliberate, yes.  If a user sets
elisp-flymake-byte-compile-executable to "src/emacs" in dir-locals in
the Emacs repo, but they haven't compiled Emacs yet, I figure they would
prefer that flymake fall back to using their running Emacs instance
rather than error because repo/src/emacs doesn't exist.

That being said, since this is unclear I think the message for that case
could be improved.  Also, some of the nested conditionals indeed can be
removed.  Hence, this patch, which I think seems good to me.  (We don't
need to check file-executable-p in the absolute file name case, where we
don't need to fall back; start-process will just error, just like it
would if (expand-file-name invocation-name invocation-directory) doesn't
exist anymore)

>> Thanks.  However, the log message still says the defcustom is being
>> modified, which the patch doesn't do.

Fixed, thanks.

[0001-Fix-null-values-of-elisp-flymake-byte-compile-execut.patch (text/x-patch, inline)]

From 8684d0e973a788165d8c7f521703413b5d1e937f Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Thu, 4 Sep 2025 10:36:17 -0400
Subject: [PATCH] Fix null values of elisp-flymake-byte-compile-executable

* lisp/progmodes/elisp-mode.el
(elisp-flymake-byte-compile--executable): Properly check for
nil, and simplify code. (bug#79380)
---
 lisp/progmodes/elisp-mode.el | 31 +++++++++++++++++--------------
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index aebc93d1ddb..42653069feb 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -2301,20 +2301,23 @@ elisp-flymake-byte-compile-executable
 (declare-function project-root "project" (project))
 (defun elisp-flymake-byte-compile--executable ()
   "Return absolute file name of the Emacs executable for flymake byte-compilation."
-  (let ((filename
-         (cond
-          ((file-name-absolute-p elisp-flymake-byte-compile-executable)
-           elisp-flymake-byte-compile-executable)
-          ((stringp elisp-flymake-byte-compile-executable)
-           (when-let* ((pr (project-current)))
-             (file-name-concat (project-root pr)
-                               elisp-flymake-byte-compile-executable))))))
-    (if (file-executable-p filename)
-        filename
-      (when elisp-flymake-byte-compile-executable
-        (message "No such `elisp-flymake-byte-compile-executable': %s"
-                 filename))
-      (expand-file-name invocation-name invocation-directory))))
+  (cond
+   ((null elisp-flymake-byte-compile-executable)
+    (expand-file-name invocation-name invocation-directory))
+   ((not (stringp elisp-flymake-byte-compile-executable))
+    (error "Invalid `elisp-flymake-byte-compile-executable': %s"
+           elisp-flymake-byte-compile-executable))
+   ((file-name-absolute-p elisp-flymake-byte-compile-executable)
+    elisp-flymake-byte-compile-executable)
+   (t ; relative file name
+    (let ((filename (file-name-concat (project-root (project-current))
+                                      elisp-flymake-byte-compile-executable)))
+      (if (file-executable-p filename)
+          filename
+        ;; The user might not have built Emacs yet, so just fall back.
+        (message "`elisp-flymake-byte-compile-executable' (%s) doesn't exist"
+                 elisp-flymake-byte-compile-executable)
+        (expand-file-name invocation-name invocation-directory))))))
 
 ;;;###autoload
 (defun elisp-flymake-byte-compile (report-fn &rest _args)
-- 
2.43.7

Message #43 received at 79380-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 79380-done <at> debbugs.gnu.org, mail <at> daniel-mendler.de
Subject: Re: bug#79380: 31.0.50; Flymake does not check Elisp code anymore,
 [PATCH] Fix null values of elisp-flymake-byte-compile-executable
Date: Sat, 06 Sep 2025 18:34:48 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  79380 <at> debbugs.gnu.org
> Date: Sat, 06 Sep 2025 11:14:24 -0400
> 
> Daniel Mendler <mail <at> daniel-mendler.de> writes:
> 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> >>> From: Spencer Baugh <sbaugh <at> janestreet.com>
> >>> Cc: 79380 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>
> >>> Date: Fri, 05 Sep 2025 14:26:49 -0400
> >>> 
> >>> > Right, even better.  Like this:
> >>> 
> >>> Ping, I'd like to install this patch to fix the breakage on master.
> >>
> >> I was waiting for Daniel to test the patch and say that there are no
> >> further issues with it.
> >>
> >> Daniel, please chime in and ack.
> >
> > Works for me, yes.
> >
> > But there is still a small inconsistency in the patch. If the defcustom
> > is set to an invalid type there will be an error. But if it is set to an
> > invalid executable we will get a warning. Is this desired?
> 
> That was deliberate, yes.  If a user sets
> elisp-flymake-byte-compile-executable to "src/emacs" in dir-locals in
> the Emacs repo, but they haven't compiled Emacs yet, I figure they would
> prefer that flymake fall back to using their running Emacs instance
> rather than error because repo/src/emacs doesn't exist.
> 
> That being said, since this is unclear I think the message for that case
> could be improved.  Also, some of the nested conditionals indeed can be
> removed.  Hence, this patch, which I think seems good to me.  (We don't
> need to check file-executable-p in the absolute file name case, where we
> don't need to fall back; start-process will just error, just like it
> would if (expand-file-name invocation-name invocation-directory) doesn't
> exist anymore)
> 
> >> Thanks.  However, the log message still says the defcustom is being
> >> modified, which the patch doesn't do.
> 
> Fixed, thanks.

Thanks, installed, and closing the bug.

Previous Next

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