bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: joseph
Subject: 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@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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]