Should custom.el move to personal/preload ?

[mrzor]

Problem
Some customizables, like the recently introduced prelude-minimalistic-ui, need to be set pretty early during startup.
Prelude stores custom variables in personal/custom.el, which is loaded after core/prelude-ui. As a result, a customized prelude-minimalistic-ui value is not used by prelude-ui.

Solution
I'm not quite sure.

Workaround
I moved my custom.el to personal/preload.
Had to add (setq custom-file (expand-file-name "custom.el" prelude-personal-preload-dir)) somewhere in i.e. personal/custom-location.el to work around init.el resetting it.

init.el could be clever about the value of custom-file : don't touch it if its anywhere in personal-dir, including preload-dir. Such cleverness would make preloading custom.el more straightforward.

Additional context
I have plenty of customized faces and styles, some of which trace back 10+ years :) It's been a long frustration to see my emacs only slowly take the proper styling as it was booting. Moving custom.el to the preload directory solved that very nicely, which was a very appreciated side effect.

This comment seems to indicate some people have legitimate reasons to see the custom variables set as late as possible. I don't know how to reconcile both.

[mrzor]

Downside of early custom.el evaluation : any customizables defined or loaded by my personal modules are not customizable anymore. I don't know how to satisfy all use cases here. Maybe minimalistic-ui should not have been a customizable ?

[bbatsov]

You bring up some good point. Probably it makes sense for Prelude's configuration variables not to be defcustoms in general, as many of them have to use in the right context to work.

[AtomicNess123]

I was wondering if it's ok to delete custom.el at all, as I have my own .el file with all my config. I have noticed that sometimes some of the config get copied onto custom.el and messes things ups if I change them back in my own .el file (because of the order in which the .el files are called).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!

[mrzor]

Well I believe it's possible to not have a custom.el at all - or it should be.

The original issue is about where to load it.

In the original issue I wrote:

This comment seems to indicate some people have legitimate reasons to see the custom variables set as late as possible. I don't know how to reconcile both.

In the interest of keeping the issue alive, here's an idea: move custom.el back to "as late as possible" evaluation. Add a new preload, "early as possible", piece of elisp that selectively loads parts of custom.el at the very beginning. Possibly whitelist based, unless something more clever can be devised.

[lyderichti59]

Today I encountered a similar problem.
I had customized my exec-path-from-shell-variables in the custom.el file. But that file is loaded after the OS specific settings (in my case prelude-linux) which executes the exec-path-from-shell-initialise too soon to pick up the env vars I customised).

Anyway, I fixed it like this :

• Load the custom-file before the OS specific settings imports
• Removed the custom-file (as the prelude-modules-file) from the list of personal files to load (a few lines later)

It worked for me.

[AtomicNess123]

Could you explain how you did this more specifically? Thanks!

[lyderichti59]

Here is the patch file. (I appended the .txt extension to bypass github extension filtering)
load-custom-file-earlier.patch.txt

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!