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 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:
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.