Solarized for Emacs is a deftheme with a fixed palette and nine borrowed ones

A deftheme over a palette that does not move

Solarized for Emacs is an Emacs 24 bit theme that makes use of the Solarized palette developed by Ethan Schoonover. The README is explicit about the priority order. The intent is always that solarized-dark and solarized-light give you the best possible experience, and that other palettes will never influence the theming decisions, because they are complementary.

The implementation detail that matters for anyone upgrading from an older Emacs theme is stated next: the theme is implemented in terms of customisations and deftheme, and it does not require the color-theme package. That means it does not drag in the old colour theme compatibility layer, and it uses the mechanism that Emacs itself supports.

The official support statement is Emacs 24 and later, which is old enough to suggest the theme is stable rather than experimental.

The repository layout shows how the pieces are separated. solarized.el is the entry point, solarized-faces.el holds the face definitions, solarized-palettes.el the colour data, and solarized-theme-utils.el the shared helpers. Each variant then has its own file, so solarized-dark-theme.el, solarized-light-theme.el, solarized-zenburn-theme.el and the rest are separate loadable units rather than switches inside one file. There is also a child-theme-example directory, which is the pattern for building a theme on top of this one.

The licence recorded for the repository is unknown, while the README carries a GPL 3 badge, so the licence file is the place to confirm the terms.

Installing from MELPA and loading a variant

Solarized for Emacs is distributed through MELPA and installed with package.el.

M-x package-install solarized-theme

That single command installs the package, and the README says it installs two variants of the theme, solarized-light-theme and solarized-dark-theme. You load one of them with M-x load-theme, and the setup instructions for each library are in the readme of the package.

To have the theme active when Emacs starts, you add a load-theme form to your init file:

