Open mrzor opened 3 years ago
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 ?
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.
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).
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!
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.
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 :
custom-file
before the OS specific settings importscustom-file
(as the prelude-modules-file
) from the list of personal files to load (a few lines later)It worked for me.
Could you explain how you did this more specifically? Thanks!
Here is the patch file. (I appended the .txt
extension to bypass github extension filtering)
load-custom-file-earlier.patch.txt
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!
Problem Some customizables, like the recently introduced
prelude-minimalistic-ui
, need to be set pretty early during startup. Prelude stores custom variables inpersonal/custom.el
, which is loaded aftercore/prelude-ui
. As a result, a customizedprelude-minimalistic-ui
value is not used byprelude-ui
.Solution I'm not quite sure.
Workaround I moved my
custom.el
topersonal/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 aroundinit.el
resetting it.init.el
could be clever about the value ofcustom-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.