How to Avoid dotspacemacs/emacs-custom-settings?

[jupl]

I mentioned this in a closed thread but thought it would be better to open a new issue instead.

Until recently I took advantage of custom-file to write custom configurations (custom-set-variables) to an ignored file in an effort to avoid code being added to my configuration automatically as I store my configuration in version control and I don't use Emacs' customize UI.

There was a recent update in develop where Spacemacs is now writing things to my configuration automatically in the form of dotspacemacs/emacs-custom-settings. I do not want this behavior and would like for this to be turned off, but there is no way to do that. Even if I remove the offending code, when I use the Update Packages feature of Spacemacs, that code gets injected back automatically.

[cdlm]

Yeah this is dangerously broken. When I reboot Emacs, more often than not it will ask to save .spacemacs because that function has been completely emptied (so all custom settings would be lost)

[ghost]

The code of ~/.emacs.d/core/core-custom-settings.el literally hardcodes "find the dotspacemacs file" (it calls dotspacemacs/location which returns your dotfile) regardless of what we set spacemacs--custom-file to.

It then deletes the custom section from your dotfile and writes the new one there. In fact, spacemacs--custom-file is just a temporary cache location (which needs to match custom-file for caching to work properly), and it then forcibly merges that cache into your config file afterwards. So no matter what you do, you will not be able to get rid of the custom-section from your main dotspacemacs file.

Suggestion to make everyone happy: Introduce a new variable to control where dotspacemacs/emacs-custom-settings is written.

Put the variable in the dotspacemacs/init section of the dotspacemacs file, and make it very clear to people in its code-comment that they can never modify the normal custom-file property anymore (because it's needed for caching of the temporary custom data before it's moved by Spacemacs)!

Give the variable this default value:
spacemacs-custom-file "dotspacemacs"

That string would be a value with special meaning which means what it does today: Find the dotspacemacs file wherever it is, and use that.

Personalized value example:
spacemacs-custom-file "~/.spacemacs.d/custom.el"

This would tell it to write to a separate file instead of your dotspacemacs file. And to load from that separate file when it restores itself.

This way we can still have the advantages of the recent Spacemacs update which wraps the custom settings (great for being able to control exactly when custom settings get applied). But we can also choose where to save it all.

It's going to require some rewrites of ~/.emacs.d/core/core-custom-settings.el but I think it's inevitable that someone will get annoyed enough to do it.

[syl20bnr]

I propose to disable the auto-rewrite of customize variables when the custom-file does not point to the dotfile or to the default .cache location. It makes sense, we need this mechanism only if those variables are written in the dotfile.

[mkaito]

Oh god yes, this is driving me crazy. One out every two emacs restarts all my custom settings are gone! And even when they are in the custom-file, emacs doesn't care and doesn't load them.

[syl20bnr]

@mkaito will take care of this tonight, at least to disable the automatic write to dotfile if the user set their own location. Is that your case ?

[mkaito]

I had two separate issues. 1. Emacs was not loading the customized variables and faces. 2. When saving customized variables, they would sometimes get written to `.cache/.custom-settings`, and sometimes to the dotfile. Sometimes, nowhere. They are both probably sympthoms of the same problem, but customize internals are a mystery to me, so what do I know. I'm going to go out on a limb and say specifying a `custom-file` that is not the dotfile might fix both of these. Sylvain Benner <notifications@github.com> writes:

…

@mkaito will take care of this tonight, at least to disable the automatic write to dotfile if the user set their own location. Is that your case ? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #7891 (comment)

-- BOFH excuse #250: Program load too heavy for processor to lift.

[syl20bnr]

2. It is unexpected because technically it is impossible except if you modify custom-file at some point. I was planing to fix it yesterday but I ran out of time, maybe this evening.

3. Can you open an issue for this one ?

[mkaito]

I did define custom-file, and that seems to actually have fixed things to a point. It still refuses to load sometimes, though.

I'm not entirely sure how to reproduce any of this. I haven't tried a "clean" installation.

[syl20bnr]

Ahah sorry for the wrong numbers, 3 is for the first point.

Ok so if you modify the custom file then it should be fixed when I push the deactivation of auto-rewrite.

[mkaito]

