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

[Stefan Monnier]

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