Theme is mixed up after update

[hagmonk]

Description

Theme is mixed up after update

Reproduction guide

I pulled from develop:

remote: Counting objects: 242, done.
remote: Total 242 (delta 159), reused 159 (delta 159), pack-reused 83
Receiving objects: 100% (242/242), 78.00 KiB | 0 bytes/s, done.
Resolving deltas: 100% (163/163), completed with 73 local objects.
From https://github.com/syl20bnr/spacemacs

• branch develop -> FETCH_HEAD
  f5924d1..66ed054 develop -> origin/develop
  First, rewinding head to replay your work on top of it...
  Fast-forwarded develop to 66ed054.

And relaunched spacemacs, and now my window is a hybrid of material-light and some other colors.

#### System Info - OS: darwin - Emacs: 25.0.90.1 - Spacemacs: 0.105.12 - Spacemacs branch: develop (rev. 66ed054) - Graphic display: t - Distribution: spacemacs - Editing style: emacs - Completion: helm - Layers:

((ruby :variables ruby-version-manager 'rvm ruby-enable-enh-ruby-mode nil)
 auto-completion better-defaults emacs-lisp osx git markdown pandoc sql clojure org restclient eyebrowse spell-checking syntax-checking themes-megapack version-control spacemacs-layouts)

[nixmaniack]

May be you have customizations in your ~/.spacemacs under custom-set-faces.

[bmag]

Some themes are partially applied as part of their installation/update process. @hagmonk it is possible that when you relaunched spacemacs, a new theme was installed and partially applied. Do you still have a mixed theme if you relaunch spacemacs again?

[hagmonk]

It persists after restart. Root cause was some stuff added to custom-set-faces. I was inclined to chalk this up to me being full of derp, however it just happened again! And I certainly didn't customize those faces myself.

I had to revert d3833db because after that commit yas-snippets keeps barfing all the time (separate issue incoming for that one), and after restarting spacemacs I found my custom-set-faces looked like this:

(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(default ((((class color) (min-colors 89)) (:foreground "#ffffff" :background "#263238"))))
 '(org-default ((t (:inherit default))))
 '(org-inlinetask ((t (:inherit default)))))

Now that default came back after I deleted it the first time. Weird :)

[bmag]

I have also noticed a custom-set-faces and other customize sections appearing at the end of my init.el, despite not using customize at all.

I deleted the customize sections, saved init.el, ran SPC a k (paradox-list-packages), and then saw that the customize sections reappeared! In other words, Paradox causes the settings to be saved to init.el.

It appears to happen because our local fork of Paradox calls customize-save-variable here and here. The original upstream Paradox package also contains calls customize-save-variables, so switching to it isn't likely to fix the problem. You can see for your self that executing the following will rewrite the customize sections: M-: (customize-save-variable 'paradox-github-token t)

In my case, custom-set-faces looks like this:

(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(company-tooltip-common ((t (:inherit company-tooltip :weight bold :underline nil))))
 '(company-tooltip-common-selection ((t (:inherit company-tooltip-selection :weight bold :underline nil)))))

It matches the code in auto-completion layer that customizes these variables, but doesn't save them to file, see here.

@hagmonk something (possibly parts of Spacemacs) sets variables and faces through customize-* calls, and something else (probably Paradox) saves to file by calling customize-save-variable or other customize save functions.
If it is Paradox that causes your trouble, you should be able to avoid the problem by putting (setq paradox-github-token t) in user-init, deleting the customize sections and restarting emacs.

[nixmaniack]

I can as well confirm that I get those custom faces set even when I don't use them. That's why my first guess was pointing to it!

[hagmonk]

Sounds like this particular instance could be worked around by setting paradox-github-token in advance, but this doesn't feel like the long term solution. The side effect of saving these variables is all sorts of unwanted junk being written to my config, which isn't great at all.

Do you feel this needs more analysis (maybe advices set around these functions to audit who's calling them? I'm not super sure the standard way to debug this) before sending the bug upstream to paradox?

[syl20bnr]

I never encountered this issue. My custom-set-faces list is empty. Do we have still the issue in current spacemacs ?

[hagmonk]

Based on the age of this issue and that I am no longer experiencing it (and you've never seen it), I think it's safe to close. Thanks!

[liuzhishan]

My theme background color is not changing while I changing the theme.
Set the custom-set-faces to () solve my problems. The theme seems to be right now.

[paultopia]

Interestingly, this just happened to me on the develop branch. I added themes-megapack, and then tried to change the theme, and ended up with a bunch of bizarre garbage theming where it looks like I had part of the interface in a light theme and part in a dark theme... and it persisted across multiple restarts. After finding this thread, I discovered that a custom-set-faces had shown up at the very end of my .spacemacs for some reason. Commented the whole thing out (and got rid of themes-megapack) and all is well again.

[real-or-random]

I hate to say this, but though this is 7 years old, this is still an issue.

An entry for default was recently added to custom-set-faces in my config by no apparent reason.

@hagmonk something (possibly parts of Spacemacs) sets variables and faces through customize-* calls, and something else (probably Paradox) saves to file by calling customize-save-variable or other customize save functions.

Indeed! I can confirm this. The easiest way to reproduce is to call customize-save-customized.

I digged deeper and I found the issue. It's in spacemacs/set-default-font: The call (set-frame-font fontspec nil t) should be (set-frame-font fontspec nil t t) I'll open a PR later today...

Related:

• After emacs -nw, themes gets messed up on GUI Emacs bbatsov/solarized-emacs#408 (but probably not spacemacs because the user has a custom.el)
• https://emacs.stackexchange.com/questions/33403/customize-creates-custom-set-faces-unintentionally (this is on spacemacs)

[real-or-random]

#16137 should fix this, but only on Emacs >= 28.0.90. So if you encounter this and still run Emacs 27, you should probably update.