bug#60346: VC refresh error "Recursive load"

bug#60346: VC refresh error "Recursive load"

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#60346: VC refresh error "Recursive load"

[Eli Zaretskii]

> 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@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?

bug#60346: jka-compre.el.gz "Recursive load"

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#60346: jka-compre.el.gz "Recursive load"

[joseph--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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