GNU bug report logs - #79650
spurious newline from vc-do-command during byte-compilation of eglot.el

Previous Next

To reply to this bug, email your comments to 79650 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: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Emacs Bug Report <bug-gnu-emacs <at> gnu.org>
Cc: João Távora <joaotavora <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: spurious newline from vc-do-command during byte-compilation of
 eglot.el
Date: Sat, 18 Oct 2025 18:11:05 +0200

Like everybody else I wondered why suddenly the batch byte-compilation of eglot.el prints a newline to stderr. I'm sure you did, too.

It turns out that eglot.el sets local variables at the end of the file:

;; bug-reference-bug-regexp: "\\(\\(github\\|bug\\)#\\([0-9]+\\)\\)"
;; bug-reference-url-format: eglot--debbugs-or-github-bug-uri

which causes the bug-reference machinery to wake up and run `bug-reference-try-setup-from-vc`, which starts running git commands.

Here we should pause and ask ourselves if it's reasonable to do this during batch compilation. I'm sure this is very important when loading the file for editing but really, isn't the byte-compiler slow enough?

Eventually we arrive in vc-do-command, where we find the gem

                (when noninteractive
                  (with-current-buffer buffer
                    (message (string-trim (buffer-string)))))

First of all, `message` takes a format string; we shouldn't be feeding it arbitrary data because that might contain `%` symbols.

Second, in this case the string is empty so we just print a newline. We shouldn't, of course.

For the record, the attempted command here is 

  git --no-pager config --get remote.upstream.url

which prints nothing and returns with exit status 1.

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

From: Pip Cet <pipcet <at> protonmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: Sean Whitton <spwhitton <at> spwhitton.name>,
 João Távora <joaotavora <at> gmail.com>,
 79650 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79650: spurious newline from vc-do-command during
 byte-compilation of eglot.el
Date: Sat, 18 Oct 2025 16:30:36 +0000

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

> Like everybody else I wondered why suddenly the batch byte-compilation of eglot.el prints a newline to stderr. I'm sure you did, too.

Guilty as charged. I even investigated, then forgot about it again (I
use git worktrees, and they're not supported very well by Emacs, so I
thought I was the only one).

My impression is this is caused by .dir-locals.el:

 (emacs-lisp-mode . ((indent-tabs-mode . nil)
                     (electric-quote-comment . nil)
                     (electric-quote-string . nil)
	             (mode . bug-reference-prog)))

Is it reasonable that we apply .dir-locals.el when byte-compiling?
bug-reference-prog-mode doesn't seem to be useful in noninteractive
mode?

> It turns out that eglot.el sets local variables at the end of the file:
>
> ;; bug-reference-bug-regexp: "\\(\\(github\\|bug\\)#\\([0-9]+\\)\\)"
> ;; bug-reference-url-format: eglot--debbugs-or-github-bug-uri
>
> which causes the bug-reference machinery to wake up and run `bug-reference-try-setup-from-vc`, which starts running git commands.
>
> Here we should pause and ask ourselves if it's reasonable to do this during batch compilation. I'm sure this is very important when loading the file for editing but really, isn't the byte-compiler slow enough?

I convinced the byte compiler to ignore .dir-locals.el, but got no
conclusive benchmarks because of the machine I was on.

> Eventually we arrive in vc-do-command, where we find the gem
>
>                 (when noninteractive
>                   (with-current-buffer buffer
>                     (message (string-trim (buffer-string)))))
>
> First of all, `message` takes a format string; we shouldn't be feeding it arbitrary data because that might contain `%` symbols.

Ouch.  messacge calls styled_format, which allocates one Lisp_Object for
every pair of characters in the format string. Calling it with strings
of unbounded length is a bad idea.

> For the record, the attempted command here is
>
>   git --no-pager config --get remote.upstream.url
>
> which prints nothing and returns with exit status 1.

Well, you haven't configured a remote called "upstream". I don't know
why this is a reasonable thing to inject into the build process, though.

I replaced "git" with a script which logged the arguments to a file
(before calling the actual git so the behavior is the same), and there
are a few more git invocations triggered by a build.  It'd be nice to
track them down, too:

I can live with autogen.sh messing with my git configuration (there's a
flag to disable it), and I guess the developer-vs-user check in
configure is there to stay, but I don't think an ordinary "make" should
run git.

My impression is it would be very confusing to set `no-byte-compile' or
`lexical-binding' for an entire directory, but maybe someone thinks it's
useful.

Pip

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: João Távora <joaotavora <at> gmail.com>,
 79650-done <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79650: spurious newline from vc-do-command during
 byte-compilation of eglot.el
Date: Sat, 18 Oct 2025 17:30:55 +0100

Hello,

On Sat 18 Oct 2025 at 06:11pm +02, Mattias Engdegård wrote:

> Like everybody else I wondered why suddenly the batch byte-compilation
> of eglot.el prints a newline to stderr. I'm sure you did, too.

:)

> Eventually we arrive in vc-do-command, where we find the gem
>
>                 (when noninteractive
>                   (with-current-buffer buffer
>                     (message (string-trim (buffer-string)))))
>
> First of all, `message` takes a format string; we shouldn't be feeding it arbitrary data because that might contain `%` symbols.
>
> Second, in this case the string is empty so we just print a newline. We shouldn't, of course.

