Closed haji-ali closed 1 year ago
There are two reasons for loading Radian in early-init.el
:
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.
NB for future readers, it seems that this :initialize #'custom-initialize-delay
property on auto-save-list-file-prefix
was added in https://github.com/emacs-mirror/emacs/commit/636856faa4de78912bf41eeaf0e639664a323424.
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
usingradian-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
?
Do you mean loading the theme or disabling the window elements?
Both, in fact. There's some previous discussion at https://github.com/raxod502/radian/issues/180, and then in https://github.com/raxod502/radian/commit/1c84e145c4f75761f59f64aff710dfa45175b437 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
).
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:
early-radian.el
where the early code is located.radian-after-early-init-hook
for user code to run at the end of early init.radian.el
to early-radian.el
.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
.init.el
in early-init.el
.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
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).
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?
I am not seeing the issue either. I don't know if the issue was resolved somewhere upstream or my original tests were flawed.
The variable
auto-save-list-file-prefix
specifies where auto-save files are saved. The packageno-littering
which Radian loads nicely sets it to be inside thevar
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 (afterearly-init.el
but beforeinit.el
). Since Radian is loaded inearly-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?