GNU bug report logs - #60346
VC refresh error "Recursive load"

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 60346 in the body.
You can then email your comments to 60346 AT debbugs.gnu.org in the normal way.

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

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

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: bug-gnu-emacs <at> gnu.org
Subject: VC refresh error "Recursive load"
Date: Mon, 26 Dec 2022 13:26:17 -0800

Hello,

I wanted to ignore byte-compiled files because edebug was refusing to
step into byte-compiled functions.

I ran the following:

emacs -Q --eval="(setq load-suffixes '(\".el\"))"

This broke basic functionality, throwing a "Recursive load" error. For
example, `M-x find-file ~/.emacs.d/init.el` gives:

VC refresh error: (error "Recursive load" "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz" "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz" "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz" "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz" "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz" "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/vc/vc-git.el.gz")
load-with-code-conversion: Recursive load: "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz", "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz", "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz", "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz", "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz", "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/vc/vc-git.el.gz"

Emacs also breaks when load-suffixes are reordered:

emacs -Q --eval="(setq load-suffixes '(\".el\" \".so\" \".elc\"))"

I am running Guix on a foreign distro Debian Bullseye. Shall I send this
issue to the Guix mailing list instead?

Thank you!

Joseph

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 60346 <at> debbugs.gnu.org
Subject: Re: bug#60346: VC refresh error "Recursive load"
Date: Tue, 27 Dec 2022 16:05:29 +0200

> Date: Mon, 26 Dec 2022 13:26:17 -0800
> From:  Joseph Turner via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> I wanted to ignore byte-compiled files because edebug was refusing to
> step into byte-compiled functions.
> 
> I ran the following:
> 
> emacs -Q --eval="(setq load-suffixes '(\".el\"))"
> 
> This broke basic functionality, throwing a "Recursive load" error. For
> example, `M-x find-file ~/.emacs.d/init.el` gives:
> 
> VC refresh error: (error "Recursive load" "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz" "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz" "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz" "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz" "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz" "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/vc/vc-git.el.gz")
> load-with-code-conversion: Recursive load: "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz", "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz", "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz", "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz", "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz", "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/vc/vc-git.el.gz"
> 
> Emacs also breaks when load-suffixes are reordered:
> 
> emacs -Q --eval="(setq load-suffixes '(\".el\" \".so\" \".elc\"))"
> 
> I am running Guix on a foreign distro Debian Bullseye. Shall I send this
> issue to the Guix mailing list instead?

I'm not sure we want to support this kind of changes in the order or
contents of load-suffixes.  It sounds to me like the order is there
for as reason, and no part of Emacs expects these lists to be
reordered, let alone have some extensions removed from them.  I think
the only valid changes are adding extensions to the end.

Stefan, WDYT?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60346 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#60346: jka-compre.el.gz "Recursive load"
Date: Tue, 27 Dec 2022 10:42:32 -0500

>> I wanted to ignore byte-compiled files because edebug was refusing to
>> step into byte-compiled functions.

Ignoring byte-compiled files is definitely not the best solution to
your problem.

>> I ran the following:
>> 
>> emacs -Q --eval="(setq load-suffixes '(\".el\"))"
>> 
>> This broke basic functionality, throwing a "Recursive load" error. For
>> example, `M-x find-file ~/.emacs.d/init.el` gives:
>> 
>> VC refresh error: (error "Recursive load"
>> "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/jka-compr.el.gz"

Loading a compressed file can be done only after we load `jka-compr`
(since that's the package which implement this feature).
So clearly, there's a bootstrap problem if that package is
itself compressed.

Distributions which compress their `.el` files get away with it because
`jka-compr.elc` isn't compressed, but if you remove `.elc` from
`load-suffixes` then you reintroduce the circularity.  Same thing if you
move it to after `.el`.

Maybe `gunzip .../jka-compr.el.gz` is all it takes to make it work, tho.

> I'm not sure we want to support this kind of changes in the order or
> contents of load-suffixes.

It might work when `.el` files aren't compressed.

> It sounds to me like the order is there for as reason, and no part of
> Emacs expects these lists to be reordered, let alone have some
> extensions removed from them.  I think the only valid changes are
> adding extensions to the end.

I'm not sure what I'd consider valid or not, but the present use-case
isn't a good justification to go and try and make that use work.


        Stefan

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

From: joseph <at> breatheoutbreathe.in
To: "Stefan Monnier" <monnier <at> iro.umontreal.ca>, "Eli Zaretskii" <eliz <at> gnu.org>
Cc: 60346 <at> debbugs.gnu.org
Subject: Re: bug#60346: jka-compre.el.gz "Recursive load"
Date: Fri, 06 Jan 2023 01:23:26 +0000

Thank you for your feedback! Yes, this seems like a case of the XY problem. If the problem comes up again for me, I'll ask for helping stepping into byte-compiled functions.

Joseph

December 27, 2022 7:42 AM, "Stefan Monnier" <monnier <at> iro.umontreal.ca> wrote:

>>> I wanted to ignore byte-compiled files because edebug was refusing to
>>> step into byte-compiled functions.
> 
> Ignoring byte-compiled files is definitely not the best solution to
> your problem.
> 
>>> I ran the following:
>>> 
>>> emacs -Q --eval="(setq load-suffixes '(\".el\"))"
>>> 
>>> This broke basic functionality, throwing a "Recursive load" error. For
>>> example, `M-x find-file ~/.emacs.d/init.el` gives:
>>> 
>>> VC refresh error: (error "Recursive load"
>>> "/gnu/store/x8nykb09aqmp2j6k74dpgc4jvbk8c2bl-emacs-next-29.0.50-3.22e8a77/share/emacs/29.0.50/lisp/j
>>> a-compr.el.gz"
> 
> Loading a compressed file can be done only after we load `jka-compr`
> (since that's the package which implement this feature).
> So clearly, there's a bootstrap problem if that package is
> itself compressed.
> 
> Distributions which compress their `.el` files get away with it because
> `jka-compr.elc` isn't compressed, but if you remove `.elc` from
> `load-suffixes` then you reintroduce the circularity. Same thing if you
> move it to after `.el`.
> 
> Maybe `gunzip .../jka-compr.el.gz` is all it takes to make it work, tho.
> 
>> I'm not sure we want to support this kind of changes in the order or
>> contents of load-suffixes.
> 
> It might work when `.el` files aren't compressed.
> 
>> It sounds to me like the order is there for as reason, and no part of
>> Emacs expects these lists to be reordered, let alone have some
>> extensions removed from them. I think the only valid changes are
>> adding extensions to the end.
> 
> I'm not sure what I'd consider valid or not, but the present use-case
> isn't a good justification to go and try and make that use work.
> 
> Stefan

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: 60346-close <at> debbugs.gnu.org
Subject: closing this old report
Date: Tue, 11 Mar 2025 19:24:57 +0800

Hello,

Nothing actionable here.

-- 
Sean Whitton

Previous Next

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