Weird colors out of spacemacs

[Naheel-Azawy]

What I did (no spacemacs, just pure emacs):

(use-package spacemacs-theme
  :defer t
  :init
  (load-theme 'spacemacs-dark t))

What I got:

The problem is that the colors are kind of too bright and weird. Any idea?

[nashamri]

Hello @Naheel-Azawy, if you are running emacs in the terminal, yeah the colors are a bit limited and this is how they look :smile:

[Naheel-Azawy]

@nashamri I tried running it with GUI before posting this and the colors were the same as in the question. After several trails I noticed that the only way to get the right colors is by running emacs alone (no client and no -nw). The image shows all cases.

Note that I used to use spacemacs. It had a very weird behavior. Running emacsclient -nw after starting the daemon shows the same weird colors. Once I emacsclient -c, the colors shows up the right way in GUI, but the weird part is that the colors gets corrected somehow in the terminal as well. I was lazy to open an issue on that because the magical workaround was to simply emacsclient -c once and then the colors become right everywhere.

But now with no spacemacs, the only case that the colors are right is when emacs is run in GUI and with no daemon.

[nashamri]

Umm, I'm not sure I see anything wrong with the screenshot. The theme has 4 variants:

• Dark for terminal
• Dark for GUI
• Light for terminal
• Light for GUI

https://github.com/nashamri/spacemacs-theme/blob/master/spacemacs-common.el#L102

In the screenshot, only the first one (the emacs labelled one) is using the GUI variant. The rest are using the dark terminal variant.

Regarding the issue that resolves itself when running emacsclient -c, maybe it's related to this issue (https://github.com/nashamri/spacemacs-theme/issues/78).

[Naheel-Azawy]

I didn't notice that there was a different variant for terminal... Now it's clear thanks!

Anyway, the problem here can be seen is that when started with emacsclient -c it still used the terminal variant. I think this is related to #78 as well. I think the problem is that the theme is loaded when the daemon is started and true-color-p is nil. when emacsclient -c, the theme is already loaded with terminal variant.

So, I tried to mess with things and (defun true-color-p () 1).... The only issue with colors in the terminal I got was the comments background. But for me, I use spacemacs theme with some modifications... So that's no big deal to me.

(setq spacemacs-theme-custom-colors
        (quote
         ((bg1 . "#000000")
          (bg2 . "#101010")
          (bg3 . "#0a0a0a")
          (bg4 . "#070707")
          (comment-bg . "#000000")
          (cblk-bg . "#070707")
          (cblk-ln-bg . "#1f1f1f")
          (head1-bg . "#000000"))))

The frame to the left is a terminal and the other is GUI. They're almost identical! How about adding an option to force using GUI or terminal variant?

[nashamri]

What happened when you set (defun true-color-p () 1)?

How about adding an option to force using GUI or terminal variant?

The question is, is there a situation where one have the ability to show GUI colors and rather use the TER variant instead? Sure maybe someone likes the terminal variant more, but honestly, they were meant to be a graceful fallback and not the preferred choice. We can add something like spacemacs-theme-force-terminal-colors but I'm not sure if there's really a demand for this.

[Naheel-Azawy]

What happened when you set (defun true-color-p () 1)?

The theme gets forced to use gui colors even in the terminal. On my terminal, st, GUI colors look perfect in the terminal. The screenshot above shows that.

We can add something like spacemacs-theme-force-terminal-colors but I'm not sure if there's really a demand for this.

Well, what I'm asking for is more like spacemacs-theme-force-gui-colors. This will save me from the nasty (defun true-color-p () 1)

[nashamri]

Then this is a bug in the true-color-p function. The theme should always try to use GUI colors, so if we can fix this issue with true-color-p, there won't be a need for an additional option.

[Naheel-Azawy]

That would be even better I guess!

[monkeyjunglejuice]

@Naheel-Azawy @nashamri

When Emacs is starting up as a daemon from command line emacs --daemon=srv1 and init.el is run, there is no GUI active. That means terminal colors will be set, because true-color-p evaluates to nil at this time. So if you connect an Emacsclient emacsclient -s srv1 -c, the theme will have the wrong (terminal) colors.

Once there's a GUI Emacsclient, true-color-p will become t of course, then if you load the theme again, the GUI theme loads and the correct colors (GUI) show up.

Here's a test. You can put the following code into init.el and make sure not to load the Spacemacs theme (load-theme 'spacemacs-light t) anywhere else:

(if (display-graphic-p)
    (message "display-graphic-p => TRUE before loading the theme")
  (message "display-graphic-p => FALSE before loading the theme"))

(defun load-spacemacs-theme-debug ()
  (message "Loading Spacemacs theme ...")
  (load-theme 'spacemacs-light t)
  (message "Loading Spacemacs theme ... done!"))
(load-spacemacs-theme-debug)

(if (true-color-p)
    (message "true-color-p => TRUE right after loading the theme")
  (message "true-color-p => FALSE right after loading the theme"))

My workaround is to load the theme not in init.el, but within a file ~/.emacs.d/lisp/init-emacsclient.el and then requiring it via emacsclient -s srv1 -e "(require 'init-emacsclient)" when invoking Emacsclient (so the theme loads only once when creating the first Emacsclient frame). But that's not a real solution, as it doesn't work well when using terminal clients and GUI clients at the same time.

[Naheel-Azawy]

@monkeyjunglejuice That makes sense now. Great explanation, thank you!