I have the following line in my .emacs to load the gruvbox theme:

(load-theme 'gruvbox t)

When opening Emacs, I get the following error

Unable to load color "color-235"

However, when I call load-theme again, everything works out fine.

Why is this error occurring?

How can I fix this so that I do not need to call load-theme every time I open Emacs?

  • Could you show us more of your .emacs file? – rekado Nov 6 '14 at 7:06
  • Sorry this is such a late answer, but the original answer was erroneous and so the issue should be properly addressed. I added images to my answer today to help illustrate the issue for anyone interested. – ocodo Aug 20 '16 at 6:24
  • Providing the theme is loading and looks as it should, you can disregard these unable to load color errors. – ocodo Aug 20 '16 at 6:32

Well, that's a bug in the theme.

(let ((gruvbox-dark0_hard  (if (display-graphic-p) "#1d2021" "color-234"))

It uses RGB values if the current terminal is a graphical one, and names like color-234 otherwise. So if you start Emacs as a demon, color-234 is used; when you open a GUI frame and load the theme again, there's a GUI, so the RGB values are used.

The obvious fix is to edit gruvbox-theme.el and get rid of that display-graphic-p nonsense: replace-regexp all the occurrences of

(if (display-graphic-p) \("[^"]*"\) "[^"]*")

by \1. The other case is for 256-color text terminals, but Emacs should already be translating color values. If Emacs doesn't know the color values corresponding to the terminal colors, the proper solution would be to call tty-color-define to define them, not to break the theme for people who use both GUI frames and text frames or the demon.

  • @Giles unfortunately you are not correct, please edit your answer to avoid misleading other users of themes which use the display-graphic-p technique. Many thanks. See my answer for the correct solution. – ocodo Aug 20 '16 at 6:22
  • @EmacsFodder After reading your answer, I don't understand what's wrong with mine. The way gruvbox calculates colors is fundamentally buggy since it assumes that all terminals can display the same colors. Calling display-graphic-p without an argument should only be done when you know what the current frame is. Different displays have different capabilities. If you don't want to rely on Emacs's color translations, you need to calculate them per frame. – Gilles 'SO- stop being evil' Aug 20 '16 at 9:48
  • you make glib assertions the theme is buggy, and advise patching the theme, making people break the palette of the theme. This is unhelpful. It would be far more reasonable to provide a comprehensive answer, mentioning the recalc issue for different frames in GUI/Terminals, and perhaps mention face color classes. Better yet suggest that the OP simply raise an issue with the theme author, so that it can be fixed properly. – ocodo Aug 20 '16 at 11:23

Unfortunately Giles is not correct about Emacs properly converting hex colors to Xterm colors.

No nearest match translation is done. (The visual results are bad) themes have a color class system which they are supposed to use, instead of the display-graphic-p solution used in Gruvbox.

The only problems with the display-graphic-p solution is that it only calculates at first load. Which can cause issues when running an Emacs daemon and starting both GUI and Terminal emacsclient.

OP could have a problem if the terminal isn't configured for Xterm 256 color mode. These unable to load color errors will show up anyway and can be safely ignored.

NB: This question would have attracted better support if posted as an issue to the Gruvbox repo issues. I suggest that anyone having problems with a theme or package, attempt to get help from the maintainers before trying here.

Updated with additional images...

Edit: To illustrate that the theme is working as expected, I made a couple of screen grabs on Darktooth which originated as a fork of Gruvbox, and uses an identical palette creation technique. The same errors are shown, however they're meaningless, as the color which should be applied by the xterm color name, is applied correctly.

Fig 1 - The Theme rendered in an xterm-256color compat terminal with the display-graphic-p predicate selecting the xterm color names:

Fig 1

Fig 2 - The Theme rendered in an xterm-256color compat terminal with the display-graphic-p predicate removed, therefore just the hex colors are passed to Emacs for translation:

enter image description here

While Emacs does an OK job, it's not as the theme designer intended, and we can see that the XTerm colors are being sent correctly in Fig 1 but not Fig 2.

Meanwhile, Emacs is sending "unable to load color" errors to *Messages* but these errors are spurious and can be disregarded. As long as TERM=xterm-256color is in the current environment and the terminal can support xterm 256 color mode, the theme will still display as intended.

I hope this helped.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.