doom-themes: a 68-theme megapack for GNU Emacs

What doom-themes actually solves for Emacs users

Emacs ships with a handful of built-in themes and no opinion about the rest. Anyone who wants a dark colorscheme ends up either writing face definitions by hand or installing themes one at a time from MELPA, each with its own package name, its own loading convention, and its own gaps in coverage for modes like org-mode or treemacs. doom-themes collapses that into one package. The README describes it as a "theme megapack for GNU Emacs, inspired by community favorites," and the theme list shows the shape of it: doom-one as the flagship, inspired by Atom One Dark, plus 67 themes the community submitted, many of them ports of colorschemes that already existed for VSCode, Vim or Atom.

The target reader is someone who wants a dark or light theme that covers more than the core faces. The README states that special attention is given to Doom Emacs and solaire-mode support, but that the pack "will work fine anywhere else." That second clause matters, because the package name and the repository name both say Doom, and a plain Emacs user could reasonably assume it is off limits. It is not. The install section gives a use-package example that has nothing to do with the Doom distribution.

The value is not in any single theme. It is in the extension functions that ship alongside them: doom-themes-visual-bell-config, doom-themes-neotree-config, doom-themes-treemacs-config and doom-themes-org-config. Those correct fontification and UI behavior that the raw theme files would otherwise leave inconsistent across modes.

How the pack is laid out and what loads when