(load-theme 'solarized-light t)

or the dark equivalent:

(load-theme 'solarized-dark t)

The second argument is the flag that enables the theme for the session, which is the standard idiom.

Switching between the two without restarting is a single command, M-x solarized-toggle-theme, and it toggles between the light and dark variant automatically. For a user who spends the day in one and occasionally wants the other, that is the feature that gets used most.

The package is published on both MELPA and MELPA Stable, according to the badges, so a conservative setup can pin the stable channel while a developer working on the theme tracks the development one. The repository also carries a CHANGELOG.md and an UPGRADE-GUIDE.md, which matters because this is a package with a long history and a version line that has moved through a major rewrite.

Ten companion palettes, and an honest note about them

Beyond the two canonical variants, the package ships ten more themes, and the README is unusually candid about what they are worth.

The list is solarized-dark-high-contrast and solarized-light-high-contrast, solarized-gruvbox-dark and solarized-gruvbox-light, four selenized variants covering dark, light, black and white, solarized-zenburn, and solarized-wombat-dark.

The guidance is that you should not expect the complementary themes to be fully accurate or the most suitable versions of how to apply those palettes in an Emacs theme. The important aspect is that the colour usage should be about the same as it is with the default Solarized palette.

The reasoning about individual colours is specific. Violet is one of the most pronounced accent colours in the Solarized palette, which is one reason the theme rarely uses it, and in another palette violet might stand out less and therefore be used more often. The original Zenburn palette has no violet at all: it is created by blending blue and magenta to fit the theme, so it is tilted towards what the theme has decided.

The TLDR is the most useful line in the section. While solarized-gruvbox-light might be a good complement for users of solarized-light, another theme not contained in this package, gruvbox-light or whatever, might be more finely tuned in relation to the Gruvbox palette.

That is an admission that a companion variant is a convenience, not the best route to that palette, and it is worth taking at face value when you decide which variant to use.

Tuning the theme, and the ordering rule that trips people up

The customisation section starts with the easy route and then gives you the code equivalent. If you dislike the low-contrast modeline or fringe, you can customize them either through M-x customize-group solarized or by setting the values with elisp.

;; make the fringe stand out from the background
(setq solarized-distinct-fringe-background t)

;; Don't change the font for some headings and titles
(setq solarized-use-variable-pitch nil)

;; make the modeline high contrast
(setq solarized-high-contrast-mode-line t)

;; Use less bolding
(setq solarized-use-less-bold t)

;; Use more italics
(setq solarized-use-more-italic t)

;; Use less colors for indicators such as git:gutter, flycheck and similar
(setq solarized-emphasize-indicators nil)

The set of knobs covers more than the modeline. There is solarized-scale-org-headlines to leave org-mode headline sizes alone, solarized-scale-markdown-headlines to turn markdown-mode headline scaling on, a family of solarized-height-minus-1 and solarized-height-plus-1 through 4 settings to avoid all font size changes, and solarized-highlight-numbers to highlight all numbers.

Then there is the rule that catches people out. These settings need to be set before load-theme is invoked for Solarized. Alternatively you can invoke M-x solarized-reload after making configuration changes.

The reason is that load-theme applies the face customisations when it runs, so a variable set afterwards is simply too late for that load. solarized-reload exists to give you a second chance without restarting Emacs.

Overriding faces: tied to the theme or global

If a particular mode looks wrong to you, the README says you can override individual faces after loading the theme, and it distinguishes two functions for that.

custom-theme-set-faces keeps your overrides tied to the theme, so they travel with the theme and are removed when the theme is unloaded. custom-set-faces applies them globally, outside the theme system.

That distinction decides how a configuration should be written. A rule that only makes sense under Solarized, a face colour that has nothing to do with the palette, belongs in custom-theme-set-faces and is scoped to the variant it was written for. A rule that is your personal preference regardless of theme, your own idea of what a warning should look like, belongs in custom-set-faces and survives a theme change.

The example in the README starts with a comment about overriding org-mode heading colours and a custom-theme-set-faces call naming the solarized-dark theme, which shows the shape of the form: the theme symbol first, then the list of faces.

For anyone building a theme on top of Solarized rather than editing it, the child-theme-example directory in the repository is the reference for how that relationship is meant to work, and it is a better starting point than copying the palette file and changing it.

The development setup: Cask, Eldev and a v1 to v2 merge test

The Makefile shows how the project is developed and tested, and it is a good indicator of how seriously the theme is maintained.

Dependencies are managed with Cask, and the elpa target runs cask install and cask update before touching a touch marker file. Compilation runs cask build, which produces the byte-compiled elisp for every file in the top level.

Testing and linting are delegated to Eldev. The test target runs eldev -p test, and the lint target runs eldev lint. The comment in the Makefile notes that the suite runs under Eldev while the targets below still use Cask to launch a development Emacs, which is a different job, and that separation is why both tools are present.

The run target launches a development Emacs with cask exec emacs -q -l ./dev-emacs.d/init.el, and the dev target loads a set of files including the theme files and the test files.

The most interesting target is dev-merge, and it explains what the repository structure is for. It clones a test repository into dev-emacs.d/test-repo, checks out the v2 branch, merges origin/v1 into it, and then runs Emacs against the merged result. That is a compatibility test across the major version boundary of the theme, and it is why the UPGRADE-GUIDE.md and the CHANGELOG.md exist.

The repository also carries a DEV-GUIDE.md, a colorlab directory that presumably relates to the palette work, a screenshots directory that the README's image links point at, and a test directory.

The release history is steady. Version 2.0.5 was published on 2025-02-22, 2.1.0 on 2026-03-29 and 2.2.0 on 2026-07-28, and the last push to the master branch was on 2026-09-10.

Editorial conclusion

Adopt Solarized for Emacs if you already use the Solarized palette elsewhere, since the two canonical variants are the ones the project says are meant to give the best possible experience, and if you value a theme that states its own limits rather than pretending every variant is equally faithful. Do not adopt it for one of the companion palettes alone, because the README says those are complementary and that a dedicated theme such as gruvbox-light may be tuned better outside this package. Before you settle on it, check your Emacs version is 24 or newer, set any solarized variables before load-theme runs or your changes will be ignored, and decide whether you want the overrides tied to the theme with custom-theme-set-faces or applied globally.

Frequently asked questions

Official sources

1. bbatsov/solarized-emacs on GitHub
2. Issues
3. README
4. Releases