search

flathub / org.gnu.emacs

https://flathub.org/apps/details/org.gnu.emacs
16 stars 17 forks source link

Do not compress jka-compr.el #78

Open khaoos-abominable opened 2 months ago

khaoos-abominable commented 2 months ago

The library jka-compr is used to load compressed libraries (.el.gz). When it's itself compressed one can encounter recursive load issue. For example: 

 Warning (initialization): An error occurred while loading ~/.emacs.d/init.el’:

error: Recursive load, /app/share/emacs/29.4/lisp/jka-compr.el.gz, /app/share/emacs/29.4/lisp/jka-compr.el.gz, /app/share/emacs/29.4/lisp/jka-compr.el.gz, /app/share/emacs/29.4/lisp/jka-compr.el.gz, /app/share/emacs/29.4/lisp/jka-compr.el.gz, /app/share/emacs/29.4/lisp/info.el.gz, /home/khaoos/.emacs.d/init.el

It's happening on a fresh spacemacs installation (dev branch) due to the lines in `~/.emacs.d/layers/+spacemacs/spacemacs-defaults/config.el

;; Don't load outdated compiled files.
(setq load-prefer-newer t)

As soon as I comment them out, issue dissapears. It seems that emacs tries to recompile the library jka-compr before its load when load-prefer-newer is set. As the uncompiled version of the library is a bit fresher (see Modify below):

[📦 org.gnu.emacs lisp]$ pwd
/app/share/emacs/29.4/lisp
📦 org.gnu.emacs lisp]$ stat *jka-compr*
  File: jka-compr.elc
  Size: 12099       Blocks: 24         IO Block: 4096   regular file
Device: 259,2   Inode: 674859      Links: 2
Access: (0644/-rw-r--r--)  Uid: (65534/nfsnobody)   Gid: (65534/nfsnobody)
Access: 2024-09-22 12:51:01.736093903 +0600
Modify: 2024-09-22 12:51:01.736093903 +0600
Change: 2024-09-22 12:51:22.793010855 +0600
 Birth: 2024-09-22 12:51:01.736093903 +0600
  File: jka-compr.el.gz
  Size: 7293        Blocks: 16         IO Block: 4096   regular file
Device: 259,2   Inode: 676551      Links: 2
Access: (0644/-rw-r--r--)  Uid: (65534/nfsnobody)   Gid: (65534/nfsnobody)
Access: 2024-09-22 12:51:01.920093179 +0600
Modify: 2024-09-22 12:51:01.921093175 +0600
Change: 2024-09-22 12:51:22.798010836 +0600
 Birth: 2024-09-22 12:51:01.920093179 +0600

So I believe if you touch jka-compr.elc the problem will go away. Or a better option I think is just to not compress jka-compr.el at all. But you decide. I haven not tried any of them as the application is immutable and I am a newbie to flatpack to hack it around. As for now I've left setting load-prefer-newer above commented out.

khaoos-abominable commented 2 months ago

Now I think that the most optimal solution will be to touch all *.elc files after their compilation.

Firstly, it will be more friendly to the load-prefer-newer setting. If all elc files are appear newer then their el.gz counterparts, they will be used for loading. And that is good as it's faster. In the opposite case el.gz will be constantly (once every session) being uncompressed and then loaded. And the last behavior I witnessed many times having older version of emacs flatpak: every new action in emacs` fresh session was accompanied by uncompressing and loading dozens of libraries. Which was kind of sluggish.

Secondly, there is a package named auto-compile that helps recompiling outdated libraries on their load and save. I haven't try yet, but I think it will fail when it sees a source el file which is fresher then it's compiled elc counterpart and tries to recompile the latter. Because the file system is read only.

So not compressing jka-compr.el as stated in the subject can be safely ignored in favor of having elc files newer then corresponding el.gz files.