The repository root holds doom-themes.el and doom-themes-base.el, with a themes/ directory beside them and an extensions/ directory for the per-plugin configuration. The Makefile confirms this split: the compile target runs emacs -batch with -L . and -L themes/ and byte-compiles both *.el and themes/*.el. So the base file and every individual theme are compiled separately, and the themes directory is on the load path at build time.

Loading works the way Emacs themes normally do. You call load-theme with a symbol, and the README's example uses (load-theme 'doom-one t) with the no-confirm argument. What doom-themes adds is the surrounding configuration layer. The use-package example sets doom-themes-enable-bold and doom-themes-enable-italic as custom variables, which the README annotates as global settings: if bold is nil, bold is universally disabled, and the same for italics. That is a pack-wide switch rather than a per-theme one, which is convenient if you dislike italic comments and annoying if you want italics in one theme and not another.

The extension functions are opt-in. You call doom-themes-visual-bell-config to get a flashing mode-line on errors, doom-themes-org-config to correct org-mode's native fontification, and either doom-themes-neotree-config or doom-themes-treemacs-config depending on which file tree you use. The neotree config carries a hard dependency the README states plainly: nerd-icons must be installed. The treemacs config takes a theme name through doom-themes-treemacs-theme, defaulting in the example to "doom-atom", with "doom-colors" offered as a less minimal icon theme.

Installing doom-themes under Doom Emacs or with use-package

There are two documented paths. If you run Doom Emacs, you do not install anything by hand. The README states that the built-in :ui doom module installs and configures doom-themes for you and loads doom-one by default. To pick a different theme you set doom-theme in your config file. The example given is:

;; in ~/.doom.d/config.el
(setq doom-theme 'doom-city-lights)

After that change, restarting Emacs or reloading your config should show the doom-city-lights palette instead of doom-one. The theme name must match one of the entries in the README's theme list.

For everyone else, doom-themes is available on MELPA, so the package manager handles retrieval. The README's example configuration lays out the common defaults:

(use-package doom-themes
  :ensure t
  :custom
  (doom-themes-enable-bold t)
  (doom-themes-enable-italic t)
  (doom-themes-treemacs-theme "doom-atom")
  :config
  (load-theme 'doom-one t)
  (doom-themes-visual-bell-config)
  (doom-themes-neotree-config)
  (doom-themes-treemacs-config)
  (doom-themes-org-config))

The :ensure t form tells use-package to install the package from your configured archives if it is missing. On evaluation, load-theme applies doom-one without prompting, and the four config calls wire up the visual bell, the neotree and treemacs icon themes, and the org-mode fontification corrections. If you use treemacs rather than neotree, drop the neotree call. If you do not use either, drop both, because each config function assumes its plugin is present.

If you want to build from a checkout rather than from MELPA, the Makefile provides the commands. Running make compile byte-compiles the base file and every theme, and make test runs the test suite with test/test-helper.el and the test/*-test.el files loaded in batch mode. make clean removes the generated .elc files, the autoloads file and editor backups.

Where the megapack model breaks down

The most obvious limitation is stated by the project itself. The README says the pack includes 67 themes "submitted to us by the Emacs community" and that PRs are welcome "to help us maintain and address inconsistencies in them." That is an admission that the non-flagship themes vary in completeness. A theme ported from a VSCode or Vim colorscheme may cover the faces its porter cared about and miss others, and the README does not claim otherwise. If you pick a theme far down the list, expect to inspect it rather than trust it.

The second limitation is the bold and italic switches. Because doom-themes-enable-bold and doom-themes-enable-italic are global, turning italics off to fix one theme's comment faces turns them off everywhere in the pack. There is no per-theme override documented in the README.

Third, the extension functions are not free. doom-themes-neotree-config requires nerd-icons to be installed, and the README flags this with an exclamation mark. Calling it without that dependency is a setup error, not a graceful degradation. Similarly, the treemacs configuration only makes sense if treemacs is loaded, and the org configuration only matters if you use org-mode.

Finally, this is not a theme engine. It does not generate palettes, does not derive faces from a base color, and does not give you a programmatic API for building your own theme from a specification. If that is what you want, doom-themes is the wrong package.

doom-themes against hand-rolled and generated Emacs themes

The realistic alternative is writing your own theme file, or using a generator that produces one from a palette definition. A hand-written theme gives you exactly the faces you want and nothing else, at the cost of doing the porting work yourself for every mode you use. That work is precisely what the doom-themes extension functions exist to absorb: org-mode's native fontification is called out in the README as something the pack corrects and improves, and that correction is not something a minimal custom theme gets for free.

A generator takes the opposite approach. You supply colors, it emits face definitions, and the output is mechanical and consistent. The difference in practice is coverage. A generator will faithfully apply your palette to the faces it knows about and silently do nothing for the rest. doom-themes, by contrast, is a fixed set of hand-adjusted themes where a human decided what each face should look like, which is why the pack can offer a treemacs icon theme choice between "doom-atom" and "doom-colors" and why the README can describe doom-earl-grey as "a gentle color scheme, for code." That kind of judgment is not reproducible from a palette file.

The trade-off runs the other way too. With a generator you own every face and can regenerate after an Emacs upgrade changes a face name. With doom-themes you wait for the pack, or you submit the PR the README invites. The repository's last push was on 2026-08-26, so the pack is being touched, but there are no retrieved releases, which means changes arrive through the master branch and MELPA rather than through tagged versions.

Licence, maintenance and what upgrading costs you

The repository is MIT licensed. For a theme pack that is about as permissive as it gets: you can copy a theme file into your own configuration, modify it, and redistribute it, provided you keep the licence notice. Several of the themes are ports of colorschemes that originated elsewhere, and the README's theme list links each one to its upstream source. MIT covers the Emacs Lisp in this repository; it does not automatically grant you rights to the upstream design, and the README does not discuss upstream licensing. If you plan to redistribute a ported theme, follow the link in the theme list and check the original project's terms. That is a factual gap in the documentation, not legal advice.

Upgrade cost is low but not zero. Because there are no retrieved releases, your package manager will pull whatever is on master at the time. Theme files are data, so a change to one theme does not break your configuration unless you were relying on a specific face's color. The extension functions are the part that can shift, since they touch org-mode and file-tree plugins whose internals change independently. The Makefile's test target exists for this reason: make test runs the batch test suite against test-helper.el and the test files, which is the check to run if you fork the pack or modify a theme. There is no documented rollback procedure in the README, so pinning a working commit in your package manager's lockfile is the only mechanism the documentation supports.

Editorial conclusion

Adopt doom-themes if you already run Doom Emacs, or if you want a large set of ported community color schemes behind one use-package form with org-mode fontification corrections and solaire-mode support. Do not adopt it if you need a single hand-tuned theme you control end to end, or if you run a non-Doom, non-use-package setup and dislike loading many theme files. Before switching, check that your chosen theme appears in the README's theme list, confirm the MELPA package name is doom-themes, and run make test from a checkout if you intend to modify any theme file.

Frequently asked questions

Official sources

1. doomemacs/themes on GitHub
2. Issues
3. License: MIT
4. README