Emacs 29.0.50 support

I’m creating this post to track Doom’s support for 29.0.50 (aka Emacs HEAD/master), and list safe commits of Emacs known to work reasonably well with recent versions of Doom.

Before I proceed, a disclaimer that every user on 29 should hear once:

:warning: Emacs 29.0.50 is in an unstable phase of its development, where little-tested refactors, bugfixes, and experimental features are trickling in, alongside breakages, hotfixes, and sudden reverts. Its stability will change from week to week, so use it at your own risk!

You may see similar stability curves with development or pre-release builds of Emacs 28 (like 28.2.50, 28.1.90, 28.0.50, where *.50 = development builds, *.9X = pre-release builds).

To avoid these issues, I highly recommend either:

  • Downgrading to 28.2 (the version Doom is most tested against),
  • Finding a stable commit of 29 (listed below) and sticking to it for as long as possible,
  • If you encounter issues, make sure both Emacs and Doom is up-to-date before reporting it. It may have already been resolved, and I am rarely able to offer partial fixes for specific commits of Emacs.
  • Check this post before reporting new 29 issues. Known issues and workarounds will be listed below.

Does Doom support 29 yet?

No. There likely won’t be official support until Q1/Q2 2023, when upstream development is likely to slow down in preparation for a 29 release in Q3/Q4 2023.

That said: I plan to adopt 29 again sometime mid-October, so I can stay ahead of its issues. Until then, investigation and resolution of issues in development builds will be delayed.

Safe commits

Emacs Doom Confirmed by
43c0ebd8bcdd (2022-09-21) 285b460c80e4 (2022-09-30) @hlissner (NixOS, Ubuntu)

:pushpin: How is this tested? Given the sheer number of packages and wide variation in user configs, it’s impossible to catch all issues (and too wide a net would catch too many false positives anyway), so this focuses on major issues, reproducible by users who can dogfood a commit for at least a week, and can (at least) ensure the following:

  • It starts up without warnings, errors, or unexpected behavior (with its default module list) in these four contexts:
    • emacs -Q
    • emacs
    • emacs --debug-init
    • doom run
  • Doom’s incremental loader and Emacs’ deferred native compilation yield no errors (wait 5-10s after startup while it kicks in) – though warnings are fine.
  • These bin/doom commands run without issue (discounting transient package hiccups and known Doom bugs):
    • doom sync && doom build
    • doom doctor
    • doom info
  • None of these produce an error/warnings:
    • Opening any simple major mode (has no required external deps): org-mode, emacs-lisp-mode, and markdown-mode
    • Opening any lsp-mode enabled major mode with LSP dependencies satisified: js2-mode, python-mode, and/or rustic-mode).
    • Switching themes.

This is not an exhaustive list. Henrik has access to an additional, unreleased test suite as well, which confirm the above and more, but only for Linux (at the moment), so his confirmation may weigh a little more there, but is still no guarantee.

Known issues

  • (2022-09-30T22:00:00Z) Startup time is doubled. (Cause unknown; no workaround)
  • (2022-09-30T22:00:00Z) Warning at startup or during doom sync: WARNING: No org-loaddefs.el file could be found from where org.el is loaded.. This might be due to emacs@aa9eaac deprecating the autoload.el library. Doom still uses the old one, but straight uses loaddefs-gen.el. Implementation differences may explain this issue.
  • (2022-10-04T22:00:00Z) Emacs is unable to locate/load fonts (all-the-icon icons go missing. Less often, doom-font and other doom-*-fonts may fail to load too). (Cause unknown; no workaround)
Resolved issues
  • Breaking change in hash-table-{keys,values} (emacs-mirror/emacs@4311bd0bd73c).
    • Explanation: Doom indirectly relied on hash-table-keys returning entries in insertion order. The upstream changed that.
    • Fixed in: doomemacs@285b460c80e4 (2022-09-28T22:00:00Z)
    • Reported in: #6813, #6859
  • Breaking regression in loaddefs-gen.el (emacs-mirror/emacs@0d383b592c2f).
    • Explanation: The Emacs 29 loaddefs-gen library invokes emacs-lisp-mode without unsetting emacs-lisp-mode-hook. This adds a new point of failure where other packages (like overseer.el) can get called/loaded from emacs-lisp-mode-hook while autoloads are generated (before those packages have been added to load-path).
    • Fixed in: doomemacs@7e931ec58634e (2022-09-09T22:00:00Z).
    • Reported in: /t/3149

This post is an ongoing work-in-progress. If you’ve identified safe commits or known issues, let me know below. Once I’ve confirmed they are 29-specific, I will track them here.

Also, I’ll post a changelog below at the end of each day (if anything has changed).

  • Move changelog into replies.
  • Add emacs@43c0ebd8bcdd doomemacs@285b460c80e4 to safe commits.
  • Add “Startup time is doubled” to known issues.
  • Add report of Emacs 29 mislabeled as Emacs 28.2.50.
  • Add recently fixed module load order issue to known issues (for posterity).
  • Remove “Some builds of Emacs 28.2.50 distributed by package managers (Homebrew, so far) may be mislabeled, and are actually 29.0.50.” – turned out to be a false alarm: all initial reports came back citing unrelated causes.
  • Add "Breaking regression in loaddefs-gen.el" entry to (resolved) known issues.
  • Add “No org-loaddefs.el file” issue to known issues.
  • Fix Doom commit link for resolved “hash-table-{keys,values}” issue.
  • Add “Unable to locate/load icon fonts” to known issues.

This is also an issue.