Good artists borrow, great artists steal.

– Pablo Picasso

After spending the past couple of weeks updating Prelude and my personal Emacs config, I figured it wouldn’t hurt to see what the competition has been up to. I hadn’t done a proper survey of other people’s configs in years, and the Emacs landscape has changed quite a bit since the last time I looked.

So I went through Doom Emacs, Purcell’s emacs.d, Centaur Emacs, Prot’s dotfiles, and a handful of others. Here are some of the most interesting things I found – settings and tricks that I either didn’t know about or had forgotten about entirely.

Performance Tweaks

Disable Bidirectional Text Scanning (Doom Emacs)

If you don’t edit right-to-left languages (Arabic, Hebrew, etc.), Emacs is doing a bunch of work on every redisplay cycle for nothing. These settings tell Emacs to assume left-to-right text everywhere and skip the bidirectional parenthesis algorithm:

(setq-default bidi-display-reordering 'left-to-right
              bidi-paragraph-direction 'left-to-right)
(setq bidi-inhibit-bpa t)

The difference is hard to measure in small buffers, but in large files (think multi-thousand-line JSON or log files) it adds up. Doom enables this unconditionally and I’ve never seen anyone complain about it.

Skip Fontification During Input (Doom Emacs)

Emacs normally fontifies (syntax-highlights) text even while you’re actively typing. This can cause micro-stutters, especially in tree-sitter modes or large buffers. One setting fixes it:

(setq redisplay-skip-fontification-on-input t)

Emacs will defer fontification until you stop typing. In practice you never notice the delay – the highlighting catches up instantly – but scrolling and typing may feel smoother.

Increase Process Output Buffer for LSP (Doom, Purcell, Centaur)

The default read-process-output-max is 64KB, which is still quite conservative. Modern LSP servers like rust-analyzer or clangd routinely send multi-megabyte responses. Bumping this reduces the number of read calls Emacs has to make:

(setq read-process-output-max (* 4 1024 1024)) ; 4MB

If you use eglot (or lsp-mode), this is basically free performance. Three of the most popular configs out there all set it – that should tell you something.

Note: I’m really surprised I didn’t discover this one sooner. Probably that’s because I rarely work on big projects these days.

Don’t Render Cursors in Non-Focused Windows (Doom Emacs)

If you have several windows visible, Emacs draws a cursor in each of them – even the ones you’re not working in. It also highlights selections in non-focused windows. Two settings to stop that:

(setq-default cursor-in-non-selected-windows nil)
(setq highlight-nonselected-windows nil)

This is mostly a visual preference (I don’t mind the phantom cursors but I know some people find them distracting), but it also reduces rendering work.

All four of these performance settings are safe to add unconditionally – they have no downsides for the vast majority of users.

Kill Ring (Emacs’s Clipboard History) and Clipboard

Save the Clipboard Before Killing (Purcell, Prot, Centaur)

Here’s a scenario: you copy a URL from your browser, switch to Emacs, kill a line with C-k, and then try to yank the URL you copied earlier with C-y. Gone. The kill replaced it on the clipboard.

This setting makes Emacs save the existing clipboard content into the kill ring before overwriting it:

(setq save-interprogram-paste-before-kill t)

Now C-y gets the kill, and M-y gets you back to the URL. Such a small thing, but it eliminates a genuinely annoying problem.

No Duplicates in the Kill Ring (Doom, Prot)

Kill the same line three times and you get three identical entries in the kill ring, wasting slots. This deduplicates them:

(setq kill-do-not-save-duplicates t)

Persist the Kill Ring Across Sessions (Doom, Prot)

Most configs that use savehist-mode only persist search rings. But savehist can save any variable – including the kill ring. Add it and you get clipboard history that survives restarts:

(setq savehist-additional-variables
      '(search-ring regexp-search-ring kill-ring))

One thing to watch out for: the kill ring can accumulate text properties (fonts, overlays, etc.) that bloat the savehist file. Doom strips them before saving:

(add-hook 'savehist-save-hook
          (lambda ()
            (setq kill-ring
                  (mapcar #'substring-no-properties
                          (cl-remove-if-not #'stringp kill-ring)))))

Probably overkill for most people, but it’s good to be aware of if your savehist file starts growing suspiciously large.

Editing

Auto-Chmod Scripts on Save (Multiple Configs)

If you create a file that starts with #! (a shebang line), it should be executable. But you always forget to chmod +x it, run the script, get “Permission denied”, curse, go back, chmod, try again. This hook does it automatically:

(add-hook 'after-save-hook
          #'executable-make-buffer-file-executable-if-script-p)

Save a file with a shebang, and Emacs chmod +xes it for you. One of those things that should arguably be a default.

Note: Okay, I have to admit I’ve always known this one, but seeing it in so many configs made me want to include it here.

Sane Syntax in re-builder (Multiple Configs)

re-builder (M-x re-builder) is an interactive tool for developing regexps – you type a pattern and see matches highlighted live in the target buffer. The problem is the default syntax: read. In read syntax, you have to double-escape everything, so a word boundary is \\< and a group is \\(...\\). It’s the regexp equivalent of trying to type with oven mitts on.

Switch to string syntax and things look like normal Emacs regexps:

(setq reb-re-syntax 'string)

Now \< is \< and \(foo\) is \(foo\). Much less painful.

See also: If you want live feedback on the regexp structure as you type it (color-coded groups, character classes, etc.), check out minibuffer-regexp-mode – a new built-in mode in Emacs 30.

Prevent ffap from Pinging Hostnames (Centaur Emacs)

Ever had Emacs freeze for a few seconds when you ran find-file-at-point (or a command that uses it internally)? If the text under point looks like a hostname – say, something.com in a comment – ffap tries to ping it to check if it’s reachable. On a slow or firewalled network, that’s a multi-second hang.

(setq ffap-machine-p-known 'reject)

This tells ffap to never try network lookups. If you actually want to open a remote file, you can type the path explicitly.

Windows

Proportional Window Resizing (Purcell, Prot)

When you split a window with C-x 2 or C-x 3, Emacs halves the current window. If you already have a multi-window layout, this can produce one awkwardly tiny window while others stay large. With this setting, all windows in the frame resize proportionally:

(setq window-combination-resize t)

The difference is subtle but makes multi-window layouts feel more balanced without manual resizing.

Reversible C-x 1 (Purcell)

C-x 1 (delete-other-windows) is the nuclear option – it nukes your entire window layout to focus on one buffer. Then you spend the next minute recreating the layout you just destroyed.

With winner-mode and a small wrapper, you can make C-x 1 toggle: press it once to go single-window, press it again to restore the previous layout:

(winner-mode +1)

(defun toggle-delete-other-windows ()
  "Delete other windows in frame if any, or restore previous window config."
  (interactive)
  (if (and winner-mode
           (equal (selected-window) (next-window)))
      (winner-undo)
    (delete-other-windows)))

(global-set-key (kbd "C-x 1") #'toggle-delete-other-windows)

Just drop this into your config as-is – it’s self-contained. This is one of those tricks where once you have it, you can’t imagine going back.

Misc

Faster Mark Popping (Purcell, Centaur, Prot)

The mark ring is one of Emacs’s most underused navigation features. Every time you jump somewhere – isearch, M-<, M->, goto-line, imenu, and many more – Emacs pushes your old position onto the mark ring. C-u C-SPC pops it, jumping you back.

The annoyance: you need C-u C-SPC every single time. With this setting, after the first C-u C-SPC you can keep pressing just C-SPC to continue popping:

(setq set-mark-command-repeat-pop t)

This pairs beautifully with repeat-mode if you have it enabled (and you should – see my earlier post on repeat-mode).

Recenter After save-place Restores Position (Doom Emacs)

save-place-mode is great – it remembers where you were in each file and jumps back there when you reopen it. The problem is that it can leave your cursor on the last visible line of the window, which is disorienting. This advice recenters the view after the jump:

(advice-add 'save-place-find-file-hook :after
            (lambda (&rest _)
              (when buffer-file-name (ignore-errors (recenter)))))

Small thing, but it makes reopening files feel much more natural.

Auto-Select Help Windows (Prot)

When you press C-h f or C-h v, Emacs opens the help buffer but leaves your cursor in the original window. You almost always want to read the help right away, so you end up pressing C-x o every single time. This fixes it:

(setq help-window-select t)

Bonus: Many of the configs I surveyed also use built-in lazy isearch counting (showing “match N of M” in the minibuffer) instead of third-party packages like anzu. I recently wrote about that in a dedicated post.

The funny thing about all of this is how much overlap there is between configs. Half of these tricks appear in three or four of the configs I surveyed. At this point I’m convinced there are about 200 essential Emacs settings floating around in the collective unconscious, and every serious config independently converges on roughly the same subset. Picasso was right – we all steal from each other, and the kill ring makes it embarrassingly easy. M-w and move on.

That’s all I have for you today! Keep hacking!

Emacs Lisp doesn’t have a built-in way to define local functions (the way let defines local variables), so cl-lib provides several macros for this. If you’ve ever been confused by cl-flet, cl-labels, and cl-letf – you’re not alone. The naming doesn’t make the distinctions obvious, and the documentation is a bit dry. Let’s try to fix that.

A Bit of History

The original flet (from the old cl package) let you temporarily override a function’s definition. It worked by swapping out the function’s symbol-function cell and restoring it when the body finished – essentially a dynamic let for functions:

;; Old-style flet (deprecated since Emacs 24.3)
(flet ((some-function () "overridden result"))
  ;; Everything here, including called functions, sees the override
  (some-function))

This was very handy for testing (stubbing impure functions), but it conflated two different things into one macro:

1. Defining local helper functions (a lexical concept)
2. Temporarily overriding a global function (a dynamic concept)

When cl was reorganized into cl-lib in Emacs 24.3, flet was split into separate macros for each use case. This also brought the lexical variants in line with Common Lisp semantics, where flet and labels are lexically scoped.

The Three Replacements

cl-flet: Local Functions (No Recursion)

cl-flet binds function names lexically within its body. The key thing to understand is that the binding is only visible in the body forms – not inside the function’s own definition, and not to any functions you call:

(cl-flet ((double (n) (* n 2)))
  (double 21)) ; => 42

Because it’s lexical, cl-flet cannot override functions seen by other code:

(defun my-helper () (+ 1 2))
(defun my-caller () (my-helper))

(cl-flet ((my-helper () 999))
  (my-caller))  ; => 3, NOT 999!

my-caller still sees the original my-helper. This is the fundamental difference from the old flet.

There’s also cl-flet*, which is to cl-flet what let* is to let – each binding can reference the ones before it.

Use cl-flet when you just need a simple local helper and don’t need recursion. Think of it as let for functions.

cl-labels: Local Functions (With Recursion)

cl-labels is like cl-flet, but the function is visible inside its own body and inside the bodies of sibling bindings. This makes recursion and mutual recursion possible:

(cl-labels ((factorial (n)
              (if (<= n 1) 1
                (* n (factorial (- n 1))))))
  (factorial 10)) ; => 3628800

This would blow up with cl-flet because factorial wouldn’t be defined inside its own body.

Mutual recursion works too:

(cl-labels ((my-even-p (n) (if (= n 0) t (my-odd-p (- n 1))))
            (my-odd-p (n) (if (= n 0) nil (my-even-p (- n 1)))))
  (list (my-even-p 4) (my-odd-p 3))) ; => (t t)

Use cl-labels when your local functions need to call themselves or each other.

Note: cl-labels requires lexical-binding to be t in the file (which it really should be for any modern Emacs Lisp code).

cl-letf: Temporary Global Override

This is the one that actually replaces the old flet’s dynamic behavior. cl-letf temporarily rebinds a generalized place (anything setf can handle) and restores it on exit:

(defun my-helper () (+ 1 2))
(defun my-caller () (my-helper))

(cl-letf (((symbol-function 'my-helper) (lambda () 999)))
  (my-caller))  ; => 999

Now my-caller does see the override, because cl-letf modifies the actual symbol-function cell of my-helper – just like the old flet did. The original definition is restored when the body exits, even on error.

The syntax is a bit verbose because cl-letf isn’t specific to functions – it’s a general-purpose temporary binding macro for any setf-able place. (symbol-function 'name) is a “generalized variable” that refers to the function stored in a symbol’s function cell – it’s just one of many places cl-letf can bind. For example:

;; Temporarily silence messages
(cl-letf (((symbol-function 'message) #'ignore))
  (do-something-noisy))

Use cl-letf when you need the old dynamic flet behavior – typically for testing (stubbing functions) or temporarily suppressing/redirecting behavior.

Quick Reference

In other words:

• Default to cl-flet for local helpers. It’s the simplest and most predictable.
• Reach for cl-labels when you need recursion or mutual recursion in local functions.
• Use cl-letf only when you genuinely need dynamic override – mainly in tests. Modifying global function cells is a sharp tool and it’s not thread-safe, so keep it contained.

That’s all I have for you today. Keep hacking!

Writing Emacs regexps has always been a bit of a dark art. Between the double-escaped backslashes and the various group syntaxes (\(...\), \(?:...\), \(?N:...\)), it’s easy to lose track of what you’re actually matching. You type something into query-replace-regexp, press RET, and hope for the best.

Emacs 30 added minibuffer-regexp-mode, a minor mode that gives you live visual feedback as you compose a regexp in the minibuffer:

(minibuffer-regexp-mode 1)

When active, the mode highlights the structure of your regexp as you type it in the minibuffer. Capture groups, character classes, and other constructs get color-coded so you can see at a glance whether your grouping is right.

I find this particularly useful when building a regexp with multiple groups for query-replace-regexp, where you need to get the group numbering right for the replacement string (e.g., \1, \2). The visual feedback makes it obvious which group is which.

How Does This Compare to re-builder?

You might be wondering how this compares to re-builder (M-x re-builder). They’re complementary, really. re-builder shows matches in the buffer as you type a regexp in a dedicated editing window – great for developing complex patterns against actual text. minibuffer-regexp-mode, on the other hand, highlights the regexp itself in the minibuffer. It kicks in automatically whenever you’re prompted for a regexp (e.g., isearch-forward-regexp, query-replace-regexp, keep-lines, etc.).

One helps you see what your regexp matches; the other helps you see what your regexp says. I’d suggest using both.

That’s all I have for you today. Keep hacking!

Ever noticed how M-x shows you every command, including ones that make no sense in your current buffer? Org commands while editing Ruby, Magit commands in a shell buffer, that sort of thing. It’s not a huge deal if you know what you’re looking for, but it adds noise to the candidate list – especially if you’re using a completion framework like Vertico or Ivy that shows everything at a glance.

Emacs 28 added a simple way to fix this:

(setq read-extended-command-predicate
      #'command-completion-default-include-p)

With this setting, M-x hides commands that declare themselves inapplicable to the current major mode from the completion candidates. So if you’re in a Python buffer, you won’t see dired-do-rename or clojure-align cluttering your results.

How does the filtering actually work? command-completion-default-include-p looks at the modes a command declares it belongs to (via the interactive form) or checks its completion-predicate symbol property. If no modes are declared and there’s no completion predicate, the command is included as usual – so existing commands that haven’t been updated are not affected.

Emacs actually ships with three predicates you can choose from (plus nil for no filtering):

• command-completion-default-include-p – the safe default. Excludes commands tagged for other modes, includes everything else.
• command-completion-using-modes-and-keymaps-p – more aggressive. Shows commands tagged for the current mode plus any command that has a keybinding in the buffer’s active keymaps. Also always includes customize-* commands. Untagged commands without keybindings are hidden.
• command-completion-using-modes-p – the strictest option. Only shows commands explicitly tagged for the current mode. Untagged commands are hidden too, so this can be quite aggressive.

I’d recommend starting with command-completion-default-include-p since it’s the most conservative – it won’t hide anything that hasn’t explicitly opted in to the filtering.

Package authors can declare mode affiliation by adding a mode specification to the interactive form:

(defun my-foo-command ()
  "Do something useful in foo-mode."
  (interactive nil foo-mode)
  ...)

The nil is the interactive spec (no arguments in this case), and foo-mode tells Emacs this command is only relevant in foo-mode buffers. If a command applies to multiple modes, just list them all:

(defun cider-eval-defun-at-point ()
  "Evaluate the top-level form at point."
  (interactive nil clojure-mode clojure-ts-mode)
  ...)

This is handy for packages like CIDER that need to work in both the classic clojure-mode and the newer Tree-sitter-based clojure-ts-mode.

As for how well this works in practice – many built-in commands already declare their applicable modes, so you’ll see a noticeably cleaner M-x right away. Third-party package adoption is growing but uneven. Commands that haven’t been updated will simply continue to show up everywhere, same as before – so there’s no downside to enabling this.

A Note for Vertico/Orderless Users

If you followed the Vertico sample configuration, you’ll find this setting already there – commented out. It was shipped that way because it was new at the time and some users found the disappearing commands surprising. It’s been stable for years now and works great with Vertico, Orderless, and Marginalia. Just uncomment it and enjoy a less noisy M-x.

Commands that are filtered out aren’t gone – the filtering only affects completion candidates. If you type the full command name at the M-x prompt it will still execute just fine.

That’s all I have for you today. Keep hacking!

How many times have you typed C-x o C-x o C-x o to cycle through a few windows? Or C-x { C-x { C-x { to keep shrinking one? All that prefix repetition is pure friction.

repeat-mode is a built-in minor mode (Emacs 28+) that lets you drop the prefix after the first invocation and just keep pressing the final key. Enable it with one line:

(repeat-mode 1)

One important thing to understand – this doesn’t magically work for every key sequence. A command is only “repeatable” if it has been explicitly added to a repeat map. Emacs ships with repeat maps for a bunch of common built-in commands, though, so you get a decent experience out of the box. Here are some of the highlights:

• C-x o o o – keep cycling windows
• C-x { { { / C-x } } } – shrink/grow window horizontally
• C-x ^ ^ ^ – grow window vertically
• C-x u u u – keep undoing
• C-x <left> <left> / C-x <right> <right> – cycle through buffer history
• M-g n n n / M-g p p p – jump through next-error results

The transient state ends as soon as you press any key that isn’t part of the repeat map.

If you’d prefer it to time out automatically, there’s a setting for that:

(setq repeat-exit-timeout 5) ;; exit after 5 seconds of inactivity

Defining Your Own Repeat Maps

The real power comes from defining repeat maps for your own commands. For instance, if you use expreg for expand-region, you can set things up so that C-= = = = - expands three times then contracts once:

(defvar expreg-repeat-map
  (let ((map (make-sparse-keymap)))
    (define-key map "=" #'expreg-expand)
    (define-key map "-" #'expreg-contract)
    map))

(put 'expreg-expand 'repeat-map 'expreg-repeat-map)
(put 'expreg-contract 'repeat-map 'expreg-repeat-map)

The pattern is simple: create a keymap, then attach it to the relevant commands via the repeat-map symbol property. Any command with that property becomes “repeatable” after first invocation.

That’s all there is to it. One line to enable, and a lot less C-x mashing in your future.

Are you using repeat-mode? Have you defined any custom repeat maps that you find particularly useful? I’d love to hear about them in the comments!

Keep hacking!

The task has always been simultaneously easy and hard. Easy because deftheme and custom-theme-set-faces are well-documented and do exactly what you’d expect. Hard because the real challenge was never the mechanics – it’s knowing which faces to theme and keeping your color choices consistent across hundreds of them.

Note: In Emacs, a face is a named set of visual attributes – foreground color, background, bold, italic, underline, etc. – that controls how a piece of text looks. Themes work by setting faces to match a color palette. See also the Elisp manual’s section on custom themes for the full API.

The Classic Approach

The traditional way to create an Emacs theme is to write a deftheme form, then set faces one by one with custom-theme-set-faces:

(deftheme my-cool-theme "A cool theme.")

(custom-theme-set-faces
 'my-cool-theme
 ;; The `t` means "all display types" -- you can also specify different
 ;; colors for different displays (GUI vs 256-color terminal, etc.)
 '(default ((t (:foreground "#c0caf5" :background "#1a1b26"))))
 '(font-lock-keyword-face ((t (:foreground "#bb9af7"))))
 '(font-lock-string-face ((t (:foreground "#9ece6a"))))
 ;; ... 200+ more faces
 )

(provide-theme 'my-cool-theme)

This works fine and gives you total control. Many excellent themes are built exactly this way. In practice, a lot of new themes start their life as copies of existing themes – mostly to avoid the leg-work of discovering which faces to define. You grab a well-maintained theme, swap the colors, and you’re halfway there.

That said, the approach has a couple of pain points:

• You need to know what faces exist. Emacs has dozens of built-in faces, and every popular package adds its own. Miss a few and your theme looks polished in some buffers but broken in others. list-faces-display is your friend here, but it only shows faces that are currently loaded.
• Consistency is on you. With hundreds of face definitions, it’s easy to use slightly different shades for things that should look the same, or to pick a color that clashes with your palette. Nothing enforces coherence – you have to do that yourself.
• Maintaining multiple variants is tedious. Want a light and dark version? You’re duplicating most of the face definitions with different colors.¹

One more gotcha: some packages use variables instead of faces for their colors (e.g., hl-todo-keyword-faces, ansi-color-names-vector). You can set those with custom-theme-set-variables, but you have to know they exist first. It’s easy to think you’ve themed everything via faces and then discover a package that hard-codes colors in a defcustom.

How big of a problem the face tracking is depends on your scope. If you only care about built-in Emacs faces, it’s pretty manageable – that’s what most of the bundled themes do (check wombat, deeper-blue, or tango – they define faces almost exclusively for packages that ship with Emacs and don’t touch third-party packages at all). But if you want your theme to look good in magit, corfu, vertico, transient, and a dozen other popular packages, you’re signing up for ongoing maintenance. A new version of magit adds a face and suddenly your theme has gaps you didn’t know about.

I still do things this way for Tokyo Themes and Batppuccin, but the more themes I maintain the more I wonder if that’s overkill.

Every Multi-Variant Theme Is a Mini Framework

Here’s something worth pointing out: any theme that ships multiple variants is already a framework of sorts, whether it calls itself one or not. The moment you factor out the palette from the face definitions so that multiple variants can share the same code, you’ve built the core of a theming engine.

Take Tokyo Themes as an example. There are four variants (night, storm, moon, day), but the face definitions live in a single shared file (tokyo-themes.el). Each variant is a thin wrapper – just a deftheme, a palette alist, and a call to the shared tokyo--apply-theme function:

(require 'tokyo-themes)
(deftheme tokyo-night "A clean dark theme inspired by Tokyo city lights.")
(tokyo--apply-theme 'tokyo-night tokyo-night-colors-alist)
(provide-theme 'tokyo-night)

That’s the entire theme file. The palette is defined elsewhere, and the face logic is shared – which is exactly how you solve the variant duplication problem mentioned earlier. In theory, anyone could define a new palette alist and call tokyo--apply-theme to create a fifth variant. The infrastructure is already there – it’s just not explicitly marketed as a “framework.”

This is exactly how the theming features of packages like Solarized and Modus evolved. They started as regular themes, grew variants, factored out the shared code, and eventually exposed that machinery to users.

Meta-Themes

Some theme packages went a step further and turned their internal infrastructure into an explicit theming API.

Solarized

solarized-emacs started as a straight port of Ethan Schoonover’s Solarized palette, but over time it grew the ability to create entirely new themes from custom palettes. You can use solarized-create-theme-file-with-palette to generate a new theme by supplying just 10 colors (2 base + 8 accent) – it derives all the intermediate shades and maps them to the full set of faces:

(solarized-create-theme-file-with-palette 'dark 'my-solarized-dark
  '("#002b36" "#fdf6e3"                         ;; base colors
    "#b58900" "#cb4b16" "#dc322f" "#d33682"     ;; accents
    "#6c71c4" "#268bd2" "#2aa198" "#859900"))

This is how Solarized’s own variants (dark, light, gruvbox, zenburn, etc.) are built internally. I’ll admit, though, that I always found it a bit weird to ship themes like Gruvbox and Zenburn under the Solarized umbrella. If you install solarized-emacs and find a solarized-gruvbox-dark theme in the list, the natural reaction is “wait, what does Gruvbox have to do with Solarized?” The answer is “nothing, really – they just share the theming engine.” That makes perfect sense once you understand the architecture, but I think it’s confusing for newcomers. It was part of the reason I was never super excited about this direction for solarized-emacs.

Modus Themes

The modus-themes take a different approach. Rather than generating new theme files, they offer deep runtime customization through palette overrides:

(setq modus-themes-common-palette-overrides
      '((bg-main "#1a1b26")
        (fg-main "#c0caf5")
        (keyword magenta-warmer)))

You can override any named color in the palette without touching the theme source. The result feels like a different theme, but it’s still Modus under the hood with all its accessibility guarantees. The overrides apply to whichever Modus variant you load, and modus-themes-toggle switches between variants while keeping your overrides intact. Protesilaos’s ef-themes share the same architecture.

Theming Frameworks

If you want to create something brand new rather than customize an existing theme family, there are a couple of frameworks designed for this.

Autothemer

autothemer provides a macro that replaces the verbose custom-theme-set-faces boilerplate with a cleaner, palette-driven approach:

(autothemer-deftheme
 my-theme "A theme using autothemer."
 ;; Display classes: 24-bit GUI, 256-color terminal, 16-color terminal
 ((((class color) (min-colors 16777216)) ((class color) (min-colors 256)) t)
  (my-bg    "#1a1b26" "black"   "black")
  (my-fg    "#c0caf5" "white"   "white")
  (my-red   "#f7768e" "red"     "red")
  (my-green "#9ece6a" "green"   "green"))

 ;; Face specs -- just reference palette names, no display class noise
 ((default         (:foreground my-fg :background my-bg))
  (font-lock-keyword-face (:foreground my-red))
  (font-lock-string-face  (:foreground my-green))))

You define your palette once as named colors with fallback values for different display capabilities (GUI frames and terminals support different color depths, so themes need appropriate fallbacks for each). Then you reference those names in face specs without worrying about display classes again. Autothemer also provides some nice extras like SVG palette previews and helpers for discovering unthemed faces.

Base16 / Tinted Theming

base16-emacs is part of the larger Tinted Theming ecosystem. The idea is that you define a scheme as 16 colors in a YAML file, and a builder generates themes for Emacs (and every other editor/terminal) from a shared template. You don’t write Elisp at all – you write YAML and run a build step.

This is great if you want one palette to rule all your tools, but you give up fine-grained control over individual Emacs faces. The generated themes cover a good set of faces, but they might not handle every niche package you use.

From Scratch vs. Framework: Pros and Cons

When to Use What

I guess relatively few people end up creating theme packages, but here’s a bit of general advice for them.

If you want total control over every face and you’re willing to put in the maintenance work, roll your own. This makes sense for themes with a strong design vision where you want to make deliberate choices about every element. It’s more work, but nothing stands between you and the result you want.

If you mostly like an existing theme but want different colors, customizing a meta-theme (Modus, Solarized, ef-themes) is a good bet. You get battle-tested face coverage for free, and the palette override approach means you can tweak things without forking. Keep in mind, though, that the face coverage problem doesn’t disappear – you’re just shifting it to the meta-theme maintainers. How comprehensive and up-to-date things stay depends entirely on how diligent they are.

If you’re creating something new but don’t want to deal with the boilerplate, use a framework. Autothemer is the best fit if you want to stay in Elisp and have fine control. Base16/Tinted Theming is the pick if you want one palette definition across all your tools.

Parting Thoughts

I’m still a “classic” – I like rolling out my themes from scratch. There’s something satisfying about hand-picking the color for every face. But I won’t pretend it doesn’t get tedious, especially when you maintain several themes across multiple variants. Every time a package adds new faces, that’s more work for me.

If I were starting fresh today, I’d seriously consider Autothemer or building on top of a meta-theme (extracted from my existing theme packages). The time you save on maintenance is time you can spend on what actually matters – making your theme look good.

On the topic of maintenance – one area where AI tools can actually help is extracting the relevant faces from a list of packages you want to support. Instead of loading each package, running list-faces-display, and eyeballing what’s new, you can ask an LLM to scan the source and give you the face definitions. It’s also handy for periodically syncing your theme against the latest versions of those packages to catch newly added faces. Not glamorous work, but exactly the kind of tedium that AI is good at.

That’s all I have for you today. Keep hacking!

Following the OS Appearance (macOS + Emacs Plus)

If you’re using Emacs Plus on macOS (which many Mac users do), you get the hook ns-system-appearance-change-functions. This is not part of core Emacs – it’s a patch that Emacs Plus applies on top of the NS build. The hook fires whenever macOS switches between light and dark mode, passing the symbol light or dark as an argument. All you need is:

(defun my-apply-theme (appearance)
  "Load theme based on APPEARANCE (light or dark)."
  (mapc #'disable-theme custom-enabled-themes)
  (pcase appearance
    ('light (load-theme 'tokyo-day t))
    ('dark (load-theme 'tokyo-night t))))

(add-hook 'ns-system-appearance-change-functions #'my-apply-theme)

That’s it. When you flip the system appearance (or the OS does it automatically based on time of day), Emacs follows along. The mapc line disables any currently active themes first – without it, load-theme stacks the new theme on top of the old one, which can cause weird color bleed between the two.

This approach is nice because it keeps Emacs in sync with every other app on your system. If you’re on macOS with Emacs Plus, this is probably the simplest option.

Note: This only works with Emacs Plus’s patched NS build. If you’re using a vanilla Emacs build, or you’re on Linux/Windows, read on.

Following the OS Appearance (Cross-Platform)

If you want OS appearance tracking without writing the hook yourself, or you need it on a platform other than macOS, check out auto-dark. It detects OS-level dark/light mode changes on macOS, Linux (via D-Bus/GNOME), Windows, and even Android (Termux):

(use-package auto-dark
  :ensure t
  :config
  (setq auto-dark-themes '((batppuccin-mocha) (batppuccin-latte)))
  (auto-dark-mode))

The value is a list of two lists – dark theme(s) first, light theme(s) second. The extra nesting is there because you can stack multiple themes per mode (e.g., a base theme plus an overlay). For a single theme per mode, the format above is all you need. auto-dark polls the system appearance every few seconds and switches accordingly. It also provides auto-dark-dark-mode-hook and auto-dark-light-mode-hook if you want to run extra code on each switch.

Time-Based Switching with circadian.el

If you want theme switching based on time of day regardless of your OS, take a look at circadian.el. It can switch themes at fixed times or based on your local sunrise/sunset:

(use-package circadian
  :ensure t
  :config
  (setq circadian-themes '((:sunrise . batppuccin-latte)
                            (:sunset  . batppuccin-mocha)))
  (circadian-setup))

You can also use fixed hours if you prefer:

(setq circadian-themes '(("8:00"  . batppuccin-latte)
                          ("20:00" . batppuccin-mocha)))

For sunrise/sunset to work, set calendar-latitude and calendar-longitude in your config. circadian.el uses Emacs’s built-in solar calculations, so no external services are needed.¹

Rolling Your Own with run-at-time

If you don’t want an extra dependency, you can do something basic with run-at-time:

(defun my-set-theme-for-time ()
  "Switch theme based on current hour."
  (let ((hour (string-to-number (format-time-string "%H"))))
    (mapc #'disable-theme custom-enabled-themes)
    (if (<= 8 hour 19)
        (load-theme 'tokyo-day t)
      (load-theme 'tokyo-night t))))

;; Run now and repeat every hour
(run-at-time t 3600 #'my-set-theme-for-time)

It’s crude compared to circadian.el, but it works and you can tweak the schedule however you like.

Which One Should You Pick?

• macOS with Emacs Plus and want zero dependencies? The ns-system-appearance-change-functions hook is all you need.
• Want OS tracking on Linux/Windows too? auto-dark has you covered.
• Prefer time-based switching? circadian.el is the polished option; the DIY run-at-time approach works if you want to keep things minimal.

What about me? Well, I’m on macOS these days and I do enable the auto-switch between light/dark mode there. So, normally I’d pick the first option, but there’s a small catch - I really dislike light themes for programming and I’m using only dark variants day and night, so I don’t really need theme auto-switching in Emacs.

Note: One thing to keep in mind: if you’re using any of these, remove any static load-theme call from your init file – let the auto-switching mechanism handle theme loading, otherwise the two will fight on startup.

As usual, there’s no shortage of ways to solve this in Emacs. Are you doing auto-switching of themes yourself? Which is your favorite approach?

That’s all I have for you today. Keep hacking!

Paredit and smartparens are structural editing packages that keep your parentheses balanced and let you manipulate s-expressions as units – essential tools for anyone writing Lisp. Paredit has been around since 2005 and its keybindings have become muscle memory for a generation of Lisp programmers (yours truly included). Smartparens inherits the same keymap when used with sp-use-paredit-bindings.

The problem is that some of those keybindings conflict with standard Emacs key prefixes that didn’t exist when paredit was written – or that have grown more important over time.

The Commands and Their Conflicts

Before getting to solutions, let’s look at each problematic command – what it does, where paredit puts it, and what it shadows.

Splice – M-s

paredit-splice-sexp (or sp-splice-sexp in smartparens) removes the enclosing delimiters around point, “splicing” the contents into the parent expression:

;; before (point on "b"):
(a (b c) d)

;; after splice:
(a b c d)

The conflict: Emacs uses M-s as the search-map prefix (since Emacs 23). Paredit’s splice binding shadows M-s o (occur), M-s . (isearch-forward-symbol-at-point), and any M-s-prefixed bindings from packages like consult (consult-line, consult-ripgrep, etc.). If you use a completion framework like Vertico + Consult, this one really hurts.

Convolute – M-?

paredit-convolute-sexp (or sp-convolute-sexp) swaps the nesting of two enclosing forms. Specifically, it takes the head of the outer form and moves it inside the inner one:

;; before (point on "c"):
(a (b c d))

;; after convolute -- "a" moved from outer to inner:
(b (a c d))

The conflict: Emacs uses M-? for xref-find-references (since Emacs 25). If you use LSP (Eglot or lsp-mode), paredit’s convolute binding shadows “find all references” – one of the most useful LSP features.

Slurp – C-<right>

paredit-forward-slurp-sexp (or sp-forward-slurp-sexp) expands the current sexp forward by pulling the next sibling inside the closing delimiter:

;; before:
(a b) c

;; after slurp -- "c" pulled inside:
(a b c)

Barf – C-<left>

paredit-forward-barf-sexp (or sp-forward-barf-sexp) is the opposite – it pushes the last element out past the closing delimiter:

;; before:
(a b c)

;; after barf -- "c" pushed out:
(a b) c

The conflict for both: C-<right> and C-<left> override right-word and left-word. Fine if you’re in a Lisp buffer and know what you’re doing, but surprising if you expected word-level movement.

Splice-killing-backward – M-<up>

paredit-splice-sexp-killing-backward splices (removes delimiters) and also kills everything before point within the sexp:

;; before (point on "c"):
(a b c d)

;; after splice-killing-backward -- "a b" killed, parens removed:
c d

Splice-killing-forward – M-<down>

paredit-splice-sexp-killing-forward does the same but kills everything after point:

;; before (point on "b"):
(a b c d)

;; after splice-killing-forward -- "c d" killed, parens removed:
a b

The conflict for both: M-<up> and M-<down> clash with org-metaup/org-metadown in Org mode, paragraph movement in some configs, and window manager shortcuts on some Linux desktops.

What to Do About It

The good news is that both Matus Goljer (a.k.a. Fuco1, the smartparens author) and Magnar Sveen (a.k.a. Magnars, the author of expand-region, multiple-cursors and many other popular packages) have solved these conflicts in their own configs. Their approaches are worth borrowing.

The examples below use smartparens. For paredit, replace smartparens-mode-map with paredit-mode-map and sp-* commands with their paredit-* equivalents.

Splice (M-s)

Matus’s approach is to rebind to M-D (meta-shift-d). The mnemonic is nice – M-d kills a word, M-D “kills the delimiters.” This is probably the most widely copied alternative:

(define-key smartparens-mode-map (kbd "M-s") nil)
(define-key smartparens-mode-map (kbd "M-D") #'sp-splice-sexp)

Magnar’s approach is to rebind to s-s (super-s). Clean if you’re on macOS where Super is the Command key:

(define-key smartparens-mode-map (kbd "M-s") nil)
(define-key smartparens-mode-map (kbd "s-s") #'sp-splice-sexp)

You can use both – M-D everywhere, s-s as a macOS bonus.

Convolute (M-?)

Convolute-sexp is one of paredit’s more obscure commands. If you use LSP or xref regularly, freeing M-? for xref-find-references is a net win:

(define-key smartparens-mode-map (kbd "M-?") nil)

If you actually use convolute-sexp, rebind it to something under a less contested prefix.

Slurp/barf (C-<arrow>)

Magnar moves these to Super:

(define-key smartparens-mode-map (kbd "C-<right>") nil)
(define-key smartparens-mode-map (kbd "C-<left>") nil)
(define-key smartparens-mode-map (kbd "s-<right>") #'sp-forward-slurp-sexp)
(define-key smartparens-mode-map (kbd "s-<left>") #'sp-forward-barf-sexp)

Matus keeps the C-<arrow> bindings (accepting the conflict). This one’s really a matter of taste – if word-level movement with C-<arrow> matters to you, move them. If you’re a Lisp programmer who slurps more than they word-move, keep them.

Splice-killing (M-<up> / M-<down>)

Matus uses C-M-<backspace> and C-M-<delete>. Magnar uses s-<up> and s-<down>. Both work well.

The Smartparens Alternative

If you’re using smartparens (rather than paredit), there’s actually a simpler option – just use smartparens’ own default keybinding set instead of the paredit compatibility bindings. Set sp-base-key-bindings to 'sp (or just don’t set it at all) and call sp-use-smartparens-bindings instead of sp-use-paredit-bindings.

The default smartparens bindings already avoid most of the conflicts above:

The two big wins are splice moving to M-D (freeing search-map) and convolute not being bound at all (freeing xref-find-references). The slurp/barf conflict with word movement remains, but that’s a trade-off most Lisp programmers are happy to make.

What about me?

I don’t use most of the commands shadowed by Paredit, so I didn’t even think about the conflicts much before today. Given that I’m a macOS user these days I like Magnar’s approach to solving the conflicts. But I’m also sooo used to pressing M-s… Decisions, decisions…

I definitely think everyone should free up M-?, given the default is quite important command. For me this was never much of a problem in the past (until the LSP era) as I’ve always used Projectile’s wrappers around xref commands – projectile-find-references (s-p ? or C-c p ?) instead of xref-find-references, and projectile-find-tag (s-p j or C-c p j) instead of xref-find-definitions. Projectile scopes these to the current project automatically, which is what I usually want anyway.

I don’t really care about any commands with arrows in them, as I’m using an HHKB keyboard and it’s not really fun to press arrows on it…

The Bottom Line

Paredit’s defaults made perfect sense in 2005. Twenty years later, Emacs has grown search-map, xref, and a whole ecosystem of packages that expect those keys to be available. If you’ve been living with these conflicts out of habit, take five minutes to rebind – your future self will thank you.

That’s all I have for you today. Keep hacking!

Programmers know the benefits of everything and the tradeoffs of nothing.

– Rich Hickey

Earlier today I wrote about Emacs Redux turning 13. That felt like the perfect occasion to also ship something I’ve been working towards for a while – Emacs Prelude 2.0.

A Long Time Coming

The last tagged Prelude release (1.1) happened all the way back in February 2021. Five years without a release might sound alarming, but I’d argue it’s a feature, not a bug. Prelude has always aimed to be a foundation – simple, stable, easy to understand. I never wanted users to dread pulling upstream because everything moved under their feet. If you look at some of the more “sophisticated” Emacs distributions out there, the constant churn and complexity can be genuinely overwhelming. That’s not the experience I want for Prelude users.

That said, five years is a long time in Emacs land. Emacs 29 landed with built-in tree-sitter, Eglot, and use-package. A bunch of third-party packages that Prelude depended on became obsolete or unmaintained. It was time for a proper update.

What’s New

Prelude 2.0 is all about modernizing the distribution for the Emacs 29+ era.

Emacs 29.1 is now the minimum version

This was the big enabling change. Emacs 29 brought so many things that Prelude previously had to install or polyfill – use-package, display-line-numbers-mode, isearch-lazy-count, use-short-answers, tree-sitter, Eglot – that bumping the minimum version let me drop a ton of compatibility code and third-party dependencies in one go. Packages like nlinum, anzu, and epl are gone entirely, replaced by their built-in equivalents.

Tree-sitter support

Language modules now automatically use tree-sitter modes (e.g., python-ts-mode instead of python-mode) when a grammar is available, with graceful fallback to classic modes when it isn’t. This means better syntax highlighting and structural editing with zero configuration – just install the grammar and you’re done. Prelude currently supports tree-sitter remapping for C/C++, Go, Python, JavaScript, TypeScript (including TSX), Ruby, Elixir, Shell, YAML, and CSS. Some modules like prelude-ocaml (which uses neocaml) are tree-sitter-only by design.

Built-in LSP via Eglot

Most language modules now come with LSP support out of the box, using Eglot as the default client. No extra packages to install, no configuration to write – just make sure you have the right language server on your $PATH and Prelude handles the rest. Eglot keybindings live under the C-c C-l prefix (rename, code actions, format, organize imports), consistent with what lsp-mode users are used to. If you prefer lsp-mode, set prelude-lsp-client to 'lsp-mode in your personal config and Prelude will use it across all language modules instead.

Modernized language modules

Python, JavaScript, TypeScript, OCaml, Go, and others have been updated to use modern tooling. anaconda-mode is replaced by LSP, js2-mode by js-ts-mode, tide by typescript-ts-mode, tuareg by neocaml, alchemist and go-projectile are gone (both unmaintained for years). The goal was to bring every language module up to 2026 standards while keeping them short and focused – most are still under 50 lines.

Faster startup

I still stand by my older take that Emacs startup time doesn’t really matter – you start Emacs once and it runs for days (or weeks, or months). But when the fruit hangs this low, why not pick it? Interactive packages are now loaded lazily via use-package :defer, and redundant require calls have been eliminated throughout. The old defadvice calls have been replaced with modern define-advice / advice-add, and a fair amount of dead code has been cleaned up across the board. Nothing dramatic, but it all adds up to a noticeably snappier startup for those who care about such things.

There’s a detailed changelog if you want the full picture, and a migration guide in the README to help with the upgrade.

The Docs Got a Facelift

The documentation site has been updated and now uses the Material for MkDocs theme, which is a lot nicer to read and navigate than the old ReadTheDocs default. The content has been refreshed too, with all modules now properly documented.

What’s Next

There’s more I’d like to do. For instance, I haven’t yet pushed to convert everything to use use-package idiomatically – some modules still use the old with-eval-after-load / add-hook style. I’d also like to explore deeper integration with project.el and perhaps revisit the module system itself. But everything is in good shape overall, and I’d rather ship incremental improvements than hold back a release for perfection.

Starter Kits in the Age of AI

A fair question to ask in 2026 is whether Emacs distributions even matter anymore. With tools like Claude Code, you can just ask an AI to set up Emacs however you like – generate an init.el from scratch, configure LSP, pick a completion framework, wire up keybindings. Why bother with a starter kit?

I think there are a few reasons Prelude (and projects like it) still matter.

First, AI coding agents are only as good as the code they’ve been trained on. And right now, the Emacs ecosystem has a serious “popularity inertia” problem – agents will almost always suggest the older, more established package over a newer alternative, even when the newer one is clearly better. Ask an AI to set up OCaml in Emacs and you’ll get tuareg + merlin every time, not neocaml + ocaml-eglot. Ask for a completion framework and you’ll get ivy or helm, not vertico + marginalia. The training data reflects the past, not the present. Well-maintained distributions that track the state of the art serve as a corrective – both for humans browsing GitHub and for the models trained on it.

Second, there’s real value in curation. An AI can generate a config, but it can’t tell you which packages play well together, which ones are unmaintained, or which defaults will bite you six months from now. That kind of judgment comes from experience, and it’s exactly what a good starter kit encodes.

And third, simplicity still wins. A generated config you don’t understand is worse than a short, readable one you do. Prelude’s modules are deliberately small and straightforward – they’re meant to be read, forked, and modified. I’d rather give someone 20 lines of well-chosen defaults than a 200-line AI-generated config full of cargo-culted settings.

I wrote more about this topic in Emacs and Vim in the Age of AI if you’re curious.

Prelude and Emacs Redux

Emacs Prelude holds a special place in my heart. It was one of my first open-source projects – I started it back in 2011, two years before this blog even existed. When I launched Emacs Redux in 2013, many of my early posts were essentially showcasing features and ideas from Prelude. The two projects grew up together, and in many ways Prelude was the proving ground for the tips and workflows that ended up here. It’s fitting that they celebrate together today.

The Return of the Prelude

Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.

– Edsger W. Dijkstra

I’ve always believed that slow, deliberate change beats constant reinvention. It’s not glamorous, it doesn’t generate hype, but it builds something you can actually rely on. Prelude doesn’t try to be everything to everyone – it tries to be a solid, understandable starting point that respects your time and attention.

And here’s a fun bit of trivia to close on: 2026 happens to be the year Honda brings back the Prelude. Very few people know this, but I was actually considering buying a (pretty old) Honda Prelude around the time I created Emacs Prelude back in 2011 – that’s where the name came from! I never did buy the car, but the Emacs distribution turned out to be a much better investment.¹ And now, 15 years later, both Preludes are making a comeback. Sometimes things just come full circle.

That’s all I have for you today. Keep hacking!

13 is my lucky number, so I’m not going to worry about it.¹

– Taylor Swift

Exactly 13 years ago today I published the first Emacs Redux post and kicked off what has become one of the longest running projects in my life. Time flies!

Some Numbers

Over the past 13 years I’ve written 228 articles here. That’s not a lot by some standards, but I’m pretty happy with the consistency. There hasn’t been a single year without at least one post – although 2017 came dangerously close with just 2 articles (written on the 31st of December). Here’s the full breakdown:

2013 was the clear winner – I was on fire after launching the blog, writing almost 70 posts in a single year. I doubt I’ll ever match that pace again, but you never know.

The Octopress Dark Ages

One thing that almost killed my blogging was Octopress. When I started Emacs Redux it was the hot blogging platform for programmers, but over time it became a real pain to work with. At some point just getting the site to build locally felt like a chore, and that friction killed my motivation to write. I wrote about the migration back in 2018, and looking at it now I can’t help but smile at this bit:

I realized recently that it has been over 10 years since my first blog post. […] One thing never really changed, though - the quality of my writing. It was always abysmally bad…

I also noted there that 2018 marked the blog’s 5th birthday, and that I had failed to keep up the pace I originally set for myself. Some things don’t change! But the migration to a plain Jekyll setup with no extra layers on top made a real difference – that’s still what I’m using today, and it gets out of my way completely. The lesson? Keep your publishing toolchain as simple as possible.

The Editor Landscape

Lots of things have changed in the editor world over the past 13 years, but my love for Emacs remains as strong as ever.

Last year I had a lot of fun rediscovering Vim and wrote a whole series of “How to Vim” articles on batsov.com. I’ve also spent some time with Helix, Zed, and even VS Code (mostly for F# development). Playing with all of these only reinforced my conviction that Emacs is the One True Editor – or at the very least, the right (most fun) editor for me. There’s nothing quite like it!

Recent Activity

Some of you might have noticed that Emacs Redux has been more active than usual over the past few months. Two reasons for that:

• I’ve been having a lot of fun working on neocaml, and new projects always generate a steady stream of interesting findings worth sharing. I’ve made it a rule of mine to turn those into blog posts instead of letting them fade from memory.²
• I wanted to celebrate this birthday in style, so I promised myself to push a bit harder on the blogging front until today. No promises for the rest of the year, though!

Thank You

A big thank you to everyone who has been reading Emacs Redux over the past 13 years. And to all the people who have supported my Emacs open-source projects – whether by contributing code, filing issues, writing docs, donations, or just spreading the word – you have my gratitude. None of this would be as rewarding without you!

Looking Ahead

The best way to predict the future is to invent it.

– Alan Kay

We live in a world that’s changing fast, and the future is always uncertain even in the best of times. But I hope that Emacs (and Emacs Redux) will be alive, well and relevant for many years to come!

In Emacs we trust! Keep hacking!