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:
- Our Github projects board breaks up open tasks into sub-projects.
- Our global issue tracker lists tasks that can’t be tackled yet or are low priority. I welcome PRs for them.
- Our global backlog lists tasks that can’t be tackled yet or are low priority. I welcome PRs for them.
- Our “Package Review” board lists all third-party packages we’re investigating for addition to or removal from Doom.
- Our Github organization is where all our repositories live.
Every other week (starting
2022-04-21T22:00:00Z2022-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.
Wondering what
doomemacs/core
anddoomemacs/modules
are? I plan to split the project up into multiple repos, but for now they refer to thecore/
andmodules/
sub-directories in our main repository.
doomemacs/core
-
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
todoomemacs/doomemacs
. - Rewrite and standardize in-repo documentation.
- Publish documentation to docs.doomemacs.org.
- Rewrite Doom’s CLI (#4273).
-
Split
doomemacs/doomemacs
into:[3] - Onboard module maintainers.
-
- 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).
- …
doomemacs/modules
-
-
:PRs welcome: Add
:send-region
&:send-buffer
handlers toset-repl-handler!
-
Add missing module
README.org
s (#1166) - Add :tools tree-sitter module (#5401, #6275)
- Add :input bidi module (#5526)
- Rewrite :editor format (see projects/6)
- …
-
:PRs welcome: Add
-
- Refactor :ui ligatures to use ligature.el (#5082)
-
Redesign
set-company-backend!
(see projects/8) - Add :config tutorial module (#6032)
- …
-
Backlog
- Add a
:tools db
module so Emacs can be used as a client for various SQL (and no-SQL?) databases. - A +nano flag for
:ui doom
- Add new
:theme
category for all-in-one UI theme modules (e.g.:theme doom
,:theme nano
, etc). Including modelines, color schemes, and other opinionated UI configuration behind flags. - Combine :ui treemacs and :ui neotree into
:ui sidebar
with+treemacs
,+neotree
and+dired
flags. - (Undecided) Drop
:completion ivy
? [4] - …
- Add a
doomemacs.org
TODO
doomemacs/themes
TODO
doomemacs/snippets
TODO
-
What can I say? My precognition must be rusty to not see y’all coming. ↩︎
-
$DAYJOB
set me back a couple weeks, but I’m back now. ↩︎ -
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).
-
There is significant overlap between the two, but the latter is clearly superior; ivy will otherwise be a maintenance burden going forward. ↩︎