I actually had the traditional custom-file snipped in my `spacemacs/user-config` for a day or two, and that seems to have fixed things, somehow. I'll test again with your fixes. ``` (setq custom-file "/somewhere/thats/not/the/dotfile") (load custom-file) ``` Sylvain Benner <notifications@github.com> writes:

…

Ahah sorry for the wrong numbers, 3 is for the first point. Ok so if you modify the custom file then it should be fixed when I push the deactivation of auto-rewrite. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #7891 (comment)

-- BOFH excuse #442: Trojan horse ran out of hay

[syl20bnr]

I have a fix pending, I'll push it soon. Note: with this fix custom-file should be set in dotspacemacs/user-init.

[ghost]

@syl20bnr Sooooo... When is the custom-file fix coming out?

And should we use this standard pattern...

;; in dotspacemacs/user-init
(setq custom-file "/somewhere/thats/not/the/dotfile")
(load custom-file)

Or this...

;; in dotspacemacs/user-init
(setq custom-file "/somewhere/thats/not/the/dotfile")

[syl20bnr]

Sorry for the late push, I finally pushed it (3 weeks later!!): 6212795

If you define your own custom-file in dotspacemacs/user-init you should get the vanilla behavior, see changes in commit.

[jupl]

Confirmed it's working in develop.

[ghost]

@syl20bnr Thanks a lot, it works perfectly!

Maybe someday this will get merged too:
#7945

🤣

[quicknir]

I am not sure if this is the correct issue to comment on, but even on HEAD I frequently see my spacemacs/emacs-custom-settings function get completely broken by spacemacs. Typically after I update packages or do some other major change it writes to my .spacemacs file writing only the beginning but not the end of this function, destroy information and leaving my .spacemacs invalid. Is this still known to be happening? Should I simply consider this deprecated and set custom-file instead?

[didibus]

I'm confused. It used to be that custom-set* functions were just at the end of the .spacemacs file. Now with develop, they get copied into a (defun dotspacemacs/emacs-custom-settings () function.

So now I have them both as a top level, and inside that function.

Which one is correct? Should I delete the one at the top level, and only keep them inside the (defun dotspacemacs/emacs-custom-settings () function? Or should I delete that function?

Why has it moved to a function now?

[syl20bnr]

This is a side-effect when changing branch, keep the one encapsulated in dotspacemacs/emacs-custom-settings

[sdwolfz]

I've set my custom file to be ~/.emacs.d/.cache/.custom-settings:

  (setq custom-file "~/.emacs.d/.cache/.custom-settings")
  (load custom-file)

That file already existed there and it seems to contain the exact same things as dotspacemacs/emacs-custom-settings had when they were added to my .spacemacs file. Not sure if this would cause any problems... it's been 4 months since I first did that and all seems OK.

I get that all my custom settings will be lost if I do a git clean but I don't actually have any. Whenever I want to configure something I search for the proper configuration and just put that in my user-config.

[didibus]

@syl20bnr Would that also work if I use the config on installs that use mainline?

I share my config file on a few computers, and some are on develop (because it fixes issues specific to their environment), and others are on mainline.

Thanks

[syl20bnr]

I'm afraid that it won't work you'll get the duplicated settings over and over again. But they can co-exist. Actually I'm not happy with this solution, I wanted to keep the dotfile in one-piece no matter what but I guess we need to make an exception for emacs custom settings and create a second file for them. This has been asked for for a long time and it seems to be the best trade off. "Didier A." <notifications@github.com> writes:

…

@syl20bnr Would that also work if I use the config on installs that use mainline? I share my config file on a few computers, and some are on develop (because it fixes issues specific to their environment), and others are on mainline. Thanks -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #7891 (comment)

[didibus]

So, I decided to move all my spacemacs to develop, to keep them more in sync that way.

One last question though, it does seem that the dotspacemacs/emacs-custom-settings gets regenerated every time I pull my latest .spacemacs. If I change something in it on computer #1, and then fast-forward the changes on computer #2, it seems computer #2 will recreate the emacs-custom-settings. In doing so, it will get rid of all my custom settings.

It kinda renders custom settings useless in this case. Is there a way to maintain them in such scenarios?

Thanks

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

[benswift]

Hey team, I ran into this issue this morning (spacemacs develop branch, emacs 27.2) and I fixed it with the "manual download of org-plus-contrib and move it into ~/.emacs.d/elpa/" solution described above.