How to deal with auto-save-list-file-prefix (and custom-initialize-delay)?

[Abdul-Lateef Haji-Ali]

The variable auto-save-list-file-prefix specifies where auto-save files are saved. The package no-littering which Radian loads nicely sets it to be inside the var directory.

However, this new value is reverted to the original value. I think this is related to the fact that auto-save-list-file-prefix has #'custom-initialize-delay as an :initialize property. This seems to mean that the value is actually initialized later (after early-init.el but before init.el). Since Radian is loaded in early-init.el (for some reason), this value of this variable and similar delayed variables are overwritten.

What is the reason for loading Radian in early-init.el? How can one deal with these variables?

[Radon Rosborough]

There are two reasons for loading Radian in early-init.el:

• Configuring the graphics settings before the initial frame is created actually speeds up startup a fair bit.
• In Emacs 28, we need to disable package.el in the early init-file, since by the time we get to the regular init-file it's too late.

Now, this really means that we just need a few select settings to be updated in the early init-file, not that we have to load all of Radian in the early init-file. And indeed it's rather annoying to load all of it in the early init-file, since that means we don't get to see progress messages during startup.

I'd welcome any improvement here, such as making the early init-file load optional, or migrating over only the parts that actually need to go there.

To answer your specific question, one simple workaround would be to add the setting to after-init-hook using radian-defhook. More generally we should clean up the mess of loading the entirety of Radian during the early init-file.

[Radon Rosborough]

NB for future readers, it seems that this :initialize #'custom-initialize-delay property on auto-save-list-file-prefix was added in emacs-mirror/emacs@636856f.

[Abdul-Lateef Haji-Ali]

I'd welcome any improvement here, such as making the early init-file load optional, or migrating over only the parts that actually need to go there.

If you could point out which parts are necessary to be in early-init.el, I might take a crack at make the necessary changes when I get a chance. One thing that I didn't get is what you mean by "graphics settings". Do you mean loading the theme or disabling the window elements?

Is this related to Radian disabling x-apply-session-resources until it finishes loading. I like this "feature", but I guess it can still be done in early-init.el and undone at the end of init.el.

To answer your specific question, one simple workaround would be to add the setting to after-init-hook using radian-defhook. More generally we should clean up the mess of loading the entirety of Radian during the early init-file.

Isn't after-init-hook still called at the end of radian.el, i.e., still in early-init.el. Did you mean radian--finalize-init-hook?

[Radon Rosborough]

Do you mean loading the theme or disabling the window elements?

Both, in fact. There's some previous discussion at #180, and then in 1c84e14 I imported the rest of init to happen before the window system gets initialized, because it's noticeably faster to configure window settings before the window gets created with its default settings already.

The "right" thing to do is of course to apply only the necessary graphics settings in early-init.el, and then load the rest of everything at the normal init time. The reason I didn't do this initially is because one graphics setting I wanted to apply was loading the color theme, which is a third-party package, which means straight.el has to be loaded, etc. etc.

In retrospect, the inconvenience of having the entire init process happen in early-init.el is much greater than the inconvenience of having a slightly messier init-file layout, or of just accepting a slightly slower startup time.

Isn't after-init-hook still called at the end of radian.el

No, I don't believe so. after-init-hook is defined by Emacs itself, and won't be called until after the entire init process completes, including the regular init-file.

You may be surprised to learn that radian--finalize-init-hook is in fact run during the early init-file, on the contrary. This is because, although the invocation is in init.el, the way early-init.el works at present (though this should be fixed, as per my previous comment) is that it simply loads init.el, and then init.el has some special code that only allows it to be loaded once (so nothing happens when Emacs proceeds from loading early-init.el to subsequently loading init.el).

[Abdul-Lateef Haji-Ali]

I am looking into separating radian's early init code and actual init code.

Here is how I am planning to do it, any feedback is appreciated:

• Create new file: early-radian.el where the early code is located.
• Create a new hook radian-after-early-init-hook for user code to run at the end of early init.
• Move UI parts (plus loading of straight and some definitions) from radian.el to early-radian.el.
• Move the loading of local.init.el from init.el to early-radian.el (so that radian-after-early-init-hook is available at the end of early-radian.el.
• Remove the loading of init.el in early-init.el.
• Remove code in init.el that prevents multiple execution (since it is unnecessary).
• init.el still loads radian.el as it is now.

The local.init.el file would be embedded in early-radian.el rather than radian.el

[Radon Rosborough]

That all sounds great! The only thing is that we need to make sure early-radian.el still gets loaded even if Emacs does not have support for early-init.el (Emacs 26 and earlier).

[Radon Rosborough]

OK, going through old issues. We had a good discussion here about early-init and whether it's needed, but thinking back to the problem that prompted this whole thing:

this new value is reverted to the original value. I think this is related to the fact that auto-save-list-file-prefix has #'custom-initialize-delay as an :initialize property

I have been unable to reproduce this behavior with Emacs 28.1. I added

(message "custom-delayed-init-variables at start: %S" custom-delayed-init-variables)

to ~/.emacs.d/early-init.el (as installed by Radian) and got custom-delayed-init-variables at start: t. Per the docstring of custom-delayed-init-variables which is used in custom-initialize-delay:

Once this list has been processed, this var is set to a non-list value.

So it seems that custom-initialize-delay is processed wholly before the early init-file. This lines up with the docstring of custom-initialize-delay:

This is used in files that are preloaded (or for autoloaded
variables), so that the initialization is done in the run-time
context rather than the build-time context.

Further, checking the value of auto-save-list-file-prefix after init, I find its value "/home/raxod502/.emacs.d/var/auto-save/sessions/" as desired.

On that basis I think the issue has been resolved (or was originally caused by something else). Does that sound right?

[Abdul-Lateef Haji-Ali]

I am not seeing the issue either. I don't know if the issue was resolved somewhere upstream or my original tests were flawed.