Fixed both issues on master.

-- 
Sean Whitton

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: mattias.engdegard <at> gmail.com, monnier <at> iro.umontreal.ca, joaotavora <at> gmail.com,
 79650 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#79650: spurious newline from vc-do-command during
 byte-compilation of eglot.el
Date: Sat, 18 Oct 2025 19:41:21 +0300

> Cc: Sean Whitton <spwhitton <at> spwhitton.name>,
>  João Távora <joaotavora <at> gmail.com>,
>  79650 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Sat, 18 Oct 2025 16:30:36 +0000
> From:  Pip Cet via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> I replaced "git" with a script which logged the arguments to a file
> (before calling the actual git so the behavior is the same), and there
> are a few more git invocations triggered by a build.  It'd be nice to
> track them down, too:

We call Git twice to record the branch and the commit SHA, so 2
invocations are expected.

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

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Emacs Bug Report <bug-gnu-emacs <at> gnu.org>
Cc: João Távora <joaotavora <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: spurious newline from vc-do-command during byte-compilation of
 eglot.el
Date: Sat, 18 Oct 2025 18:47:08 +0200

I wrote

> Eventually we arrive in vc-do-command, where we find the gem

and perhaps that was a bit too strongly worded -- my apologies to Sean.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: João Távora <joaotavora <at> gmail.com>,
 79650 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#79650: spurious newline from vc-do-command during
 byte-compilation of eglot.el
Date: Sat, 18 Oct 2025 13:17:55 -0400

>   git --no-pager config --get remote.upstream.url

Why do we need to run this during the buffer setup?
Can we delay it to the moment we actually do something with
a bug-reference (like click on it)?


        Stefan

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

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mattias.engdegard <at> gmail.com, monnier <at> iro.umontreal.ca, joaotavora <at> gmail.com,
 79650 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#79650: spurious newline from vc-do-command during
 byte-compilation of eglot.el
Date: Sun, 19 Oct 2025 09:44:00 +0000

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

>> Cc: Sean Whitton <spwhitton <at> spwhitton.name>,
>>  João Távora <joaotavora <at> gmail.com>,
>>  79650 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Date: Sat, 18 Oct 2025 16:30:36 +0000
>> From:  Pip Cet via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> I replaced "git" with a script which logged the arguments to a file
>> (before calling the actual git so the behavior is the same), and there
>> are a few more git invocations triggered by a build.  It'd be nice to
>> track them down, too:
>
> We call Git twice to record the branch and the commit SHA, so 2
> invocations are expected.

Thanks! Those are indispensable, I think.

I may be doing something wrong here. I used:

#!/bin/bash
echo "$(date) git $@" >> "$(dirname "$0")/gitlog"
exec /usr/bin/git "$@"

That produces 145 lines of output for "make" (master branch, clean git
worktree), which seems high but possible. But if I run "make distclean"
and "make" again afterwards, I get 726 lines of output.

Deleting .dir-locals.el reduces the number somewhat.

Pip

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: mattias.engdegard <at> gmail.com, monnier <at> iro.umontreal.ca, joaotavora <at> gmail.com,
 79650 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#79650: spurious newline from vc-do-command during
 byte-compilation of eglot.el
Date: Sun, 19 Oct 2025 13:43:35 +0300

> Date: Sun, 19 Oct 2025 09:44:00 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: mattias.engdegard <at> gmail.com, spwhitton <at> spwhitton.name, joaotavora <at> gmail.com, 79650 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> 
> "Eli Zaretskii" <eliz <at> gnu.org> writes:
> 
> > We call Git twice to record the branch and the commit SHA, so 2
> > invocations are expected.
> 
> Thanks! Those are indispensable, I think.
> 
> I may be doing something wrong here. I used:
> 
> #!/bin/bash
> echo "$(date) git $@" >> "$(dirname "$0")/gitlog"
> exec /usr/bin/git "$@"
> 
> That produces 145 lines of output for "make" (master branch, clean git
> worktree), which seems high but possible. But if I run "make distclean"
> and "make" again afterwards, I get 726 lines of output.
> 
> Deleting .dir-locals.el reduces the number somewhat.

Maybe these are "git status" calls when visiting versioned files?

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

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: Sean Whitton <spwhitton <at> spwhitton.name>,
 João Távora <joaotavora <at> gmail.com>, 79650 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79650: spurious newline from vc-do-command during
 byte-compilation of eglot.el
Date: Sun, 19 Oct 2025 21:16:31 +0200

18 okt. 2025 kl. 18.30 skrev Pip Cet <pipcet <at> protonmail.com>:

> Is it reasonable that we apply .dir-locals.el when byte-compiling?
> bug-reference-prog-mode doesn't seem to be useful in noninteractive
> mode?

Yes, the list of variables that could reasonably be affecting compilation should be pretty short. I'd prefer we didn't need to consult .dir-locals.el but some packages do use it for setting byte-compile-error-on-warn and/or byte-compile-warnings, which admittedly is a convenience.

But I'm not convinced that it's necessary to run git in order to find any applicable .dir-locals.el. Is it?

Previous Next

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