This is something to think about. In 8-color mode, I set background and some others to nil, because we don't have enough colors otherwise. But the tradeoff is that if your terminal is dark, you can't use light in Emacs, and vice versa.

The question: is it more important to allow light/dark in Emacs independent of terminal coloring, or to have the proper background (and maybe some more foreground) colors.

Perhaps it should be another custom variable? solarized-enable-256+-colors or something.

Or maybe (setq solarized-use-terminal-theme t) that lets the theme file know it can defer lots of colours to the terminal itself? This is more your department. :)

I also suffer from this. I guess it's safe to assume that most people who opt for Solarized theme in Emacs have it also set in their terminals.

To revisit this: given that the README is so adamant that one sets one's terminal to the Solarized theme as well:

If you are going to use Solarized in Terminal mode (i.e. not in a GUI 
version like Cocoa or X11 Emacs), please please please consider setting
your terminal emulator's colorscheme to use the Solarized palette.

It should deal with that correctly (in fact I'm surprised it doesn't, because it certainly used to).

I'm a bit confused by this issue now – @bradleywright, if you're using the Solarized Dark iTerm2 theme, shouldn't your terminal be supporting only 16 colors? When in 256-color mode, we just go into “good enough” mode, because we can't match exact colors. And I think in 256-color mode, we need to override the background, because Emacs’ background-mode isn't enough to tell us your background properly matches Solarized (whereas, in 16/8 color mode, we have to assume your term is set up for Solarized colors).

What are the behavioral issues you run into when your terminal is set to 16 colors?

I have set my $TERM to xterm-256colors as suggested by Ethan Schoonover here: altercation/solarized#97

@sellout if I explicitly set it to xterm-16color it's fine.

So xterm-16color doesn't actually exist on most Linux boxes. What TERM should I be setting? If I use xterm-256 Emacs does the above, so I'm kind of stuck.

I think just term or term-color will give you 16-color mode.

I am having the same issue with emacs -nw while using iTerm2 on Mac OS X Lion. Has any progress made on this issue? Is there any specific information I can provide you to resolve it?

term and term-color aren't 16, they're 8. As far as I can tell there aren't any valid $TERM values in infocmp that have 16 colours. So I'm not sure how this can ever work.

On Archlinux, using URxvt with the Solarized Dark colorscheme, I can confirm that this bug applies too. When trying to use the Emacs colorscheme, the background goes black. I tried to set solarized-termcolors 16 but it didn't change anything.

I also had this issue on archlinux. Here's how I fixed it: I use urxvt with 16 colors and set them to the solarized palette using Xresources. The solarized theme in X11 emacs works just fine, but with -nw its messed up. Investigating what colors are actually used for the scheme in emacs -nw I found that the hex values for 256 color terminals are used. So I checked what piece of code picks the colors and found in solarized-definitions.el:

    (let* ((index (if window-system
                         (if solarized-degrade
                             3
                        (if solarized-broken-srgb 2 1))
                           (case (display-color-cells)
                             (16 4)
                             (8  5)
                             (otherwise 3)))))

So for me the 16 case should apply, hence I checked what emacs returns for (display-color-cells) : 88.
Turns out urxvt, compiled without 256 color support, can actually display 88 colors - from the urxvt manpage:

"In addition to the default foreground and background colours, urxvt can display up to 88/256 colours: 8 ANSI colours plus high-intensity (potentially bold/blink) versions of the same, and 72 (or 240 in 256 colour mode) colours arranged in an 4x4x4 (or 6x6x6) colour RGB cube plus a 8 (24) colour greyscale ramp."

Thus, as a workaround, I changed the above code to:

(case (display-color-cells)
         (16 4)
         (88 4)
         (8  5)
         (otherwise 3)))

and now everything is fine.

hth

Thanks for the insight into what’s happening, @junaG.

That case should really be a nested if/else checking, for example, (< (display-color-cells) 256). Much more robust.

Also, it sounds like the 256 color mode in urxvt could still give the precise ANSI colors we want. Is that correct? If so, I wonder how we could automatically identify that case. Might have to bring back the solarized-termcolors variable, but with a smarter default.

I tried urxvt with 256colors enabled and indeed I get the precise ANSI colors. I have no idea how to identify that case though.

On Arch x64, I had the same issue; background went black and I got weird colors. Echoing $TERM and checking with M-x list-colors-display, I got 256 colors. Turns out, unlike contrary believe, Arch's urxvt is by default compiled and run with 256 colors.

So adding this in my .Xresources and reloading it with xrdb fixed the problem:
URxvt*termName: rxvt

Having struggled with color differences between running emacs and "emacs -nw" on urxvt for some time some observations that might help others hitting this problem (I'm using emacs 24.2 on Funtoo)

1. The background color when running "emacs -nw" is wrong on all emacs solarized repositories I tried. This one is least bad as the background becomes black(ish), which is at least workable. In the repository from bbatsov it becomes bright green. This problem is present for urxvt both with and without 256 colors enabled.

2. Setting Xresources to use solarized colors as recommended by the main solarized website appears to make no difference to the background problem. Color when using emacs -nw are still way off for both urxvt with and without 256 colors independent of whether Xresources is set up to use solarized colors.

3. The suggested work-around above is to start emacs on urxvt using TERM=xterm-16color emacs -nw. This indeed works when just looking at the output for emacs -nw as this becomes indentical to the output when running emacs directly. However this work-around doesn't work properly for using emacs in deamon mode as emacsclient with xterm-16color leads to comments having same colors as background (other colors are also off) (this applies to both with and without 256 colors enabled). Reloading the config file once with (M-x load-file [ent] .emacs) will fix this issue for subsequent calls; so not too much of a problem.

4. The fix suggested by junag to add (88 4) indeed works in cases that urxvt is not compiled with 256 color support. Also here colors in emacsclient are not completely correct (but in this case everything is at least readable, so better than using the xterm-16color workaround)

5. Suggested workaround by bassu to set TERM to rxvt for me doesn't give the correct colors when comparing against solarized website. So don't think that is the correct workaround.

I for now will stick with the work-around in number 4, which for me works best.

@moesasji
My workaround presumes the following:

1. You have configured Xresources according to your taste
2. You know how to start an application in an appropriate overridden color bit

Themes like Solarized have reverse color pallets and it's not so easy to tweak it for every environment. The suggested workaround gives me 90-95% compatibility in lower color mode without much bleeding!

Hi, I am running Ubuntu 12.04.3 with emacs 23.3.1 .I come across the same issue when I setting .bashrc file 👍 export TERM="xterm-256color".
Things fixed when I just set:export TERM="xterm".

And I use emacs -nw mode

What is the definitive answer on this issue? Am I supposed to have an alias that prepend TERM=xterm whenever I want to start emacs in a terminial?

This should be fixed in c677b26.

Thanks, latest version works perfect on my rxvt-unicode-256color.