Does it behave properly when you do emacs -nw in a terminal, or does it look the same?

I think what is happening is that the same set of color definitions are being used across all frames, regardless of whether they are GUI or terminal. I can think of a couple workarounds until I fix this properly:

• M-x load-theme solarized-dark (assuming you're on Emacs 24) in the terminal frame, which should reload all frames using the terminal color definitions or
• set solarized-degrade to t, which will always use the 256 terminal mode in all frames.

I think there are two things that need to be done to handle this correctly:

• figure out how to update the face definitions on a per-frame basis
• add a hook to after-make-frame-functions to update the faces for that frame

Does it behave properly when you do emacs -nw in a terminal, or
does it look the same?

It works, in the sense that my colors are the same as in the parent
terminal. I would prefer to have different themes for my terminal and
emacs. Otherwise I am confusing my terminal sessions and emacs -nw in
those terminals. I don't really know how previous versions of solarize
worked, but it was doing exactly this as far as I can remember. And I
think it was exactly (setq solarize-termcolor 256) which was making it
work.

• M-x load-theme solarized-dark (assuming you're on Emacs 24) in
  the terminal frame, which should reload all frames using the
  terminal color definitions or

This one works.

• set solarized-degrade to t, which will always use the 256 terminal mode in all frames.

Also works, but colors sucks :( Prefer not to.

I think there are two things that need to be done to handle this correctly:

• figure out how to update the face definitions on a per-frame basis
• add a hook to after-make-frame-functions to update the faces for that frame

I have pretty basic understanding of emacs faces, but as far as I can
see, faces have conditional definitions:

(defface foo
'((((class grayscale)
(background light)) (:background "DimGray"))
(((class grayscale)
(background dark)) (:background "LightGray"))
(((class color)
(background light) (min-colors 88)) (:background "tan"))
(((class color)
(background dark) (min-colors 88)) (:background "gray20"))
(((background light) (min-colors 16)) (:weight bold))
(((background dark) (min-colors 16)) (:weight bold))
)
"Face used to highlight currently debugged line."
:group 'ess-debug
)

As we are on this, I believe solarize should define a set of 16 faces
for all it's colors like solarize-base, solarize-red etc. Then, if I am
not mistaken, emacs will be able to install them automatically depending
on the context.

It's really inconvenient to customize colors now. Suppose some package
defines a face 'foo-face which really doesn't fit into solarize theme. I
want it to be solarize-red. What shall I do then? Now I just go to
source file and modify the solarize definitions. Pretty awkward. What I
should do, instead, is something like this in my .emacs:

(setq foo-face solarize-red)

What do you think?

Well, solarized faces are a bit more than 16 due to formating differences. One can use :inherit face attribute to define others based on the basic 16th.

I am actually planning to use conditional faces solve the emacsclient issue, and also to unify solarized-dark and solarized-light into a single theme. That way different frames can use different modes (e.g., the light mode in the GUI and the dark mode in tty emacsclients). And if you have emacsclients running in both 16- and 256-color terms, each will use the correct colors.

The move away from solarized-termcolors was to allow Solarized to automatically use the right set of colors in different terminals, however it interacted badly with emacsclient. But the conditional faces are a change that needed to be made anyway, and this emacsclient breakage has just forced my hand.

I don't think defining faces to represent the colors will work, because there are way more than 16 – a face combines foreground color, background color, and many formatting options. I do want to make it easier to customize package faces, but I'm not quite sure what the best approach is yet. However, I am happy to merge Solarized faces for different packages into the repo, so if you do edit the source to make them work, please feel free to submit a patch.

I don't suppose there's any progress on this? I'm having to do a lot of reloads of the theme to get emacsclient -t to work...

I wonder if there's any progress??

I currently have this in my .emacs, which reloads the theme whenever I'm using a console frame. It's not pretty, but it makes emacsclient -t usable for me.

; Work around broken solarized colours in emacsclient -t by reloading the theme
; whenever a frame is create/deleted and when the server is done editing
(defun thj-reload-solarized (frame)
  (select-frame frame)
  (load-theme 'solarized-dark))
(defun thj-reload-solarized-on-delete (&optional frame)
    (load-theme 'solarized-dark))
(add-hook 'delete-frame-functions 'thj-reload-solarized-on-delete)
(add-hook 'server-done-hook 'thj-reload-solarized-on-delete)
(add-hook 'after-make-frame-functions 'thj-reload-solarized)

Hello, I found a simple hook, which works for me.
Refer http://stackoverflow.com/questions/18904529/after-emacs-deamon-i-can-not-see-new-theme-in-emacsclient-frame-it-works-fr

(if (daemonp)
    (add-hook 'after-make-frame-functions
              (lambda (frame)
                (select-frame frame)
                (load-theme 'solarized-dark t)))
      (load-theme 'solarized-dark t))

The unified theme (solarized instead of solarized-dark/solarized-light) has now been merged into master. This should all behave much better now.