Compiling your #emacs config files is the perfect solution for people who want to save 5 seconds on startup time, in exchange for hours debugging compile errors.

Today's #emacs lesson: my locally installed #orgmode broke completely. After some light debugging I gave up, deleted the org directory, and reinstalled from melpa.

And - still broken. With warnings that Emacs couldn't find the org file in the directory I'd deleted. And completely scrubbed from my init. But Emacs continued to look for it in the old location.

Until - I deleted the .elc files in my user-lisp directory. And then, at last, it works.

From which I tentatively conclude that when you compile an #elisp file that calls another file, it somehow hard-codes the location of the file it loads. Such that changing the load path or otherwise telling Emacs to load a different file doesn't get accounted for.

Which, if accurate, would mean you need to recompile your .elc files not just when the corresponding .el file changes, but when any of the files it calls changes?

Is that right? That sounds ugly

I have discovered that the #Emacs user-lisp directory is not for me
in the process of rebuilding my config I did learn that dropping the 'ensure' flag from 'use-package' decreases up my load time, most noticeably when the network is having a slow day. Which is relatively frequently here
also, @nextcloud automatic file backup saved my bacon when I accidentally did a 'rm eln-cache/ *', wiping out my init.el and a few other mildly important files
@plantarum @nextcloud your init.el must be protected at all costs! Keep it under version control.

@plantarum It's been a long time since I used emacs, but a very cursory check suggests you could set `no-byte-compile` to `t` to disable byte compilation entirely. Most of the advantage of byte compilation is on startup of course but it's not clear to me it's very visible on modern systems, and if you mostly just start emacs after you reboot your computer (a whole thing on it's own, but the right way to use emacs in my opinion) you only pay any extra cost once anyway.

But, there could easily be a better way to solve the problem that isn't quite so much of a big hammer.

@plantarum

any bump in emacs version i delete the elc files & elpa folder

@plantarum
Pretty sure it was looking for your org file because there was a variable set to tell it to look there.
It was set in your .el files. But you seem to have deleted those while leaving their compiled versions in place.

Emacs continued loading the compiled configurations, therefore pointing at the old file that was no longer there.
That's why removing the .elc files fixed the problem that was created when you deleted the org file.

Usually, the .el and .elc files are right next to each other, not in some other place. You can, however make it do that.

@Zenie except that I didn't delete any .el files, but did delete the .elc files. Initially via rm *.elc, and eventually escalating to `find .emacs.d/ -name '*.elc' -exec rm '{}' ;`.

I suspect you're right, but I could not find the offending elc file anywhere. I was pretty thorough (repeatedly) in scrubbing them!

@plantarum
It's hard to say now. But it's an easy thing to do, pick up an old .elc

A basic org configuration will tell it where org files go and which ones to load.

It does certainly seem confusing whatever it was that you had going on.

@plantarum OTOH, TFW you get to the other side.

@kickingvegas Well, I spent an hour last night fighting with "Org version mismatch". Cycling through deleting and recompiling org .el files, clearing out eln-cache, putting (require 'org) at different places in my init, round and round.

Finally it was gone.

Logging in this evening and its back. WTF.

Also a bunch of 'file doesn't exist' when I run emacs --debug-init, despite the file very much existing.

At this point I'm just silencing warnings and hoping that nothing blows up.

@plantarum file under “we did this not because it was easy, but because we thought it would be easy…”

@plantarum
maybe?

TLDR: Use process snapshotting software to create a snapshot of the emacs process running as a server, after it goes through all init. Connect to it with emacsclient. Use the saved snapshot to start/restart emacs without running any of the initialization code at all.

https://arrayfire.com/blog/checkpoint-and-restore-emacs-into-immortality/

Checkpoint and Restore Emacs into Immortality | ArrayFire