Development roadmap

Doom Emacs hasn’t been easy to keep up with—it has many moving parts, and until recently announcements and updates were hidden behind a login-gated Discord server, in git commit logs, or floating around in incomplete docs and unlisted gists[1]. Not fun.

Cue the Discourse. Users are initially subscribed to #news and #news:releases, but this post offers a high-level overview of my plans for Doom Emacs.

But if you want more exhaustive and low-level roadmaps:

:newspaper: Every other week (starting 2022-04-21T22:00:00Z 2022-05-08T22:00:00Z[2]), I’ll post a newsletter to the #news category to touch on the state of Doom, Emacs, and our community.

:pushpin: Wondering what doomemacs/core and doomemacs/modules are? I plan to split the project up into multiple repos, but for now they refer to the core/ and modules/ sub-directories in our main repository.


  • v3.0.0

    This release is focused on resolving Doom’s technical debt, accrued during its time as my private config. Poor documentation, cut corners in Doom’s core, and an inaccessible community (on Discord) made it difficult to onboard new maintainers, coordinate existing contributors, or address systemic issues in Doom’s design. They also haven’t done my inbox or issue trackers any favors.

    • Bump minimum required Emacs version from 26.x to 27.1.
    • Reclaim master branch.
    • Adopt Discourse.
    • Move hlissner/doom-emacs to doomemacs/doomemacs.
    • Rewrite and standardize in-repo documentation.
    • Publish documentation to
    • Rewrite Doom’s CLI (#4273).
    • Split doomemacs/doomemacs into:[3]
      • doomemacs/core
      • doomemacs/modules (and adopt CalVer)
      • doomemacs/contrib-modules (and adopt CalVer)
    • Onboard module maintainers.
  • v3.1.0

    • Release a Doom Emacs Github action
    • First-class support for literate configs.
    • Drop use-package (internally).
    • Parallelize doom upgrade.
    • On-the-fly module activation (e.g. open *.json file, prompt to install :lang json, no restart needed).
    • Nix-based library for isolated testing environments (sandbox 2.0).
    • Convert $ doom install into a configuration wizard.
    • 28.x optimization run.
  • v3.2.0

    • Remove core packages or move them out to modules (up to 50% of them).
    • Replace projectile with project.el.
    • Replace smartparens with electric.el.
  • Backlog

    • Add pdumper and/or CRIU support.
    • Bump minimum required Emacs version from 27.1 to 28.1 (probably early/mid-2023).







  1. What can I say? My precognition must be rusty to not see y’all coming. ↩︎

  2. $DAYJOB set me back a couple weeks, but I’m back now. ↩︎

  3. This split happens in two steps because:

    • Rewriting Doom’s CLI will take a while, and I want the benefits of an Github organization sooner (particularly codeowners and teams).
    • The CLI rewrite includes the ability to declaratively manage module libraries (similar to how it manages packages).
  4. There is significant overlap between the two, but the latter is clearly superior; ivy will otherwise be a maintenance burden going forward. ↩︎