Nicolas Cavigneaux has an excellent post on signing and optionally encrypting emails sent with mu4e. The idea is to sign each email you send and if you have a GPG key for every recipient, encrypt it was well. As Cavigneaux says, it’s pretty easy to sign and/or encrypt messages with mu4e but you have to remember to do it and most people, including him, don’t always remember.

The solution, of course, is to automate the process so that you don’t have to remember. That turns out to be pretty easy to do. Cavigneaux has the necessary code in his post. The basic flow is to check if you have everyone’s encryption key and, if so, encrypt the message. Regardless of whether or not everyone’s encryption key is available sign the message. There are calls available for both the signing and encryption. The process is kicked off with the send-message-hook every time you send a message.

There was a time when encrypting all your messages was the thing to do but difficulties with key distribution have pretty much put an end to the encrypt all emails movement. Most people don’t have keys and those who do will probably be annoyed to receive mundane emails that are encrypted. For those sensitive emails being sent to people you know have keys, you pretty much automatically remember to encrypt them.

That leaves signing. It mostly doesn’t hurt anything¹ so it probably doesn’t matter if you always sign your messages, especially if you have reasons to suspect that their contents might come into dispute. I’ve stopped doing even that because, as I say, no one has any idea what it means.

So my takeaway is that if you’re paranoid about certifying the content of your emails or you regularly deal with people who want to ensure themselves that they’re communication with you, it may make sense to automatically sign your emails. Except in special circumstances, I don’t see any reason to encrypt all your emails.

Hey hey hey, now I'm linkarzu-famous. =) Linkarzu (Christian Arzu) posted a reaction video to the first part of YE24: Sacha and Prot Talk Emacs - Newbies/Starter Kits. Here's his vid:

YouTube might be holding my comment for moderation because I tried to add too many links to it. I also realized my timestamps were off in my YT comment, so here it is along with other stuff I've just added.

(setq-default abbrev-mode 1)
(define-abbrev global-abbrev-table "ot" ""
  (lambda () (insert (format-time-string "[%Y-%m-%d %a %H:%M]"))))

You can e-mail me at sacha@sachachua.com.

I maintain a bunch of theme ports these days: Zenburn, Solarized, Tokyo Night, and most recently Batppuccin. Every one of them wants screenshots in the README, ideally one per variant, so people can compare the flavors at a glance.

I’d been putting this off forever, because taking the screenshots by hand is such a chore. Load a theme, resize the frame, arrange a nice-looking buffer, take a screenshot, crop it, then repeat for every single flavor. And the results are never quite consistent: the font is a little different, the window is a slightly different size, the crop is off by a few pixels. Multiply that by four flavors across several themes and you can see why I kept finding better things to do.

So recently I finally did what I should have done from the start and taught Emacs to take the screenshots for me. What started as a five-minute hack turned into a surprisingly deep little rabbit hole, so I figured it was worth a write-up.

The core idea is simple: spin up a throwaway emacs -Q, load the theme, show a sample buffer in a frame of a fixed size, and capture just that window. Because every step is scripted, the screenshots come out identical in layout, and regenerating the whole set after a color tweak is a single command.

A clean, disposable frame

The first half of the job is pure Emacs Lisp. I want a frame with no distractions (no tool bar, menu bar, or scroll bars), a nice font, a fixed size, and of course the theme loaded:

(setq inhibit-startup-screen t)
(menu-bar-mode -1)
(tool-bar-mode -1)
(scroll-bar-mode -1)
(setq-default cursor-type nil)          ; hide the cursor for a clean shot
(set-face-attribute 'default nil :family "Fira Code" :height 150)

(add-to-list 'custom-theme-load-path "/path/to/theme")
(load-theme 'batppuccin-mocha t)

(set-frame-size (selected-frame) 92 36)
(find-file "sample.el")

I load all of this into a throwaway Emacs:

emacs -Q --eval '(load "setup.el")'

A couple of things bit me here that are worth calling out:

• emacs -L some/dir puts a directory on the load-path, but load-theme searches custom-theme-load-path. Those are two different lists, so remember to add the theme’s directory to the latter.
• If your sample file lives in a project with a .dir-locals.el, opening it can pop up an “unsafe local variables” prompt that blocks the whole script. Setting enable-local-variables and enable-dir-local-variables to nil sidesteps that.

I use an Emacs Lisp file as the sample, by the way. It highlights nicely and, being the mother tongue, needs no third-party major mode, which keeps the whole setup dependency-free.

Now there’s a pretty Emacs frame on screen. The other half of the problem is turning it into a PNG.

Option 1: let Emacs export itself

The cleanest approach doesn’t involve a screenshot at all. If your Emacs is built with Cairo (as the GTK build on Linux typically is), it has a wonderful function called x-export-frames that renders a frame straight to an image:

(with-temp-file "shot.svg"
  (insert (x-export-frames nil 'svg)))

It can emit svg, pdf, postscript, or png. No external tools, no window-manager wrangling, no “don’t touch the mouse while it runs”. Emacs simply hands you the picture. If you’re on a Cairo build, stop reading and use this.

Alas, I’m on macOS, where Emacs uses the NS toolkit and x-export-frames isn’t available (you get a friendly void-function). So I had to go the screenshot route.

Option 2: screenshot the window

macOS ships with screencapture, which can grab a rectangular region of the screen. The trick is knowing exactly where the Emacs frame is. Conveniently, Emacs knows: frame-edges reports the outer pixel coordinates of the frame:

(let ((e (frame-edges nil 'outer-edges)))
  (with-temp-file "/tmp/geom"
    (insert (format "%d %d %d %d" (nth 0 e) (nth 1 e) (nth 2 e) (nth 3 e)))))

The shell side reads those coordinates and captures the rectangle:

read L T R B < /tmp/geom
screencapture -x -R "$L,$T,$((R - L)),$((B - T))" out.png

And that’s basically it. Except it isn’t.

The part nobody warns you about

Here’s the catch with region capture: screencapture -R grabs whatever happens to be on screen at those coordinates. If any other window is sitting on top of the Emacs frame, you’ll cheerfully capture that instead. And since I like to keep working while the script churns through a dozen flavors, this happened all the time. I’d end up with a screenshot of my terminal, my browser, or my other Emacs.

I ended up stacking a few tricks. First I float the frame above everything else with the z-group frame parameter, (set-frame-parameter nil 'z-group 'above). Then, since an Emacs launched from a background shell isn’t the active application and starts out buried behind the other windows, I pull it forward with (ns-hide-emacs 'activate).

Neither of those is bulletproof on its own, so the real safety net is checking the result. After each capture I sample a pixel from a corner that should be the theme’s background and compare it to the color Emacs reports for the default face. If they don’t match, I know I grabbed the wrong window, so I wait a moment and try again. That one check is what makes the whole thing safe to run while I keep working. Asking ImageMagick for a single pixel is enough:

magick out.png -crop '1x1+24+420' +repage -format '%[pixel:p{0,0}]' info:

Capturing a specific window by its ID would sidestep the stacking problem entirely, but on recent macOS enumerating window IDs requires Screen Recording permission for whatever process asks, and I couldn’t get that from a plain script. Floating the frame and verifying the result turned out to be simpler and more reliable.

A few finishing touches

A couple of smaller tweaks made the output look properly polished. GUI Emacs on macOS colors the native title bar according to the frame’s ns-appearance parameter, so I set it to light for light themes and dark for dark ones, and add ns-transparent-titlebar so the bar blends into the buffer background. It’s a tiny detail, but it makes the whole window feel like one piece. (It’s also the same trick that fixes an unreadable title bar under light themes, but that’s a story for another day.)

The other tweak was really a bugfix. Every so often a shot came out with a stray glyph or two at the top of the buffer, some redisplay artifact I never bothered to fully diagnose. Forcing a (redraw-display) right before I read out the frame geometry made it go away.

Other roads not taken

If you want to run this on a server or in CI, the story gets even better on Linux. You can start a virtual X display with Xvfb, run the Cairo Emacs build against it, and use x-export-frames: fully headless, perfectly reproducible, and with none of the “is the right window on top?” nonsense. That’s the setup I’d reach for if I ever wanted to generate these in a GitHub Action.

There are also plenty of other capture tools depending on your platform: ImageMagick’s import and the venerable scrot on X11, grim on Wayland, gnome-screenshot, and so on. Most of them can target a specific window, which is handy. One thing that won’t work is emacs --batch: batch mode has no GUI frame, so there’s nothing to photograph. You genuinely need a real, on-screen frame (or Cairo’s off-screen rendering).

Where this is headed

For now this lives as a small tools/ script inside my Batppuccin repo: a sample.el to display, an Emacs Lisp file to set up the frame, and a shell script to drive the capture and verification. It has already saved me a ton of tedium. Regenerating four flavors’ worth of screenshots is one command, and they come out identical every time.

But all of my theme ports have the same need, and the logic is almost entirely theme-agnostic. So I suspect I’ll eventually pull it out into a little standalone project: point it at a theme directory, hand it a sample file, and let it produce a consistent gallery for any theme. If that sounds useful to you as well, let me know. It might just nudge me into actually doing it.

Until then, I hope some of these ideas save you a bit of manual cropping. Automating the boring parts is what Emacs is all about.

I have found a peculiar delight in encryption, and particularly in using pgp-based asymmetric cryptography. This is especially useful for securing email communications, but doing so requires remembering to run M-x mml-secure-sign or mml-secure-encrypt in Mail Utilities For Emacs (Mu4e) before sending the message. For this reason I have been wanting to write a quick method that automatically adds signing capabilities and encryption only the recipient has a public key. Thankfully, I did not have to do so because of Nicolas Cavigneaux’s recent post Sign Always, Encrypt When Possible where he showcases his functins for doing exactly that. It prompted me to tweak it slightly, and to add the functionality to automatically discover public keys that I have yet to import.

Cavigneaux’s post sets up an elegant arrangement: email should always be signed with your pgp key, and you should “upgrade” from there to encryption only if your correspondent can handle encrypted mail and has shared their public key with you. This is done by using Emacs’ built-in Easy Privacy Guard (epg) tooling to compare the owners of the imported public keys on the machine with the list of recipients in an email.¹ If you have the public key for all recipients, the message will be automatically encrypted — otherwise it will merely be signed to prove that you are the author.

This was exactly what I had wanted, and I quickly incorporated this functionality into my own configuration. Testing it out, I felt a bit uneasy sending encrypted mail automatically. Because it is not the default, I felt that fully automated encryption made me unsure whether the mail has been encrypted or not — even when I know I have a public key. I thus made the slight modification of prompting for both encryption and signing:

(defun kudu/message-sign-encrypt-if-all-keys-available ()
    "Add MML tag to encrypt message when there is a key for each recipient,
sign it otherwise."
    (if (bounga/message-all-epg-keys-available-p)
        (if (y-or-n-p "Encrypt? ")
            (mml-secure-message-sign-encrypt)
          (when (y-or-n-p "Sign? ")
            (mml-secure-message-sign)))
      (when (y-or-n-p "Sign? ")
        (mml-secure-message-sign))))

In practice I will probably always be pressing Y when prompted, but this adds a level of certainty that the code is running correctly. It reminds me of an advertising gimmick for housewives in the 1950s: when cake mix first became available, it was not appreciated because it was perceived as being “too easy” — it did not feel like baking a cake yourself. And so the recipe was tweaked to simply require an extra egg to be added. In practice this was a trivial change, but it meant that you felt more responsible for the finished work.

But there is an additional step I want to automate that Cavigneaux alluded to, but did not implement. He writes:

[T]he policy is only as good as my keyring. Encryption depends on having imported the right public keys; nothing here fetches them for me.

I have recently been having more correspondence with people using the Swiss-based email provider Protonmail. Proton provides support for the Web Key Directory (wkd) method of providing keys, where the dns settings of a domain point to a file containing a public key for a specific user. This allows the email itself to “provide” its own public key for encryption. The public key of any @protonmail.com or @pm.me address can be quickly imported in a second using gpg --locate-external-keys email@pm.me. Proton will similarly use wkd to get your public key, and so you will receive encrypted mail as well. This is still easy to set up for any other email provider, as long as you can edit the domain settings.²

Sadly, epg does not come with any options for Gnupg’s --locate-keys or --locate-external-keys flags. This might be a good addition. In the meantime, we can write a quick and dirty function to do the job for us in the background when opening any new email:

(defun kudu/message-locate-keys ()
  "Tries to find the public keys of 'bounga/message-recipients' via WKD through --locate-keys."
  (dolist (recipient (string-to-list (bounga/message-recipients)))
    (let ((recipient-email (cadr recipient))
          (proc (make-process
                 :name "gpg-locate-keys"
                 :command (list epg-gpg-program "--no-tty" "--locate-keys" (cadr recipient))
                 :connection-type 'pipe
                 :filter (lambda (proc string)
                           (process-put proc 'output
                                        (concat (or (process-get proc 'output) "") string)))
                 :sentinel (lambda (proc event)
                             (when (eq (process-status proc) 'exit)
                               (let ((output (process-get proc 'output))
                                     (email (process-get proc 'email)))
                                 (if (and output (string-match-p "imported: [1-9]" output))
                                     (message "Public key imported for %s" email))))))))
      (process-put proc 'email recipient-email))))

We use --locate-keys because the stricter --locate-external-keys will check the domain even if a key already exists in the local keyring. --locate-keys will instead instantly find local keys and finish early, while only missing keys will be checked. This is done asynchronously through make-process so that it does not cause the ui to freeze as we wait for network requests to finish. gpg seems to check very quickly, so it is not a large performance hit regardless.

We want to have imported any new keys before sending our email because Cavigneaux’s functions are run on 'message-send-hook. We therefore run kudu/message-locate-keys much earlier:

(add-hook 'mu4e-view-rendered-hook 'kudu/message-locate-keys)

This adds any correspondents’ public keys on any opened email, and so does not have to go through your entire contacts list. A downside is that it does not check for a public key when you are the person sending an unsolicited email, but it will when you get their reply.

This is not the world’s most elegant function, and if someone more familiar with epg has any comments regarding ways to improve it I will happily edit this post for improvements. Just send me a (pgp encrypted!) email. Run echo 'am9hcnhwYWJsb0B2b25hcm5kdC5zZQ' | base64 --decode | xargs gpg --locate-external-keys to import my key. If you have wkd set up, I will automatically fetch your public key. If not, this is a great opportunity to fix that!

I will also note how wonderful Emacs and epg make working with encrypted files, messages, and/or text more generally. I must admit that I used a plain-text .authinfo for an embarrassingly long time to store some of my secrets, thinking it would be bothersome to use the encrypted .authinfo.gpg for auth-sources. If you are like me, do not worry — the peace of mind from being able to write down personal information and simply leave it scattered on your filesystem is well worth just having to type your password.

(defun bounga/message-recipients ()
  "Return a list of all recipients in the message, looking at TO, CC and BCC.
Each recipient is in the format of `mail-extract-address-components'."
  (mapcan (lambda (header)
            (let ((header-value (message-fetch-field header)))
              (and
               header-value
               (mail-extract-address-components header-value t))))
          '("To" "Cc" "Bcc")))

Jonas Bernoulli is announcing the release of Magit 4.6. It includes, he says, over 300 commits since the last release 6 months ago. You can check Bernoulli’s post for the details but an overview is that the main changes were in

• Blob handling. Working with blobs should be easier and make more sense with this release.
• Experimental syntax highlighting in diffs.
• Improved hook handling that allows for the calling of Elisp hooks from Git hooks.
• Improved commit message processing. List of changed definitions in a diff are now available for composing a git commit message.

As I’ve said before, Magit and Org Mode are responsible for luring many new users into the Emacs event horizon so these improvements are important. Moreover, they raise again the need for supporting this effort. Bernoulli spends full time on Magit on a few other open source projects and depends on contributors for his livelihood Take a look at his support page to see how you can help out.

Raw link: https://www.youtube.com/watch?v=UjCbNOqUgTs

In this video demonstration I show the tools I use to write in French using Emacs. One is the built-in framework for input methods, which allows us to compose characters to express the full range of the language we are typing in (e.g. French or Greek). The other is a spell-checking package called jinx, which is developed by Daniel Mendler.

Below is the code I showed in the video:

(use-package emacs
  :demand t
  :bind
  ( :map global-map
    ;; The `toggle-input-method' sets the latest selected input
    ;; method, or the one defined in `default-input-method'.  Once an
    ;; input method is set, `toggle-input-method' will switch back to
    ;; the standard Emacs input.
    ("<f2>" . toggle-input-method))
  :config
  ;; Call the command `describe-input-method' to get a description of
  ;; what the given input method supports in terms of key sequences as
  ;; well as the key layout it has.
  (setq default-input-method "french-postfix"))



;; You need to have libenchant available on your system. For example,
;; Debian provides the package `libenchant-2-dev'.
(use-package jinx
  :ensure t
  :demand t
  :bind
  ( :map global-map
    ("M-$" . jinx-correct) ; or bind `jinx-correct-all'
    ("C-M-$" . jinx-languages))
  :config
  ;; Here you can specify a string with space-separated dictionaries.
  ;; I install the aspell dictionaries, such as the Debian package
  ;; `aspell-fr' for French and `aspell-el' for Greek (Éllinika).
  ;; With `aspell' installed on the system, do `aspell dicts' on the
  ;; command-line to get a list of available dictionaries.
  (setq jinx-languages "en fr el es")

  ;; I want to have Jinx in programming modes but I do not want it to
  ;; check anything that is a comment or string, because then it
  ;; underlines too many things which are not useful. We can do the
  ;; same for other modes, though I think this is fine.
  (setq jinx-exclude-faces
        '((prog-mode font-lock-comment-face font-lock-string-face)))

  (global-jinx-mode 1))

What it is

emacs-mailto makes macOS mailto: links open in Emacs, using whatever mail-user-agent you already have configured: mu4e, notmuch, Gnus, Rmail, or plain message-mode. Click a mailto: link in your browser, and Emacs comes to the front with a compose buffer already addressed.

The project lives at sr.ht/~bounga/emacs-mailto, where you’ll find the source and the ticket tracker.

The problem it solves

The GNU Emacs NS port (as shipped by emacs-plus, emacs-mac, or the official build) does not handle mailto: URLs.

When Emacs is already running, clicking a mailto: link activates Emacs but the URL never arrives: macOS brings the app to the front and drops the URL Apple-event before it ever reaches Emacs Lisp. So nothing happens: no compose buffer, and no way to fix it from your config, because the event never gets there in the first place.

That’s the whole frustration emacs-mailto exists to remove.

How it works

emacs-mailto sidesteps the dropped Apple-event with a tiny relay app registered as your default mail application. On a mailto: click, it brings Emacs to the front and hands the URL to emacsclient:

open -a Emacs
emacsclient -n -e "(run-at-time 0 nil (lambda () (browse-url-mail \"<url>\")))"

browse-url-mail parses the mailto: URL (recipient, subject, body) and opens a compose buffer through your mail-user-agent. The run-at-time wrapper lets emacsclient return immediately instead of blocking on an interactive prompt, such as a From-address picker.

A few details make it painless in practice:

• emacsclient is located automatically at runtime (Homebrew on Apple Silicon or Intel, MacPorts, ~/.local/bin, or /usr/bin), so no path is hard-coded.
• The app is built and ad-hoc signed locally by the installer, so there is no Gatekeeper quarantine and no pre-built binary to trust.

Requirements

• macOS
• Emacs running with a server (M-x server-start, or the Doom/Spacemacs defaults), so emacsclient can reach it
• A configured mail-user-agent (this is what actually opens the compose buffer)

Installation

Clone the repository and run the installer:

git clone https://git.sr.ht/~bounga/emacs-mailto
cd emacs-mailto
./install.sh

This compiles Emacs Mailto.app into ~/Applications, registers it, and sets it as the default mailto: handler.

Test it:

open "mailto:test@example.com?subject=Hi"

Emacs should come to the front with a compose buffer addressed to test@example.com.

If your Emacs app has a different name, or you want a custom bundle identifier, override them with environment variables:

EMACS_APP="Emacs" BUNDLE_ID="org.nongnu.emacs-mailto" ./install.sh

A caveat about the default mail app

The relay runs as a background agent (LSUIElement), so it does not show up in Mail → Settings → General → “Default email application”. That menu may keep displaying another app; ignore it. To check the real handler, ask LaunchServices directly:

swift -e 'import AppKit; print(NSWorkspace.shared.urlForApplication(toOpen: URL(string:"mailto:x@y.z")!)!.path)'

It should print .../Emacs Mailto.app.

Uninstall

./uninstall.sh

This removes the app and resets the mailto: handler to Apple Mail.

Wrapping up

The whole thing is one small relay that removes a long-standing papercut of running Emacs as a mail client on macOS. It’s MIT licensed. If you hit a rough edge with your particular Emacs build or macOS version, the tracker is on the project page at sr.ht/~bounga/emacs-mailto.

What it is

shpaste is a small Emacs client for paste.sr.ht, the pastebin service from SourceHut. It lets me share a snippet without leaving the editor: select some text, run a command, and the paste URL is already in my kill-ring, ready to paste into a chat or an email.

It is built on the SourceHut GraphQL API and does just enough to be useful: create pastes, list them, open them, delete them. Nothing more.

The project lives at sr.ht/~bounga/shpaste, where you’ll find the source, the ticket tracker, and the mailing lists.

What it does

• Create a paste from the region or from the whole buffer. The resulting URL is pushed to the kill-ring and shown in the echo area.
• Browse your pastes in a dedicated list buffer, sorted and tabulated.
• From that buffer: open a paste, copy its URL, delete it, or refresh the list.
• Choose a visibility per paste: public, unlisted, or private.
• Point it at a self-hosted SourceHut instance if you don’t use the public one.

The list buffer looks like this:

Requirements

• Emacs 29.1 or later
• plz (GNU ELPA) and curl

Installation

shpaste is not on MELPA yet; the package is only a few weeks old. MELPA Stable support will come later, built from the version tags. In the meantime, install it straight from the repository.

On vanilla Emacs 29.1+, package-vc-install clones and builds it from source:

(package-vc-install "https://git.sr.ht/~bounga/shpaste")

On Emacs 30+, you can let use-package do the same with :vc:

(use-package shpaste
  :vc (:url "https://git.sr.ht/~bounga/shpaste" :rev :newest))

In Doom Emacs, declare the recipe in packages.el:

(package! shpaste
  :recipe (:type git
           :host nil
           :repo "https://git.sr.ht/~bounga/shpaste"
           :files ("*.el")))

Then configure it in config.el. This is the setup I use, with a paste leader menu and the list-buffer bindings:

(use-package! shpaste
  :commands (shpaste-list
             shpaste-create-from-region
             shpaste-create-from-buffer)
  :init
  (setq shpaste-default-visibility 'unlisted)
  (map! :leader
        (:prefix ("P" . "paste")
         :desc "List my pastes"      "l" #'shpaste-list
         :desc "Paste buffer"        "p" #'shpaste-create-from-buffer
         :desc "Paste region"        "r" #'shpaste-create-from-region))
  :config
  (map! :map shpaste-list-mode-map
        :n "RET" #'shpaste-list-open
        :n "w"   #'shpaste-list-copy-url
        :n "d"   #'shpaste-list-delete
        :n "gr"  #'shpaste-list-refresh))

Getting a token

shpaste authenticates with a SourceHut OAuth2 personal access token. Generate one at meta.sr.ht/oauth2 with the PASTES grant in read-write mode, then store it in auth-source with the host set to your instance — for example in ~/.authinfo.gpg:

machine paste.sr.ht password <YOUR_TOKEN>

There is no shpaste-token variable: the token is only ever read from auth-source. If you want the details of how that lookup works and why I chose it, I wrote a whole post about it: Using auth-source in a Real Emacs Package.

Usage

Inside the shpaste-list buffer:

Configuration

Two options, both optional:

• shpaste-instance (default "paste.sr.ht") — set it to a self-hosted host. It is used both to build the API endpoint and as the auth-source lookup key, so the machine field above must match it.
• shpaste-default-visibility (default unlisted) — one of public, unlisted, or private.

Wrapping up

That’s the whole tool. shpaste is young (currently 0.1.0) and MIT licensed. If you live in Emacs and use SourceHut, give it a try — and if you hit a rough edge or have an idea, the project page is at sr.ht/~bounga/shpaste.

Introduction

GPG is only useful for the emails you actually remember to protect.

In mu4e, signing and encrypting a message is a manual gesture. Before sending, I hit C-c C-m s p to sign, or C-c C-m c p to sign and encrypt. It works, but it relies on me thinking about it every single time.

I don’t. Nobody does.

So in practice, the manual approach means most messages go out unsigned, and encryption only happens on the rare occasion I stop to remember it exists.

I wanted the opposite default. Something with no friction, that follows a clear policy:

• Sign every message I send. Always.
• Encrypt a message when, and only when, I have a public key for every recipient.

The second rule matters. Encryption is all-or-nothing: if a single recipient is missing from my keyring, encrypting would lock them out of their own email. So encryption has to be opportunistic — on when it can be, silently off when it can’t.

Here is how I wired that into mu4e.

The Building Blocks

Three pieces do the work.

MML secure tags. When you compose a message, Emacs doesn’t encrypt anything itself. It inserts an MML tag that tells the message layer what to do at send time. Two functions add those tags for me: mml-secure-message-sign and mml-secure-message-sign-encrypt.

message-send-hook. This hook runs right before a message is sent, when the headers are filled in and the recipients are known. That’s the perfect moment to decide whether to sign or to sign and encrypt.

epg. The Emacs interface to GnuPG. I use it to ask a simple question: do I have a public key for this address?

Two settings configure the signing context:

(setq mml-secure-openpgp-sign-with-sender t
      mml-secure-openpgp-encrypt-to-self t)

sign-with-sender tells the OpenPGP layer to pick the signing key based on the From address, which is exactly what I want when juggling several accounts.

encrypt-to-self is the one that saves you from a classic mistake. When you encrypt a message to someone else’s key, you can no longer read it — not even in your own Sent folder. Encrypting to yourself as well keeps your sent copies readable.

Collecting the Recipients

To decide whether encryption is possible, I first need the full list of people the message is going to.

(defun bounga/message-recipients ()
  "Return a list of all recipients in the message, looking at TO, CC and BCC.
Each recipient is in the format of `mail-extract-address-components'."
  (mapcan (lambda (header)
            (let ((header-value (message-fetch-field header)))
              (and
               header-value
               (mail-extract-address-components header-value t))))
          '("To" "Cc" "Bcc")))

The bounga/ prefix is my personal namespace. Emacs Lisp has a single global namespace, so prefixing your own functions is the convention that keeps them from colliding with built-ins or package code — never define a bare message-recipients that looks like it belongs to message.el. Pick whatever prefix you like; just be consistent.

I walk the To, Cc and Bcc headers, read each one with message-fetch-field, and parse it with mail-extract-address-components. The trailing t asks for all addresses in a header, not just the first, so a To line with five people returns five entries.

Bcc is in the list on purpose. A blind-carbon recipient still has to be able to read the message — if I can’t encrypt to them, I can’t encrypt at all.

mapcan concatenates the per-header results into a single flat list.

Do I Have Everyone’s Key?

Now the actual question: is there a public key in my keyring for every recipient?

(defun bounga/message-all-epg-keys-available-p ()
  "Return non-nil if the pgp keyring has a public key for each recipient."
  (require 'epa)
  (let ((context (epg-make-context epa-protocol)))
    (catch 'break
      (dolist (recipient (bounga/message-recipients))
        (let ((recipient-email (cadr recipient)))
          (when (and recipient-email (not (epg-list-keys context recipient-email)))
            (throw 'break nil))))
      t)))

I create an epg context, then loop over the recipients. For each one I ask epg-list-keys whether the keyring holds a key for that address. The email is the second element of each parsed recipient, hence cadr.

The logic is deliberately strict. The moment I find a single recipient with no key, I throw out of the loop and return nil: encryption is off the table. Only if the loop completes — every recipient covered — does the function return t.

The catch/throw pair is just an early exit. There is no point checking the remaining addresses once one is missing.

Tying It to Send

The decision function is tiny, because the two helpers did the hard part:

(defun bounga/message-sign-encrypt-if-all-keys-available ()
  "Add MML tag to encrypt message when there is a key for each recipient,
sign it otherwise.
Consider adding this function to `message-send-hook' to
systematically send signed / encrypted emails when possible."
  (if (bounga/message-all-epg-keys-available-p)
      (mml-secure-message-sign-encrypt)
    (mml-secure-message-sign)))

If I have everyone’s key, sign and encrypt. Otherwise, just sign. Either way, the message is signed — that part is never optional.

The last step is to run this before every send:

(add-hook 'message-send-hook 'bounga/message-sign-encrypt-if-all-keys-available)

message-send-hook fires once the message is complete and about to leave. By then the recipients are settled, so the keyring check reflects exactly who will receive the message.

The Result

With those few lines in place, I no longer have to remember GPG at all.

Every email I send is signed. Whenever I happen to have public keys for all the recipients (which, over time, covers more and more of my correspondence), the message is encrypted too, without a single keystroke on my part.

A couple of honest caveats.

Signing everything means every recipient can tell I use GPG, and gets a signature attachment whether they care about it or not. For me that’s a feature, not a cost.

And the policy is only as good as my keyring. Encryption depends on having imported the right public keys; nothing here fetches them for me. When a key is missing, the message silently falls back to signing only — which is the safe failure mode, but a silent one. If you’d rather be told, this is the spot to add a notice.

None of that changes the day-to-day feel, though: I write email, I send it, and the right cryptography happens on its own.

BTW, my public PGP key is available here: DB19B66E.

Projectile 3.0 is finally out, and it’s a big one - easily the biggest release in years. There’s a nice reason for that: this year Projectile turns 15.¹ It all started back in the summer of 2011, simply because I was frustrated that find-file-in-project didn’t work on Windows, and somehow that little anniversary made me want to shake things up and finally tackle a whole pile of changes I’d been putting off for ages. Some new features, some long-overdue spring cleaning, and a few things I’d wanted to remove for the better part of a decade.

What’s dead can’t die

There’s a running joke that Projectile is obsolete now that Emacs ships project.el out of the box. I’ve heard it many times, and I even wrote about it when Projectile turned 10 - it’s obviously hard to compete with a built-in package, as it has a home-field advantage you can never match.

But here’s the thing. If it’s really true that Projectile is dead and everyone has moved on to project.el, then that’s oddly liberating. What’s dead can’t die, right? If there are no users left to upset, I can finally go wild with my wildest ideas and stop worrying about breaking the workflows of Projectile’s (non-existent) users. And that’s more or less the spirit in which I approached 3.0 - I stopped being quite so precious about backwards compatibility and just did what I felt was right for the project.

(Turns out there might still be a user or two out there after all, so do skim the migration notes below. Sorry in advance!)

The highlights

There’s a lot in this release - well over a hundred entries in the changelog - but here are the highlights I’m most excited about:

• projectile-dispatch (bound to s-p m) is a new transient menu that mirrors the command map, so you no longer have to remember every keybinding. It also exposes command modifiers as switches, so you can toggle a regexp search, start a fresh shell, invalidate the cache, or open a result in another window/frame right from the menu.
• Projectile can now index a project asynchronously, in a background process, so a cold projectile-find-file no longer freezes Emacs while it walks a huge tree. The building blocks are public, so external tools can drive Projectile’s indexing asynchronously as well.
• There’s a new (optional) projectile-consult integration built on those async data sources. Its finder streams candidates into the minibuffer as the project gets indexed, instead of blocking until indexing is done, while still honouring your VCS and indexing configuration.
• The various search commands got folded into a single projectile-search, backed by a small, extensible backend registry. It ships grep, ripgrep and ag backends out of the box, and you can register your own (deadgrep, consult-ripgrep, whatever you fancy) in a few lines.
• The shell, REPL and terminal commands got the same treatment - one projectile-run with shell, eshell, ielm, term, vterm, eat and ghostel backends, plus a seam to plug in your own.
• The indexers got a thorough going-over - batched stat calls, single directory listings instead of dozens of file-exists-p probes, smarter caching. It all adds up, and it really shows over TRAMP, where every needless round-trip used to hurt. I think that 15 years later I’ve finally solved Projectile’s infamous performance issues over TRAMP!²
• I finally removed a pile of features that had outlived their usefulness - the single-key Commander (superseded by the dispatch menu), the idle timer, projectile-browse-dirty-projects, and all of the built-in tags support (xref and LSP do this far better nowadays).
• The minimum supported Emacs is now 28.1. That let me drop a heap of compatibility shims and finally make transient a proper dependency instead of an optional extra.
• Projectile is a better project.el citizen now - it implements more of the protocol (project name, buffers, ignores), so tools built on top of project.el behave correctly in Projectile-managed projects.
• I also dropped the legacy ido/ivy/helm completion systems - these days everything rides on the standard completing-read, so Vertico, Consult and friends just work. ido fans are the one group that has to lift a finger: install ido-completing-read+ (the package formerly known as ido-ubiquitous) and turn on ido-ubiquitous-mode, and ido will drive Projectile’s prompts just like before.
• And there’s a pile of smaller quality-of-life additions - subproject compile/test for multi-module projects (c m c / c m t), a %p placeholder for the project name in command strings, projectile-add-and-switch-project, jumping back to the most recent project, and more.

Upgrading

3.0 is a major release for a reason - there are breaking changes. The minimum Emacs version is now 28.1, several long-deprecated commands and options are gone, and a couple of keybindings moved around. I’ve written a dedicated Migrating to Projectile 3.0 guide that walks through everything and how to adapt your config. Most setups will keep working untouched, but please give it a read before you upgrade.

Fifteen years later

As I said back when Projectile turned 10 - it’s always hard to compete with built-in packages. Still, I’m genuinely proud that 15 years in, Projectile is still here and, hopefully, still relevant to at least some of you. It remains one of my favourite projects and the one I reach for every single day.

Huge thanks to everyone who has contributed code, reported bugs, written extensions, or simply used Projectile over the years - none of this would exist without you. I really hope 3.0 isn’t the end of the innovation for Projectile, and that it’ll keep surprising and delighting its users for years to come.

Keep hacking!

Over at Emacs Dwelling there’s a nice post on why you should set Emacs to delete files by moving them to trash. That’s easy to do by setting delete-by-moving-to-trash to t. The post has a story illustrating why you should do that: it’s very easy to accidentally delete a file with Dired and if you do it to a file with changes that haven’t been committed to version control you can lose a few hours work. If you don’t use version control, the story is even worse.

The post seemed to me to be a worthy cautionary tale and I thought it would make a good Irreal post but when I began the writing process by entering a file name for the post, delete-to-trash.org, I discovered that such a file already existed from 2022. Even worse, for my blogging plans, it said everything I was planning to say in this post. Nevertheless, that was 4 years ago and the lesson, it seems, is evergreen so it’s worth making the point again. It costs you nothing and in those rare occasions where errant muscle memory causes you to delete a file, it can save the day. So rather than repeat the story I’ll just suggest that you check out the Emacs Dwelling post or my previous effort.

I have a soft spot for Sayid - it’s one of the most ingenious Clojure tools ever built, and also one of the most neglected. It’s an omniscient debugger: instead of stopping your program at a breakpoint, it quietly records every call to the functions you’ve traced and lets you rummage through the recording afterwards. It’s the kind of thing you demo to people and watch their jaw drop. And it had been sitting practically unmaintained for the better part of a decade.

Here’s the awkward part: that neglect is largely on me. Bill Piel, Sayid’s original author, handed me the keys ages ago, and I’ve been… let’s say a less than exemplary steward. I’d merge the occasional patch to keep the lights on, but until very recently I’d done precious little to actually move the project forward.

The best time to maintain your open-source project was six years ago. The second best time is now.

– Ancient proverb, lightly adapted

So what finally lit a fire under me? Blame CIDER 2.0. I’ve been reworking CIDER’s debugging and tracing story, and at some point I sat down to make the built-in tracer smarter. A few hours in it hit me: nothing I could realistically bolt onto the built-in tracing would come anywhere close to what Sayid already does. So instead of building a worse Sayid, I dusted off the real one, gave it a good scrub, and here we are - Sayid 0.4.

What is Sayid, anyway?

For the uninitiated: Sayid records the arguments, return value, timing and full call tree of the functions you trace, so you can go back and inspect exactly what happened - no breakpoints, no println, no re-running the thing five times.

While we’re on the subject of embarrassing confessions: I’ve been the maintainer of this thing for years and I still have no idea what “Sayid” actually means or what it’s a reference to. If you happen to know, please, put me out of my misery - I’d love to finally get the joke.

Trace a namespace, run your code, and pop open the workspace with C-c s w:

▾ (demo.coins/can-afford? [:quarter :dime :nickel :penny] 45) => true
    (demo.coins/total-cents [:quarter :dime :nickel :penny]) => 45

can-afford? says true, but four coins worth 41 cents shouldn’t cover a 45-cent tab. Something’s off, and the bug lives inside total-cents. This is where Sayid really shines - flip on an inner trace and it records every expression inside the function:

▾ (demo.coins/can-afford? [:quarter :dime :nickel :penny] 45) => true
  ▾ (demo.coins/total-cents [:quarter :dime :nickel :penny]) => 45
    ▾ (apply + (map coin-values coins)) => 45
        (map coin-values coins) => (25 10 5 5)

There it is, staring right at us: (25 10 5 5), when the last value should be 1. A penny is worth five cents in our coin map. We never wrote a single println, and we never had to guess where to put a breakpoint - we just looked at what actually happened.

That’s the pitch, and it’s a great one. So why was such a cool tool gathering dust?

Why an omniscient debugger, in 2026?

Honestly, part of it is that Clojure folks are spoiled. We have the REPL, so the reflex for most of us is to just re-run a form with some tap> or println sprinkled in and eyeball the output. That works right up until it doesn’t - until the bug is three layers deep in a map over a lazy seq, or only shows up on the 400th call, or lives in code you didn’t write and don’t feel like instrumenting by hand.

A traditional stepping debugger stops the world and makes you drive. Sayid does the opposite: it lets the program run to completion and then hands you the entire execution history as something you can navigate at your own pace. tools.trace is in the same spirit, but it dumps text to stdout - Sayid keeps structured data and gives you a query DSL to slice it. That’s a much better fit for how we actually work in Clojure: run it, capture everything, explore the data.

And here’s the thing that made me want to revive it rather than reinvent it - “capture everything as data and explore it later” is exactly the workflow that’s becoming more relevant, not less. Structured execution traces are gold, whether the thing doing the exploring is you, a data-inspection tool like Portal, or an AI assistant trying to understand why your code misbehaved.

Out with the old coordinates

First order of business was dragging the project into the present.

Sayid used to live under com.billpiel/sayid on Clojars, with namespaces like com.billpiel.sayid.core. The new home is clojure-emacs, so the artifact is now published as mx.cider/sayid:

{:user {:plugins [[mx.cider/sayid "0.4.0"]]}}

I also dropped the personal-domain prefix from every namespace - it’s plain sayid.core, sayid.trace, sayid.nrepl-middleware and so on now. The old com.billpiel/sayid coordinates still get the same releases for the time being, so nobody’s dependency breaks overnight, but the future is mx.cider.

Data first, strings later

Here’s the change I’m most excited about. Sayid’s nREPL middleware used to hand the Emacs client a pre-rendered blob of text plus a pile of text properties for colouring. In other words, the server did all the rendering and the client was a dumb terminal. That single decision is a big part of why there was exactly one Sayid client.

So the middleware now speaks data. There’s a family of new ops - sayid-get-workspace-data, sayid-query-data and friends - that return the recorded call tree as honest, navigable data instead of a wall of text:

{"id"       "4793"
 "name"     "demo.coins/can-afford?"
 "args"     ["[:quarter :dime :nickel :penny]" "45"]
 "return"   "true"
 "file"     "demo/coins.clj"
 "line"     12
 "children" [...]}

The structural bits (ids, names, timings, source location, the tree shape) come across as real nested maps and lists you can walk by key. The captured values are pr-str‘d, since an arbitrary Clojure value can’t always round-trip over the wire - but that’s the only place strings sneak in, and it’s exactly where you’d expect them.

The upshot: any editor or tool that speaks nREPL can now fetch a workspace and render it however it likes, and a REPL one-liner or a Portal tap gets you the same data with zero Sayid-specific machinery. The whole thing is written up in doc/nrepl-api.md, so you don’t have to reverse-engineer the wire format from the Emacs client the way you would have before.

A UI that doesn’t feel like 2015

With the data ops in place, I rebuilt the Emacs UI on top of them. The workspace and the “what’s traced” views are now proper foldable trees, built on CIDER’s new cider-tree-view. You get real folding (TAB), navigation (n/p), jump-to-source (RET), and - my favourite - c i hands the actual captured value straight to CIDER’s inspector, so you can drill into an argument or a return value as a live, navigable object rather than squinting at its printed form.

There’s also a query layer wired into the tree: f narrows to every recorded call of the function at point, i focuses a single call and its subtree. On a big trace that’s the difference between “wall of text” and “actually finding the thing”.

The best part is that the client is now smaller, not bigger - all the tree rendering, folding and value inspection are handled by mature components instead of bespoke code painting text properties by hand. That’s the payoff of moving rendering to the client: the server ships data, and the client is free to be as fancy or as plain as it wants.

Wait, you broke everything?

Backwards compatibility is a promise you make to the users you have. Sayid had exactly one, and reader, I am that user.

– Me, rationalising

Yeah, I did. I went pretty wild with the breaking changes this time around - new artifact coordinates, new namespaces, a reworked nREPL API, a bumped minimum CIDER version. Normally I’d bend over backwards to keep old clients working, but here I made a deliberate call: as far as I can tell, the bundled Emacs client was the only client Sayid ever had. Dancing around imaginary third parties to preserve compatibility nobody was relying on would have just made the project harder to adopt and harder to maintain.

So I opted for sweeping changes that leave Sayid in a much better place to build on, rather than a museum of backwards-compatible cruft. If it turns out I was wrong and you were quietly depending on the old coordinates - I’m sorry, and do let me know, because that’s genuinely useful information.

Take it for a spin

That’s the gist of it. Sayid is alive again, it’s leaner, it speaks data, and it has a UI I’m not embarrassed to demo. What I’d love now is for more people to actually use it and tell me whether the new direction resonates.

So please - [mx.cider/sayid "0.4.0"], trace something gnarly, and pop open the tree. Then head over to the issue tracker and tell me what you think: what feels great, what feels rough, what’s missing. I have ideas for where to take it next (bounding the recording so you can safely trace a whole namespace under a test suite is high on the list), but I’d rather steer by what people actually want out of it.

Big thanks to Bill Piel for building such a wonderful tool in the first place - I’m merely standing on the shoulders of a giant here. And thanks in advance to everyone willing to kick the tyres on the revival!

That’s all from me for now. Keep hacking!

P.S. One more thing…

Well, that didn’t take long. Remember that “high on the list” bit a few paragraphs up - bounding the recording so you can safely trace a whole namespace under a test suite? Turns out I couldn’t leave it alone. A short burst of small improvements after this post went up, and it’s done: Sayid 0.5.

That was the thing that made Sayid feel like a toy - point it at a real workload and it would cheerfully eat your whole heap and fall over. The recording now has a set of tunable bounds instead: a cap on how many top-level calls it keeps, a depth limit, 1-in-N sampling for hot paths, a per-function cap, and a keep-only-the-last-N mode for when what you care about is whatever happened right before things went sideways. Fat and infinite values no longer hang the data ops either, and the traced-functions view got its enable/disable/remove actions back.

The upshot for you: you can finally point Sayid at real code under real load without babysitting it. Same ask as before - give it a spin and tell me how it feels.

Consult notes is a package that hooks into your note-taking system. It works particularly well with Denote, picking up your notes directory variable automatically.

My interest in having a note system comes down to whether it helps my writing. A writer needs different kinds of notes: reading notes, notes on craft, notes on etymology, and random ideas. You’ll notice I’ve built that into the config below.

I’ve touched on the topic of note-taking in Emacs a few times, in posts on “making everything a note” and on the “undergrad” style of note-taking. I’ve often argued that a full dedicated notes package was unnecessary when you could simply create files and link them together.

But this “consult notes” package made me want to give Denote another try and see how it feels. So far, I like it. I’m going to test drive this config for a few weeks and report back on how it’s going.

(use-package denote
  :ensure t
  :bind (("C-c n n" . denote)                ; new note
         ("C-c n f" . denote-open-or-create) ; find/create by title
         ("C-c n l" . denote-link)           ; insert a link to another note
         ("C-c n b" . denote-backlinks))     ; show what links here
  :custom
  ;; Names the destination for notes in the file system
  (denote-directory (expand-file-name "~/notes/"))
  ;; Default to Org type of files
  (denote-file-type 'org)
  ;; Keywords you reach for more often
  (denote-known-keywords '("craft" "etymology" "draft" "idea"))
  (denote-prompts '(title keywords))
  :config
  (denote-rename-buffer-mode 1))            ; show note title in the buffer name, nice

(use-package consult
  :ensure t
  :bind (("M-s l" . consult-line)            ; search within current draft
         ("M-s L" . consult-line-multi)      ; search across all open buffers
         ("M-s r" . consult-ripgrep)         ; search the whole writing directory
         ("M-s o" . consult-outline)         ; jump between org/markdown headings
         ("M-s b" . consult-buffer)
         ("M-s k" . consult-keep-lines)      ; isolate lines matching a pattern
         ("M-s f" . consult-flush-lines))    ; strip lines matching a pattern
  :custom
  ;; Small delay before previewing (keeps a big file from feeling jumpy)
  (consult-preview-key '(:debounce 0.2 any)))

(use-package consult-notes
  :ensure t
  :commands (consult-notes consult-notes-search-in-all-notes)
  :bind (("M-s n" . consult-notes)                       ; search notes by title
         ("M-s N" . consult-notes-search-in-all-notes))  ; full-text across notes
  :config
  ;; Reads denote-directory automatically (no second path to maintain)
  (consult-notes-denote-mode))

The post God mode notes with Denote and Consult Notes appeared first on Chris Maiorana.

Diary was my pick for this month's Emacs Carnival. But in fact it's part of a larger set of functions under the calendar group. Another set of functions allows you to create pocket date books, desk planners and wall calendars if you have access to a printer. The function names begin with cal-tex-cursor and cal-html-cursor, and they can be found in cal-tex.el and cal-html.el, respectively.

The "tex" and "html" in the function names describe the output formats, LaTeX and, well, HTML; "cursor" describes one way of defining their inputs (from the position of the cursor in the calendar buffer). They're further subdivided into layouts such as day, week, month and year. My favorite is cal-tex-cursor-week-iso.

Open the calendar (M-x calendar). Observe that the cursor is at today. Now invoke cal-html-cursor-month and accept the default at the prompt. The function will create a file named YYYY-MM.html. The variable cal-html-directory provides the cal-html functions with the path name. The HTML file is placed in a subdirectory named YYYY. In my case, cal-html-directory is set to "~/public_html." As I invoke it today, the subdirectory / filename is 2026/2026-06.html.

The calendar can pull information from your diary file(s), the holidays defined in holidays.el and in the holiday-other-holidays variable. If you have %%(diary-sunrise-sunset) and %%(diary-lunar-phases) you'll get the times of sunrise and sunset at your coordinates, and the dates and times of the four lunar phases, assuming that cal-tex-diary is non-nil. (I also have cal-tex-24 non-nil.)

I suggested cal-html-cursor-month because its output is easily viewed (rendered) with a web browser. But I prefer the weekly calendar produced by cal-tex-cursor-week-iso, which outputs in LaTeX.

I've invoked cal-tex-cursor-week-iso with the cursor on June 16. The output is shown in Figure 1 after rendering to PDF with pdflatex. (Note that the screenshot is closely cropped.) There's a lot included here.

First, note that our Third Tuesday of the Month Club meeting (used as an example in a previous post) is shown. This comes from a diary entry; unfortunately org file events are ignored. (The agenda for this week is shown in Figure 2; note the event in red does not appear in the weekly calendar. This is another reason I favor recording appointments in the diary.)

Two other diary entries also are included: a record of when the kitchen cabinets were painted, plus a breakfast meeting with Howard.

Then you'll find two holidays, Islamic New Year and Father's Day. And because I have diary-lunar-phases in my diary, a moon phase also shows up. (I commented out the diary-sunrise-sunset statement because it adds the information to every day of the week, which makes the weekly planner look too cluttered.) Last but not least the Summer Solstice is included as a Sunday holiday along with the time it occurs.

The first line of each day block also shows (right justified) the day number (of the year) and the number of days remaining in the year. The Sunday block is quite crowded; the first line is wrapped, so the day number / days remaining field appears on the next line.

Sadly, any links in the diary that worked in Org Agenda do not work in the LaTeX output. You'll see instead the full syntax of the link, [URL][description] ].

I created an improved version of cal-tex-cursor-week-iso. Here are some of the changes:

• inhibit sunrise/sunset data for all but the first day
• switch to sans-serif font
• color birthdays and anniversaries in blue
• replace the non-ASCII characters (used for Bahai holidays)
• offset left or right to allow for the binding of a year's worth of pages
• more?

I uploaded it to Codeberg, but I need to clean it up a bit before I feel comfortable promoting it.

If you position the cursor on the last day of the year and invoke cal-tex-cursor-week-iso with a prefix argument of 53, you can create the pages for a personalized weekly planner for next year! Try it out!

I was working on my diff-minimap package, deep in the weeds of fringe indicators and search highlights, and I did the thing. You know the thing. I was in Dired, accidentally, for some reason hit D to delete a filename (probably some malfunctioning muscle memory) and it was gone!

Except it was my own source file. diff-minimap.el. The one I had been hacking on for the last hour. The one with all those uncommitted changes.

Now, in my head, I have a trash setup. I am sure I configured that somewhere, probably years ago, in some init file on some machine. But the machine I was sitting at? Nope. Emacs just did a straight delete, no safety net, no way back.

The file was tracked in git, so I could git checkout HEAD -- diff-minimap.el to get the committed version back. But the uncommitted work - the inline diff preview, the vc-diff positioning, the side-window hunk viewer - that was gone.

Emacs has a built-in variable, delete-by-moving-to-trash. When it is set to t, Dired (and other delete operations) move files to the system trash instead of permanently deleting them. On Linux that is ~/.local/share/Trash/files/, on macOS it is ~/.Trash/, on Windows it is the Recycle Bin.

It is one of those settings that seems obvious in hindsight but is easy to overlook because Emacs defaults it to nil. The reasoning is probably that Emacs is a serious tool for serious people who know what they are doing, so deleting means deleting?!

So I added it to my config:

(setq delete-by-moving-to-trash t)

That is it. One line. From now on, D in Dired moves to trash instead of deleting permanently and I will not have that sinking feeling again!

Anyway, back to diff-minimap.

Normally I write these posts after a CIDER release is out, with the smug satisfaction of someone who has already tagged the version and updated the changelog. Today I’m flipping the script a little: the release isn’t out yet, but I’m too excited to keep quiet about it.

Here’s the thing. The next CIDER release was supposed to be 1.23. But as I kept piling change upon change, it slowly dawned on me that calling this “1.23” would be doing it a disservice. So I’m now strongly considering shipping it as CIDER 2.0 instead.

A different kind of release

The last few CIDER releases were on the conservative side - lots of important internal work, but relatively little that you’d actually notice day to day. This one is the exact opposite. It’s stuffed with user-visible changes, many of which have been sitting on the issue tracker and in the back of my mind for literally years.

Why now? Two reasons.

First, all that boring groundwork paid off. Some of you noticed I spent a lot of time recently backfilling tests and generally enriching the test suite. That wasn’t busywork - it was me building a safety net, so that finally making sweeping changes would be safe and pleasant instead of terrifying. Mission accomplished: I’ve been refactoring with abandon and sleeping just fine.

Second - and I know this is the controversial part - AI agents have been a genuinely great help. Not for writing CIDER for me (the design taste is still very much mine, thank you), but for quickly prototyping my half-formed ideas in different ways so I can see and feel them before committing to the approach I like best. Turns out “show me, don’t tell me” works wonders when the thing showing you can knock out a prototype in minutes. Boo me if you must, but when you’re the maintainer of so many projects and you have only so little time to spend on all of them that really makes a difference.

There’s a third ingredient worth mentioning: I’d been hammocking on most of this for months, quietly turning the designs over in the back of my mind while I was wrapping up CIDER 1.22. So while 1.22 itself took the better part of four months (and still shipped later than I’d have liked), the release right after it has been snapping together in a couple of weeks - the code was the easy part once the thinking was done. It helps that a lot of these changes close issues that had been gathering dust for years; the ClojureScript macroexpansion bug (#2099) was filed all the way back in 2017. Nothing beats hammock-driven development - even if it’s decidedly not the fastest way to ship anything.

OK, enough preamble. Let’s look at the goodies.

Keymaps you can actually discover

CIDER has a lot of commands, and historically the only way to find them was to memorize cryptic key chords or grep the manual. No more. Every command prefix now pops a transient menu (the same UI magit made famous), and there’s a top-level cider-menu that ties them all together:

Evaluate             Code              REPL & session           Diagnostics
 e Eval...            t Test...         j Insert into REPL...    r Trace...
 m Macroexpand...     n Namespace...    x Jack-in / connect...   p Profile...
 d Documentation...   w References...                            l Log...

Crucially, this isn’t a modal speed bump - your old muscle memory still fires instantly. C-c C-d C-d runs cider-doc as fast as ever; the menu only shows up if you pause after the prefix, wondering “wait, what else is in here?”

One tree view to rule them all

A bunch of CIDER’s browsers grew up independently and looked it. They now share a single, foldable tree-view widget - the namespace browser, the spec browser, and the new call-graph browsers all behave consistently (TAB to fold, n/p to move around). For example, exploring who calls a function:

who-calls clojure.core/reduce
  ▾ my.app.core/sum
      ▸ my.app.api/handler
  ▸ my.app.util/total

Expand a node and CIDER lazily fetches the next level. It’s a much nicer way to spelunk through a codebase than a flat list of strings.

Find usages, batteries included

Speaking of call graphs - CIDER now ships with genuinely capable cross-reference functionality out of the box. cider-who-calls/cider-who-is-called for the call graph, cider-who-implements for protocols and multimethods, plus xref-find-references (M-?) that searches your source and therefore finds usages even in code you haven’t loaded into the REPL yet.

The practical upshot: if you were reaching for clj-refactor.el or clojure-lsp mostly to find usages, you probably don’t need them anymore. (If you were using them for other things, carry on - we’re friends, not rivals.)

Much of the inspiration here came straight from swank-clojure and SLIME itself, which have offered this kind of cross-referencing for ages. Sometimes nothing beats revisiting the classics.

The debugging toolbox got a serious polish

This is the part I’m most happy about. Pretty much every “what is my code actually doing?” tool got some love.

The macro tooling is the headliner. The macroexpansion buffer finally grew a header line that shows the active expander and options, cycles namespace display and metadata in place, pulses the freshly-expanded form, and - at long last - says something useful when you point it at a special form or an unresolved symbol, instead of silently shrugging. Better still, there’s a brand new inline stepper (cider-macrostep, a Clojure spin on the venerable macrostep package) that expands macros right where they sit, one step at a time. Expandable sub-forms get underlined so you can hop between them with n/p, and every gensym is painted its own color, so you can finally follow where that g__1234 ends up. I did not expect macro debugging to be fun, and yet here we are.

Tracing got the same treatment. Traced calls no longer smear themselves all over your REPL output; they stream into a dedicated, foldable *cider-trace* buffer instead:

*cider-trace*
▾ (my.app/process {:id 7})
    ▸ (my.app/validate {:id 7})  => true
    ▸ (my.app/persist {:id 7})   => {:id 7, :saved? true}
  => {:id 7, :saved? true}

And because “wait, what did I even trace?” is a question I ask myself constantly, cider-list-traced and cider-untrace-all are now a keystroke away.

Enlighten (you remember it, right?) picked up some manners too. You can light up a single form with cider-enlighten-defun-at-point without flipping the global mode, and cider-enlighten-stop makes the whole thing vanish at once, instead of making you re-evaluate everything in penance. And for the tap> crowd, cider-tap opens a buffer that streams whatever you send to tap> and lets you crack any value open in the inspector with RET. It’s println debugging, minus the println guilt.

ClojureScript gets some love too

ClojureScript is always the trickier sibling, but it got meaningful improvements this round:

• You can now run ClojureScript tests with the regular test commands (including async cljs.test tests) instead of CIDER refusing to play along.
• Macroexpansion of user-defined cljs macros finally works (it used to silently echo the form back unexpanded - a bug that had been open since forever).
• And when you invoke a Clojure-only command under a cljs REPL, CIDER now tells you so clearly, rather than failing in some confusing way.

This was another area where AI tooling was quite helpful to me, as I’ve rarely used ClojureScript in the past, but I still managed to figure out how to finally solve those problems that have been pain points for CIDER’s users for as long as we’ve had ClojureScript support.

On a related note, I’ve also been chasing down a few small bugs in Piggieback (the middleware that powers most of the cljs REPLs CIDER talks to) - have a look at the recent releases if you’re curious. And I’ve been idly pondering some form of “native” shadow-cljs support down the road. That last one is very much TBD, so don’t hold me to it - but the ClojureScript story keeps inching forward.

A pile of quality-of-life touches

It wouldn’t be a CIDER release without a long tail of small comforts. A few that I keep bumping into and grinning at:

• Eldoc is asynchronous now, so dragging the cursor around no longer blocks Emacs on an nREPL round-trip. Buttery smooth.
• A new cider-mode lighter (with an optional fringe marker) flags when the current buffer’s namespace isn’t loaded into the REPL, or has gone stale because you edited an already-evaluated form. That retires a whole genre of “why isn’t my change taking effect?” head-scratching.
• cider-doc can pull ClojureDocs examples right into the doc buffer.
• Sending a form into your namespace’s (comment ...) block is a one-keystroke affair now (cider-send-to-comment), and cider-jump-to-comment teleports you back there.
• Stuck in .cljc land? You can pin where a buffer’s evaluations go - clj, cljs, or both - with cider-set-eval-destination and friends.
• The REPL banner is slimmer and far less shouty; the getting-started spiel now lives in a summonable reference card (C-c C-h).
• The cheatsheet finally learned about all the functions Clojure has grown since 1.11.

I’m probably still forgetting a dozen things - the changelog is genuinely enormous this time around.

Please go play with it!

Unfortunately no one can be told what CIDER 2.0 is – you have to experience it yourselves…

– Clorpheus

Here’s where you come in. All of this is already available in the snapshot release of CIDER on MELPA. I’d love for you to install it, kick the tires, and - especially - tell me how the various UX changes feel. Discoverable? Annoying? Joyful? I genuinely want to know before I carve any of it in stone.

If no serious problems surface, I plan to cut the real release fairly soon - think a week or two. So now’s the perfect time to influence it.

Epilogue

I keep hearing that the Clojure community isn’t innovating much these days. I hope CIDER 2.0 goes a small way towards convincing the doubters that we’re not quite done yet. The best is always yet to come - for both Clojure and Emacs.

Now let’s go forth and brew some (magic) CIDER together! Keep brewing!

This week, lots of people were talking about FSF's policy of not accepting LLM contributions to Emacs core (see the last two items in the AI category). Comments seem generally supportive of FSF's caution.

• Help wanted:
  • EmacsConf - 2026 - Call for Participation
  • Monadic Sheep: Canvas patch: we need testers! (lobste.rs, emacs-devel)
• Upcoming events (iCal file, Org):
  • EmacsATX: Emacs Social https://www.meetup.com/emacsatx/events/315091677/ Thu Jul 2 1600 America/Vancouver - 1800 America/Chicago - 1900 America/Toronto - 2300 Etc/GMT – Fri Jul 3 0100 Europe/Berlin - 0430 Asia/Kolkata - 0700 Asia/Singapore
  • M-x Research: TBA https://m-x-research.github.io/ Fri Jul 3 0800 America/Vancouver - 1000 America/Chicago - 1100 America/Toronto - 1500 Etc/GMT - 1700 Europe/Berlin - 2030 Asia/Kolkata - 2300 Asia/Singapore
  • Emacs.si (in person): Emacs.si meetup #7 2026 (v #živo) https://dogodki.kompot.si/events/88d59360-d89a-42cc-b567-ed39ac5186fb Mon Jul 6 1900 CET
  • OrgMeetup (virtual) https://orgmode.org/worg/orgmeetup.html Wed Jul 8 0900 America/Vancouver - 1100 America/Chicago - 1200 America/Toronto - 1600 Etc/GMT - 1800 Europe/Berlin - 2130 Asia/Kolkata – Thu Jul 9 0000 Asia/Singapore
  • Atelier Emacs Montpellier (in person) https://lebib.org/date/atelier-emacs Fri Jul 10 1800 Europe/Paris
• Emacs configuration:
  • New transitional MELPA channels: snapshots and releases (@minad@mastodon.world) - version numbers will be release.0.date.count, which will be compatible with other package archives
  • Raymond Zeitler: Emacs disabled Commands
  • From Doom Emacs to Vanilla/Custom Emacs — Saved by Claude Code (Reddit) - annotated config
  • Firemacs Update (Reddit)
• Emacs Lisp:
  • Emacs' lispy-mode: Convolute real-world example! - DEV Community (@vindarel@framapiaf.org)
  • Regular expressions that work “everywhere” (HN, lobste.rs)
  • Scheduling Future Tasks in Emacs (Reddit, Irreal)
  • commonmark-gfm.el: a pure Emacs Lisp CommonMark/GFM renderer (Reddit)
  • vui.el: declarative, React-style UIs in Emacs buffers (v1.2, now with inline forms and flex layout) (Reddit)
• Appearance:
  • an attempt to create a theme inspired by Nerv from Evangelion (Reddit)
  • Kusanagi: a Ghost in the Shell-inspired dark theme for Emacs (Reddit)
  • Emacs with Ghostty-like Liquid Glass Effect (Reddit)
  • svg-margin: Better Gutters for Emacs (Reddit)
  • Protesilaos: Emacs: new ‘doric-tiger’ and ‘doric-lion’ for the ‘doric-themes’
  • Protesilaos: Emacs: fontaine version 3.1.0
• Navigation:
  • Raymond Zeitler: Preventing Errant Navigation
  • Overriding Emacs' Broken Bookmark Position Code (Updated) (Shallow Thoughts) (@akkana@fosstodon.org)
  • Randy Ridenour: Toggle Ghostel (Irreal)
• Dired:
  • dired-clipboard.el: Copy and paste files in Dired with M-w / C-y (Reddit)
• Org Mode:
  • Raymond Zeitler: Link diary Event to Org Heading (Irreal)
  • Chai 2.0 — Emacs reading workflow, stripped down to what actually matters (Reddit)
  • Jakub Nowak: org-roam Orphans
  • I built a stats dashboard for org-roam (org-roam-stats) (Reddit)
  • Vulpea v2.4: unlinked mentions, schemas, and renaming - Boris Buliga (changelog, Reddit)
• Coding:
  • flymake-sqlite v0.3.0 (@gemmaro)
  • Bozhidar Batsov: Neocaml 0.9: A Better REPL, Dune/Opam Completion, and More Robustness
  • Ankit Gadiya: which-function-mode displays the current function in the mode line
• Web:
  • Browsel: a two way communication between the web browser and emacs (YouTube 10:28, (Reddit)
• Mail, news, and chat:
  • Jakub Nowak: New Package: Gomuks.el - Matrix client written in Go
• Multimedia:
  • as-sound-switch: blazingly fast audio i/o switcher for Emacs (Reddit) MacOS
  • luqtas/csound-score-emacs: my take on navigating the Csound score paradigm with Emacs · GitHub
• Fun:
  • the learning cliff and the View from the Top (Reddit)
• AI:
  • For scientists and learners: agent-shell renders equations as you chat (Reddit, YouTube)
  • emacs-opencode: native Emacs client for OpenCode (Reddit)
  • emacs-jail-mcp: MCP server with disposable Emacs sandbox (Reddit)
  • macher-agent updates (emacs native agent orchestration) (Reddit)
  • Meta Redux: copilot.el 0.7
  • Andros Fenollosa: How I built a GPU backend for Emacs (Reddit, HN)
  • Honesty gets Emacs patch rejected (Reddit, HN, lobste.rs)
• Community:
  • Emacs Blog Carnival July 2026 "Programming" | Plain DrOps (@SpaceCadet@chaos.social)
  • Emacs anniversary (@EFLS)
  • An example would be handy right about now - how to shave yaks with great efficiency . — Willem van den Ende (@mostalive)
  • Do all emacs veterans that started from doom eventually roll out their own vanilla config?
  • Hristos N. Triantafillou: Ten Years Of Emacs
  • Neovim user trying to learn Vanilla Emacs properly, what should I focus on first? (Reddit) - linkarzu
    • Ok, so Now we're Really Installing it (01:50:14)
    • Follow The Emacs Tutorial (Day 3) (01:25:38)
    • Emacs Tutorial part 2 (Day 4) (02:07:00)
    • 0012 | Learning Emacs with The Professor from University of Victoria (01:34:35)
      • Learning Emacs with The Professor from University of Victoria (12:50)
  • Doom Emacs: Why I Chose It Over Vim and Never Looked Back (27:03)
• Other:
  • Helixel - Another Helix Emulation Layer (Reddit)
• Emacs development:
  • Limit VC-Dir status process output processing
• New packages:
  • fzfa: Async fuzzy completion via `fzf-native' (MELPA)
  • git-overleaf: Clone, push, and pull full Overleaf projects with Git (MELPA)
  • lisp-ts-mode: lisp-mode with tree-sitter support (GNU ELPA)
  • musicbrainz-interactive: Interactive commands for MusicBrainz related things (MELPA)
  • youtube-music: YouTube Music client (MELPA)

Links from reddit.com/r/emacs, r/orgmode, r/spacemacs, Mastodon #emacs, Bluesky #emacs, Hacker News, lobste.rs, programming.dev, lemmy.world, lemmy.ml, planet.emacslife.com, YouTube, the Emacs NEWS file, Emacs Calendar, and emacs-devel. Thanks to Andrés Ramírez for emacs-devel links. Do you have an Emacs-related link or announcement? Please e-mail me at sacha@sachachua.com. Thank you!

You can e-mail me at sacha@sachachua.com.

It's possible to configure Emacs to prompt the user before calling a function, thereby "disabling" a function. The function isn't totally inaccessible -- Emacs will let you run it if you want it to. I chose to do this with scroll-left, scroll-right, scroll-up-command and scroll-down-command as explained in the previous post.

Most keypresses call self-insert-command, which is itself a function. So what would happen if self-insert-command were disabled?

It turns out to be not as debilitating as you'd think -- only the alpha-numeric and punctuation keys are affected. When a modifier is used with a key (M-x, for example), there is no interruption. Likewise, the TAB key is allowed to pass, which makes completion easier.

When Emacs inhibits self-insert-command, it prevents the keypress from having its intended effect. It will say that the command is disabled because many users find it confusing. Then you'll have the options of:

• (n) Not running the command
• (y) Run the command and don't ask again
• SPC Run the command just one time to try it
• (!) Enable the command and all other disabled commands

The n, y, SPC and ! keys are not inhibited at this point, so the user doesn't get trapped in a set of recursive prompts.

So to invoke org-agenda, I'd press M-x o. Then I'd press SPC to enable the self-insert-command for "o." Then I'd press r followed by SPC, and so on. My keypresses are M-x o r g - a g TAB ENTER.

Thus, adding (put 'self-insert-command 'disabled t) to a cube-mate's init file is a harmless prank, something to try on April Fool's Day.

Fontaine allows the user to define detailed font configurations and set them on demand. For example, one can have a regular-editing preset and another for presentation-mode (these are arbitrary, user-defined symbols): the former uses small fonts which are optimised for writing, while the latter applies typefaces that are pleasant to read at comfortable point sizes.

• Package name (GNU ELPA): fontaine
• Official manual: https://protesilaos.com/emacs/fontaine
• Change log: https://protesilaos.com/emacs/fontaine-changelog
• Git repositories:
  • GitHub: https://github.com/protesilaos/fontaine
  • GitLab: https://gitlab.com/protesilaos/fontaine
• Backronym: Fonts, Ornaments, and Neat Typography Are Irrelevant in Non-graphical Emacs.

Below are the release notes.

Version 3.1.0 on 2026-06-29

This is a small release that includes internal refinements as well as two user-facing changes:

1. The user option fontaine-presets accepts an optional :line-spacing entry, which corresponds to the line-spacing variable. As of Emacs version 31, line-spacing can be bound to a cons cell to set the space above and below. Fontaine now handles this as intended.

2. By default, changing the font size has the effect of resizing the frame. This is because of the original value of the variable frame-inhibit-implied-resize. Fontaine is now designed to always inhibit frame resizing, regardless of frame-inhibit-implied-resize.

The Canvas patch is almost done. Except that we need more testing, specifically for its MS Windows port. (Though testers on other operating systems like GNU/Linux and MacOS are also welcome.)

Since we don't have any computers running MS Windows, we are not sure if the code is actually correct.

Please follow the following instructions for testing it on MS Windows. You can discuss the results or ask us questions at MonadicSheep Emacs Fork's Issue tracker, #phi-mu-lambda on Libera IRC (open webchat in browser), or on the fediverse (tag the post with #emacs).

(defun make-rect (width height pixel)
  (make-vector (* width height) pixel))

(setq rect-canvas-vec (make-rect 250 250 #xFFFF0000))
(setq rect-canvas `(image :type canvas
                          :data-width 250
                          :data-height 250
                          :data ,rect-canvas-vec))
(insert (propertize "#" 'display rect-canvas))

(defvar rect-canvas-timer nil)
(let ((i 0))
  (setq rect-canvas-timer
        (run-with-timer
         0 0.016
         (lambda ()
           (if (< i (* 20 250))
               (progn
                 (aset rect-canvas-vec (+ (* 115 250) i) #xFF0000FF)
                 (canvas-refresh rect-canvas t)
                 (setq i (1+ i)))
             (cancel-timer rect-canvas-timer))))))

Ray Zeitler has a useful post that describes how to solve a niche problem involving Emacs diary and Org mode. The problem is you have an event scheduled in your diary and you want access to an Org heading for clocking and note taking.

It turns out that it’s pretty easy to arrange that. Take a look at Zeitler’s post to see the exact recipe.

I just added two new themes to my minimalist doric-themes package. doric-tiger is a light theme, while doric-lion is dark. Both use orange and yellow colours. Below are sample screenshots.

doric-tiger

doric-lion

Part of development

The new themes will be available in version 1.2.0. I think they already are well defined and may not need furter changes. Though I will continue to test—and possibly tweak—them over the course of the next two weeks or so.

Sources

The Doric themes use few colours and will appear monochromatic in many contexts. They are my most minimalist themes. Styles involve the careful use of typographic features and subtleties in colour gradients to establish a consistent rhythm.

If you want maximalist themes in terms of colour, check my ef-themes package. For something in-between, which I would consider the best “default theme” for a text editor, opt for my modus-themes.

• Package name (GNU ELPA): doric-themes
• Sample pictures: https://protesilaos.com/emacs/doric-themes-pictures
• Git repository: https://github.com/protesilaos/doric-themes
• Backronym: Doric Only Really Intensifies Conservatively … themes.

For the past few months I've been on and off working on a new package for Emacs, which is my first attempt at a proper major mode "application".

It is a wrapper/frontend for Gomuks, which is a Matrix client written in Go. Typically, Gomuks runs a web app client for Matrix, which connects to the Gomuks backend via a websocket. My wrapper, gomuks.el, connects to the websocket and acts as a full (well, rudimentary) Matrix client inside Emacs.

I often press C-<end> or C-<next> accidentally. It's annoying and disorientating because I lose my place in the document as well as my train of thought. I think of them (a bit dramatically) as "Deadly Navigation Keys." But I discovered two valuable Emacs features to make it easy to recover from them (or prevent them) as a result.

The first valuable feature is that C-<end> (which is bound to end-of-buffer) sets the mark at the cursor location prior to setting point to the end of the buffer. (I only just realized this after seeing the message "Mark set" in the minibuffer about fifty times.)

There's an almost-applicable saying, "What goes up, must come down," except in this case I'd say, "What gets pushed, may be popped." A simple invocation of C-h a pop.+mark revealed the pop-to-mark-command. And then, happily, M-x pop-to-mark-command returned me to exactly where I left off. It was the undo feature that Emacs had been missing -- a sort of undo-cursor-motion.

Recovering from beginning-of-buffer is just as easy. It, too, pushes mark.

There are, however, other Deadly Navigation Keys that do not push mark. In fact, they don't even change the position of the cursor. Instead, they scroll the buffer. I'm referring to scroll-left and scroll-right . These are disabled by default. However, I figured that only babies needed to shielded from such commands, so I enabled them.

Holy cow was that a mistake! On my laptop keyboard, the page down and right arrow keys are crammed very close together. I often press C-<right> to advance one word, but that's only 1 cm away from C-<next>, which is bound to scroll-left. And scroll-left alters the view of the buffer such that all the content I been work on shifts off screen. The first time it happened, I freaked, of course, and then I checked the status bar to see if the buffer had been modified. (It hadn't.) So I closed Emacs entirely and restarted it. Then I re-disabled scroll-left and scroll-right.

But then it occurred to me to disable end-of-buffer and beginning-of-buffer, too, because I rarely use those functions, and if I really need to call them, all I'd have to do is press the spacebar after each C-<end>. Disabling a command is a convenient way of seeking confirmation without making the user type "yes" (or "y").

What commands do you have disabled? And why?

Randy Ridenour is living proof that you don’t have to be a young nerd to master Emacs and Elisp. Ridenour, a professor of Philosophy, has shown repeatedly that it’s possible for a nontechnical person to become sufficiently proficient with Emacs and Elisp to bend the editor to his will and make it work as he needs it to.

Irreal has recounted some examples of Ridenour’s past use of Elisp to customize his work environment and now there’s a new one. Lately he decided to try ghostel for his terminal emulator. He was already using ghostty as his macOS terminal emulator so the change made sense.

The change worked out well and Ridenour was pleased with the result except for one thing. With his previous Emacs terminal emulator, eat, he was able to toggle the emulator on and off easily but it didn’t work with ghostel. Rather than look for another package to solve this, he decided to fix it himself.

The desired functionality was

1. If no instance of ghostel is running, start one in the current window.
2. If there is already a ghostel instance running in another window, switch to it.
3. If there is a ghostel instance running in the current window, bury it.

Ridenour implemented that functionality with two functions. The first gets the active buffer of any running instance of ghostel or returns nil if there is none. The second function implements the three steps above in a straightforward way. The code is in his post and easy to understand so take a look if you have a similar need.

This month’s Emacs Asia-Pacific (APAC) virtual meetup is scheduled for Saturday, June 27, 2026 with BigBlueButton and #emacs on Libera Chat IRC. The timing will be 1400 to 1500 IST.

The meetup might get extended by 30 minutes if there is any talk, this page will be updated accordingly.

If you would like to give a demo or talk (maximum 20 minutes) on GNU Emacs or any variant, please contact bhavin192 on Libera Chat with your talk details:

Good news, everyone – copilot.el 0.7 is out! And it’s a big one.

Ever since I took over the maintenance of copilot.el in the spring of 2025, I’ve had one north star: close the gap between Emacs and the editors that enjoy first-party Copilot support. VS Code and (Neo)vim got the rich, official experience – chat, agents, the whole shebang – while we Emacs folks were stuck with humble ghost-text completion. That never sat right with me. Emacs deserves better.

For a bit of perspective on the pace: in its first three years the project never shipped a single tagged release. 0.7 is the seventh I’ve cut since taking over. We’ve been busy.

For a long time that gap felt unbridgeable. We were essentially reverse-engineering an undocumented protocol and replicating it in Elisp, always one step behind. But then Microsoft open-sourced @github/copilot-language-server, and everything changed. Suddenly we had a documented, first-party LSP server to talk to – the very same backend that powers Copilot in VS Code. The migration to it in 0.4 was the turning point. From that moment on, catching up to the other editors stopped being a fantasy and became a (long) TODO list.

We’ve been chipping away at that list ever since. A few months ago, in 0.5, we added basic support for Copilot Chat – the first time the package did anything beyond completion. 0.6 brought Next Edit Suggestions (NES) and the experimental beginnings of agent mode. And now 0.7 fills in pretty much all of the remaining blanks.

So what’s actually in it? Quite a lot. Let me walk you through the highlights.

Agent Mode, For Real

Chat is nice, but talking to an assistant that can’t do anything gets old fast. Enter agent mode:

(setopt copilot-chat-use-agent-mode t)

With this on, Copilot can run tools to actually get work done – run shell commands, create and edit files, read your diagnostics, fetch web pages. Ask it to “add a test for foo and run it” and it’ll write the test, invoke your test runner, read the output, and iterate, all without you leaving the chat buffer.

Of course, letting an AI run commands and rewrite your files unsupervised is a recipe for excitement of the wrong kind, so every tool call asks for confirmation first. File edits show you a diff preview before you approve them, and if you trust a particular tool you can pick always to stop being asked for the rest of the conversation. Long-running terminal commands now run asynchronously too, so Emacs stays responsive while that test suite chugs along – and C-g aborts a command that’s overstaying its welcome.

Workspace Awareness

An agent that can only see the current buffer isn’t much of an agent. So 0.7 teaches copilot.el to answer the server’s workspace requests: Copilot can now search your project by file glob or by text/regex (via ripgrep, so your .gitignore is respected), read files, and list directories across the whole tree. That’s what makes “where is X handled in this codebase?” actually work.

For the truly ambitious there’s also opt-in semantic search:

(setopt copilot-chat-enable-semantic-search t)

Flip that on and the server builds an embeddings index of your workspace, so you can ask whole-codebase questions instead of pointing at specific files. It’s off by default, since indexing isn’t free, but it’s there when you want it.

MCP Support

Model Context Protocol is how you give an assistant extra superpowers, and copilot.el now speaks it. Point copilot-mcp-servers at the servers you want and their tools show up in chat, right alongside the built-in ones:

(setopt copilot-mcp-servers
        '(:fetch (:command "uvx" :args ["mcp-server-fetch"])
          :memory (:command "npx"
                   :args ["-y" "@modelcontextprotocol/server-memory"])))

M-x copilot-chat-list-mcp-tools shows you which servers connected and what they offer (and complains loudly when one fails to start, which beats the old silent treatment).

A Chat You Can Actually Use

The chat buffer grew up too. A few of the quality-of-life additions:

• Slash commands (C-c /) – /explain, /fix, /tests, /doc, and friends, fetched live from the server.
• Acting on code blocks – C-c C-i inserts the code block at point into your source buffer, C-c M-w copies it to the kill ring. No more copy-paste gymnastics out of a read-only buffer.
• Attaching context – copilot-chat-add-file-reference (C-c C-f) and copilot-chat-add-region-reference let you hand Copilot specific files or selections along with your question.

Odds and Ends

A grab bag of smaller, but handy, additions:

• M-x copilot-quota shows how much of your chat, completion, and premium-request allowance is left – useful now that the fancy models eat into a quota.
• Copilot will tell you when a suggestion closely matches public code and collect those matches, with their licenses and reference URLs, in a buffer you can open via M-x copilot-list-code-citations.
• A pile of bug fixes, including agent-mode tool confirmations that were flat-out broken against newer servers, and chat finally picking a sensible default model on its own.

As always, see the full changelog for the complete rundown.

Epilogue

Agent mode, MCP, and semantic search are all opt-in, so nothing here changes your setup unless you ask for it. But I’d love for you to ask for it! Turn on agent mode, point it at a real task, and tell me where it shines and where it falls on its face. This kind of feature only gets good with people kicking the tires and filing detailed reports, so please do open issues and let me know how it goes. Your feedback is what shapes the next release.

I’d be remiss not to acknowledge it: there’s a decent chance that by now half of you have wandered off to Claude Code or some other agentic CLI, and that pouring this much time and energy into Copilot support for Emacs is, objectively, a questionable use of a human life. Fair enough.

But here’s the thing – Emacs has always excelled at providing amazing support for niche technologies long after the rest of the world has moved on. We’re the people who’ll lovingly maintain a mode for a language nobody has written any code in since 2003. Keeping Copilot first-class in Emacs is squarely in that grand tradition, and I, for one, intend to see it through. :-)

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

TIL about the which-function-mode in Emacs. It is a global minor mode that displays the current function in the mode line when enabled.

Introduction

I’ve used Emacs for many years.

My fingers knew the native bindings by heart. C-a, C-e, C-k, M-f, the whole choreography of chords. I never really questioned it.

Then I moved to Doom Emacs.

Doom is built around Evil, the Vim emulation layer. Vim keybindings are the default, on purpose. And the first thing I did was turn them off.

It was pure habit. I had years of native muscle memory and no intention of throwing it away to relearn how to move a cursor.

So for a while I ran Doom the “wrong” way: a Vim-first distribution with Vim disabled.

Later, I changed my mind.

Giving Evil a Real Chance

At some point it felt silly to run Doom against its own grain.

The whole project is designed around Evil. Most of its polish, its defaults, its bindings assume you’re editing the Vim way. By keeping native bindings I was fighting the tool instead of using it.

So I flipped the switch and committed to it.

The beginning was rough.

There’s a whole grammar to learn. Modes. Operators. Motions. Text objects. A language where pressing keys in the wrong order does nothing useful, and where the “obvious” Emacs reflex is suddenly wrong.

For a few days I was slower at everything.

Then, slowly, it started to make sense. And once it did, I kept it. This is still how I edit today.

One thing matters before the bindings, though.

What I switched to isn’t really Evil. It’s Doom in Evil mode, which is a very different, much friendlier thing.

It’s Doom, Not Raw Vim

This distinction took me a while to appreciate.

Evil on its own is the engine: it teaches Emacs to speak Vim. But raw Evil is spartan. Doom wraps it in a coherent set of defaults, a leader key, discoverable menus, and dozens of small integrations that make the modal model pleasant instead of merely functional.

which-key is the clearest example. Start a key sequence, pause, and Doom shows you every possible continuation in a popup. You’re never stranded wondering what comes next.

So when I say I switched to Evil, I really mean I switched to Doom’s curated take on it. I don’t think I would have stuck with bare Evil. The polish is what kept me.

The Mental Model That Made It Click

The breakthrough wasn’t memorising bindings.

It was understanding that Vim editing is a small language: a verb, then something to act on.

You combine an operator (the verb) with a motion or a text object (what to act on):

• d — delete
• c — change (delete, then drop into insert mode)
• y — yank (copy)

And the things to act on:

• w — to the next word
• iw / aw — “inner word” / “a word” (with surrounding space)
• i) / a) — inside / around parentheses
• ip / ap — inside / around a paragraph

Once that clicks, you stop memorising commands and start composing them. dw, ci), yap — none of these needed to be learned individually. They fall out of the grammar.

The other revelation was the dot command.

Pressing . repeats your last change. Edit one word, jump to the next occurrence, press ., and you’ve made the same edit again. It sounds trivial. It’s one of the things I’d miss the most.

The Editing Bindings I Reach For Daily

These are the ones that earned a permanent place in my hands.

Acting on the word under the cursor:

• daw — delete a word (and its surrounding space)
• caw — change a word (delete it and land in insert mode)
• diw — delete the inner word, leaving the spaces
• ciw — change the whole inner word
• cw — change from the cursor to the end of the word

Working with indentation, which is wonderful in indentation-heavy languages:

• dii — delete everything at the current indentation level
• cii — change that whole block

Doom ships the indentation text object (ii / ai), so these compose just like the word objects.

Commenting:

• gcc — toggle the comment on the current line
• gc + a motion — comment a region, e.g. gcap to comment a paragraph

And for shuffling things around, there’s a surprising amount you can do with operators and the p (paste) register. The Vim wiki has a good reference on swapping characters, words and lines that I still go back to.

Getting Around

Motion is where the modal model really pays off, because once you’re in normal mode the whole keyboard is navigation.

Jumping to a line is just the line number followed by G:

30G

That puts the cursor on line 30. (:30 followed by Enter does the same.)

Within a line, f and t are indispensable:

• f( — jump forward to the next (
• t( — jump just before it
• ; and , — repeat that jump forward and backward

But the binding that genuinely changed how I move is Doom’s avy integration, hiding under the gs prefix:

• gss — type a couple of characters and jump to anything visible on screen
• gsj / gsk — jump visually to a line below / above
• gs SPC — jump to any character, anywhere in the buffer

After a while, reaching for the mouse or hammering arrow keys feels slow.

For code, Doom’s LSP layer adds the usual suspects:

• gd — go to definition
• gr — find references
• K — show documentation for the symbol under the cursor

Doom’s Polish: The Leader Key

This is the part that has very little to do with Vim, and everything to do with why Doom is comfortable.

Almost every non-editing action lives under the SPC leader key:

• SPC f f — find a file
• SPC b b — switch buffer
• SPC p p — switch project
• SPC w — window management
• SPC s — search (in buffer, project, etc.)
• SPC g g — open Magit
• SPC : — run a command (the old M-x)

Because of which-key, I never had to memorise these up front. I’d press SPC, read the menu, and drill down. The bindings stuck on their own through repetition.

And when I want to know what a key does in the current mode, the bindings help is right there under SPC h b — a searchable list of everything currently bound. It’s how I discovered half of what I now use.

What I Didn’t Fully Convert

I’m not a purist about any of this.

A few Emacs reflexes survived the switch, simply because my fingers refused to let them go.

The big one is C-g. It’s my universal “get me out of here”, and it works everywhere in Doom, so I never replaced it. Leaving insert mode is the clearest case: I still do it three different ways depending on where my hands are — Esc, jk, or C-g. I never forced myself to settle on one.

In insert mode I also kept C-a and C-e to jump to the start and end of the line. That’s an Emacs-ism rather than a Vim one — Doom keeps those motions alive in insert state — and it’s so wired into my hands that switching to a normal-mode motion just to reach the end of a line never felt worth it.

And every so often I still reach for M-x instead of SPC : to run a command. Old habits.

On top of that I keep a handful of small custom bindings, and they fall into two telling camps.

Some of them duplicate what Evil already does. I bound my own commands to duplicate a line and to change the case of a word, even though Evil has perfectly good answers — yyp to duplicate a line, gUiw / guiw to upper- or lower-case a word. I kept the Emacs versions purely out of reflex.

Others have no Vim equivalent at all, and those I would never give up. Narrowing is the clearest example: focusing the buffer on a single region or function is a pure Emacs power, so I gave it a proper home under the leader.

(map! :leader
      :desc "Narrow to region" "n r" #'narrow-to-region
      :desc "Narrow to defun"  "n f" #'narrow-to-defun
      :desc "Widen"            "n w" #'widen)

That’s the honest part of the story. I didn’t replace one orthodoxy with another. I took Doom’s Evil as a strong default and bent the last few percent to fit my hands.

If anything, that’s the lesson: the goal isn’t to edit like Vim, or like Emacs. It’s to edit like you, on top of sane defaults.

Resources

A few things that helped me far more than any single cheat sheet:

• Noel Welsh — Doom Emacs Workflows covers the basics of finding text, moving text, workspaces and multiple cursors really well.
• niyumard/Doom-Emacs-Cheat-Sheet for a quick binding reference.
• The built-in SPC h b bindings help, which is the resource you’ll actually reach for once you’re inside Doom.

Was It Worth It?

Yes — with an asterisk.

It was worth it because, after the rough first days, modal editing genuinely made me faster: the verb-plus-object grammar turns most common edits into a couple of deliberate keystrokes.

The asterisk is that “switching to Evil” undersells what actually happened. I didn’t move to Vim. I moved to Doom, resisted its way of working for a while, then finally let it do what it was built to do.

The grammar fought me. Then it made sense. And it stuck.

Charles Choi has a nice post on simulating the Unix at command with Emacs. Back in the old days, Choi used to use the Unix at command to notify himself of various events. In macOS, the at command is disabled by default because its use can deplete the battery. Old habits die hard though, and Choi wanted a way to get the same behavior.

He started with the Emacs run-at-time function that does roughly the same thing as the at command except it runs an Emacs function instead of a command line function. Choi filled that gap with a macOS shortcut that he calls nota. The idea is that a small Emacs function schedules nota with the desired message at whatever time you want.

If you’d like to use his workflow, his post has a link to his shortcut that you can download. Of course, the shortcut bit works only with macOS but I doubt it would be hard to adapt to any Unix-like system. As far as I can see, the shortcut mechanism is merely a convenience and could probably be replaced with something like the Unix message command.

Regardless, if you’re looking for a handy way to serve a notification at a certain time and, like Choi and me, you have Emacs running all the time, take a look at his post.

I use org-roam for taking notes, but I also like to have indexes (just org roam nodes that link their contents) that link everything together. This means that if I want nodes properly linked when I make them, I first have to find the index they belong to insert them into, which really ruins the flow. I would rather go through the graph regularly and clean things up later, but aside from squinting at org-roam-ui finding those orphan nodes is actually quite annoying from within Emacs.

Thankfully I stumbled upon this note by Justin Abrahms, which gives a nice SQL query for finding orphans, and I've written a bit of Elisp around it to prompt for the resulting nodes with completing read. Hopefully someone else finds this useful!

(defun org-roam-find-orphan ()
  "Find all orphaned nodes and then provide their paths to open with completing-read."
  (interactive)
  (let* ((org-roam--db (sqlite-open org-roam-db-location))
       (org-roam-orphans
        (sqlite-select
         org-roam--db
         "select * from nodes n
where not exists ( select null from links l where n.id = l.source )
and not exists ( select null from links l where n.id = l.dest );")))
    (sqlite-close org-roam--db)
    (find-file
     (completing-read
      "Orphan node: "
      (mapcar
       (lambda (rec)
       (string-replace "\"" "" (cadr rec)))
       org-roam-orphans)))))

Back when I had to run a lot of long-running simulations on Unix systems, I became an ardent user of the at command, which lets one schedule a program to run at a future date. I also used at to schedule different notifications, like sending a message to a pager (yer, how quaint).

Moving to macOS (nee OS X) changed that, as it disabled by default the at command due to battery life management. As I was unwilling to give up battery life for at, I learned to live without it. That was, until I learned that Emacs had run-at-time.

The run-at-time command does as it says on the tin: it will run a function at some future specification of time.

1

(run-at-time TIME REPEAT FUNCTION &rest ARGS)

That specification of time is “natural language-like” in that multiple string representations of time can be accepted, both absolute and relative.

The function can be anything Elisp offers, but running shell commands is what makes run-at-time a substitute for at, with some caveats.

Jobs that are submitted by run-at-time can be listed out via the list-timers command. You can cancel a job (actually a timer object) using the c key, bound to timer-list-cancel. Note that Emacs disables list-timers by default as it exposes timers that you should likely not mess with. Be forewarned.

Another caveat is that using run-at-time presumes that your Emacs session is still running at that future time. If you have Emacs running all the time (particularly as a server) then this should work without complication.

Example: Scheduling a macOS Notification

A common use I have for run-at-time is to send myself a notification at a future time. The way I prefer to be notified is using the macOS Notification Center. Here’s an example of what a notification looks like:

The above notification was sent using a macOS Shortcut I’ve defined named nota. Shown below is how nota is defined in the Shortcuts app.

A macOS shortcut can be invoked from the command line. We can wrap this capability in the Elisp function cc/run-nota.

1
2
3
4
5
6
7
8

(defun cc/run-nota (msg)
  "Run nota shortcut with MSG."
  (process-lines
   "shortcuts"
   "run"
   "nota"
   "-i"
   msg))

Finally we can schedule cc/run-nota with run-at-time through the wrapper command cc/notify-at.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

(defun cc/notify-at (&optional start-time msg)
  "Send a nota notification with MSG at START-TIME.

This command invokes `cc/run-nota' with MSG at START-TIME passed into
`run-at-time'."
  (interactive)
  (let* ((start-time (if start-time
                         start-time
                       (read-string "Time: ")))
         (msg (if msg
                  msg
                (read-string "Message: "))))
    (run-at-time start-time
                 nil
                 #'cc/run-nota
                 msg)

    (message "Show notification “%s” in/at %s" msg start-time)))

Users wishing to install the nota macOS shortcut can download it via the following iCloud link:

nota shortcut (via iCloud)

Closing Thoughts

run-at-time is an underappreciated built-in which has given me much of what I used to use at for. If you use Emacs for implementing any kind of automation, you should include run-at-time as part of your toolbox for it.

It’s been a couple of months since the last neocaml release, and the reason is simple — for a while there I was genuinely out of ideas. Back when I shipped 0.6 I declared (again!) that I was done with new features, and this time I almost meant it. But ideas have a way of creeping back in, and 0.9 turned out to be a meaty release. Here are the highlights.

A much nicer REPL experience

The biggest chunk of work went into the REPL (toplevel) integration. I’m well aware that the OCaml toplevel isn’t terribly popular with seasoned OCaml developers — most of them reach for a proper build and a debugger instead. But I think newcomers get a lot of mileage out of a REPL, and (no surprise to anyone who’s followed my work) I’m a Lisper at heart with a real soft spot for interactive development. Clojure and Emacs Lisp spoiled me, and I want OCaml beginners to taste a bit of that too.

So, what’s new:

• A dedicated REPL per project. The REPL buffer is now named after its project (e.g. *OCaml: myproject*), and the send commands route to the current buffer’s project REPL. You can have several projects running side by side without them stepping on each other.

• Choose your toplevel. The new neocaml-repl-flavor lets you pick between ocaml, utop, and dune-utop. Set it globally, or per project via .dir-locals.el:

  1
  ((neocaml-mode . ((neocaml-repl-flavor . dune-utop))))
  

  The active flavor shows up in the REPL’s mode line, so you always know what you’re talking to.

• Send a phrase and step. C-c C-n (neocaml-repl-send-phrase-and-step) sends the phrase at point to the REPL and moves on to the next one — perfect for walking through a file top to bottom while you experiment.
• #require from Emacs. neocaml-repl-require loads a findlib package into the running toplevel without you having to type the directive by hand.
• Restart on demand. neocaml-repl-restart kills and restarts the toplevel when things get into a weird state.

Completion for Opam and Dune, no LSP required

This one I’m particularly happy with. .ml/.mli files have ocaml-lsp-server to lean on for completion, but the auxiliary file formats have no language server at all. That’s exactly the kind of gap neocaml is meant to fill, so both neocaml-dune-mode and neocaml-opam-mode now ship a completion-at-point backend.

In a dune file you get completion for stanza names, the field names valid for the enclosing stanza, and library names inside libraries/pps fields:

(library
 (name my_lib)
 (libraries str re|))   ; <- completes both your own libraries and installed findlib ones

The library candidates combine your project’s own libraries with whatever’s installed in the active Opam switch. And it’s switch-aware — if there’s a project-local switch (an _opam/ directory), neocaml detects it and queries it via opam exec --, without any configuration on your part. The results are cached per project, so it stays snappy.

In opam files you get completion for field and section names, and package names inside depends/depopts/conflicts (sourced from opam list):

depends: [
  "dune" {>= "3.0"}
  "cmd|"   ; <- completes to cmdliner and friends
]

Both backends can be toggled off via neocaml-dune-complete-libraries and neocaml-opam-complete-packages if you’d rather not have them.

Robustness improvements

A good chunk of this release is the unglamorous but important work of making things just behave correctly:

• Character literals and quoted strings at the syntactic layer. Tree-sitter fontifies '"', '(', and {|raw "strings"|} correctly, but the syntax table underneath was getting confused — which broke forward-sexp, delete-pair, and electric-pair-mode around those constructs. The fix was a good old syntax-propertize-function. I wrote up the whole story over on Emacs Redux in Tree-sitter Modes Still Need a Syntax Table, if you’re into mode-writing internals.
• project.el integration. A directory with a dune-project file is now recognized as a project root (even without version control), _build/ and _opam/ are ignored, and compile-command defaults to dune build in dune projects.

There’s more in there too — ocamlformat integration (C-c C-f), clickable URLs and bug references in comments, a font-lock level selector, and richer menus across the modes.

OCaml 5.5 support, and the ABI 14 balancing act

OCaml 5.5 was released on June 19th, so this felt like a good moment to ship 5.5 support in neocaml. The ocaml and ocaml-interface grammars now track tree-sitter-ocaml v0.25.0, which brings the 5.5 grammar along with it.

There’s a wrinkle here that’s worth explaining, because it’s shaped the last few releases. A tree-sitter grammar gets compiled into a parser that speaks a particular ABI version, and Emacs can only load parsers up to the latest ABI supported by the libtree-sitter it was built against — it’s not the Emacs version itself that sets the ceiling. In practice a lot of Emacs 30 builds out there (notably Homebrew’s on macOS) are linked against tree-sitter 0.24, which tops out at ABI 14; you need an Emacs built against tree-sitter 0.25+ to load ABI 15 grammars. The trouble is that the tree-sitter 0.25 CLI now generates ABI 15 parsers by default, so any grammar regenerated with current tooling produces something those builds simply can’t load — you install it and it just errors out. Emacs 31 will ship with newer tree-sitter and make ABI 15 the common case, but it’s not out yet. (This isn’t a neocaml problem as such; it’s been biting tree-sitter modes across the ecosystem.)

After a few users ran into exactly this, I’ve made a deliberate decision: stick to ABI 14 grammars until Emacs 31 is widely available. That effort started a couple of releases back — in 0.8.1 I lowered the ABI requirement from 15 to 14 across the opam, dune, and ocamllex modes, switched the menhir recipe to tmcgilchrist/tree-sitter-menhir, and pinned ocamllex back to v0.24.0, all of which target ABI 14 (#42). 0.9 extends that policy to the core OCaml grammars.

The catch with v0.25.0 is precisely that it generates an ABI 15 parser. Happily, the 5.5 grammar didn’t actually need any ABI 15 features — the bump rode along with the CLI upgrade — so an ABI 14 regeneration of the very same grammar is a drop-in. Big thanks to 314eter, the tree-sitter-ocaml maintainer, for cutting a v0.25.0-abi14 tag for exactly this purpose (#141). The one snag was that tagging normally triggers releases to NPM, crates.io, and PyPI, so I sent a small PR to skip publishing for ABI-suffixed tags (#142), and the tag followed. neocaml now pins both grammars to it.

Roadmap and docs

If you’re curious where neocaml is headed, I’ve started keeping a ROADMAP.md with ideas and guiding principles (short version: tree-sitter first, lean on the LSP stack for .ml/.mli, and own the auxiliary modes that have no language server). The project also has a proper documentation site now at neocaml.org, so there’s a real home for the details beyond the README.

Give it a Try

As always — update from MELPA, play with it, and let me know how it goes. The full list of changes is in the 0.9.0 release notes. Bug reports, feature requests, and pull requests are all welcome on GitHub.

That’s all from me, folks! Keep hacking!

Suppose you want to schedule a recurring meeting in the diary, yet you want to access an org heading for note-taking and clocking time. You can add a link to that org heading in the description of the diary event.

Here's how I'd do it:

• Place point on the desired Org heading
• Invoke org-store-link, which might be bound to C-c l
• In the diary file...
  • Add the date expression for the corresponding event. In this example, we'll schedule an event that occurs from 7pm to 8pm on the third Tuesday of every month.
    • %%(diary-float t 2 3) 19:00-20:00
  • Add a space and then the link as the event description with M-x org-insert-link
    • Note that C-c C-l might not bound to org-insert-link in diary-mode
• That's it!

I have been using Eat and toggle-term.el for terminal emulation in Emacs. After seeing some recommendations for Ghostel, I decided to give it a try, especially since I use Ghostty as my terminal emulator on the Mac anyway. All the reports were correct, Ghostel works like a charm, but I didn’t have as smooth a toggle experience as I had with Eat. Before switching back, I wondered if I really needed to install a package just to toggle the Ghostel buffer. It turns out that writing a simple toggle function was fairly easy.

The first function returns the name of the ghostel buffer if there is one. The second function starts ghostel if there is no existing ghostel buffer, switches to the buffer if there is one, and buries the ghostel buffer if it is currently the active buffer. I had to use bind-key* to override the ghostel key-map.

(defun rlr/ghostel-buffer ()
  "Return the active ghostel buffer, or nil if none exists."
  (seq-find (lambda (buf)
              (string-match-p "\\*ghostel:" (buffer-name buf)))
            (buffer-list)))

(defun rlr/ghostel-toggle ()
  (interactive)
  (let ((buf (rlr/ghostel-buffer)))
    (cond
     ((not buf)
      (ghostel))
     ((eq (current-buffer) buf)
      (bury-buffer))
     (t
      (switch-to-buffer buf)))))

(bind-key* "<f2>" 'rlr/ghostel-toggle)

As you all know by now, I’m not a Google fan and generally avoid using their products. The one exception is YouTube for videos. Apparently, YouTube also has a radio channel, which is a sort of music streaming service. I listen to my music offline so I’m not interested in steaming services and even if I were, I’d probably use Apple’s or maybe the Amazon service that I get for free as an Amazon Prime member.

Still, lots of people don’t share my antipathy to Google and at least occasionally like to stream music. One such person is Álvaro Ramírez who sometimes has the urge to listen to YouTube radio channels and, being Ramírez, built an Emacs player, ytr, to do that. As usual, he built ytr to scratch and itch and is using it to experiment with its UI with the long term goal of possibly integrating it into his music player, ready-player.

Ytr is still at an early stage of development and will probably change as Ramírez gets more experience with it. It’s not yet in MELPA, of course, but you can get a copy from its GitHub repository where you’ll find installation instructions as well as a command summary.

If you have any interest in playing YouTube radio from within Emacs, take a look at Ramírez’s post and the ytr GitHub repository.

Update [2026-06-24 Wed 10:08]: Álvaro Ramírez reached out to me offline with a clarification. What ytr actually does is download the audio track from any YouTube video. As Ramírez says, often the video portion is secondary to the audio. I’ve noticed that that’s especially true for older recordings where the video portion may consist simply of a picture of the album cover or the artist.

A few months ago I became obsessed with a silly question: why does my Emacs, on a laptop with a perfectly capable GPU, draw all of its text using the CPU? And that led to others: why can't I play a video inside a buffer? Why can't I have animated cursor effects? Why can't I cross-fade between buffers? I needed to satisfy my curiosity, so I started digging.

I started reading the code, with an AI as my companion. I discovered that every glyph, every underline, every scroll is recomputed and repainted by the processor. Emacs's redisplay engine (xdisp.c) was born in an era when there was no other option, and it is tuned to the millimeter for exactly that. And nobody had managed to slip a GPU underneath without rewriting half of Emacs... until recently.

So I decided to try. What began as a weekend experiment ended up being a complete display backend for macOS with Metal, a second backend for GNU/Linux with OpenGL, a video player inside the buffer, shader-based cursor effects, and a debate of more than a hundred messages on the Emacs developers' mailing list that ranged from cairo's performance to software freedom and the ethics of artificial intelligence.

This article exists because I feel like telling the story, and it might be useful for future implementations. At the end I leave the lessons I take away and a conclusion that is not the one I expected when I started.

A note of honesty up front: I built this project with the help of an LLM as a copilot, from start to finish. I say it here just as I said it in public when I was asked. I will come back to it, because it turned out to be the most important plot twist of the whole journey.

Phase 1: the architecture decision

Anyone's first instinct would be to open the macOS code, the Cocoa backend (nsterm.m), and start replacing CoreGraphics calls with Metal calls. It is the most direct path. And it is exactly what I decided not to do.

The problem with that approach is that it ties you to one platform. If I write "Emacs with Metal", I have an Emacs for Mac and nothing else. I needed to write a display-backend abstraction that would let me have one driver per platform. So I sketched a three-layer architecture on a Post-it:

flowchart TD
    X["Redisplay engine
(xdisp.c, untouched)"]:::core --> P["src/gfxterm.c
Neutral drawing policy (plain C)"]:::policy
    P --> D["src/gfxdrv.h
Driver interface (~25 operations)"]:::iface
    D --> M["src/mtlterm.m (macOS)
Metal driver"]:::mtl
    D --> G["src/glterm.c (GNU/Linux, X11)
OpenGL ES / EGL driver"]:::gl

    classDef core fill:#37474F,stroke:#263238,stroke-width:2px,color:#fff
    classDef policy fill:#00897B,stroke:#00695C,stroke-width:2px,color:#fff
    classDef iface fill:#7CB342,stroke:#558B2F,stroke-width:2px,color:#fff
    classDef mtl fill:#8E24AA,stroke:#6A1B9A,stroke-width:2px,color:#fff
    classDef gl fill:#D32F2F,stroke:#B71C1C,stroke-width:2px,color:#fff

The idea is that all the drawing logic (how a glyph string is composed, where the wavy underline goes, how an image is clipped to the window, how scrolling works) lives in a plain-C file, without a single platform-specific line. And that each platform only has to implement a small contract: about 25 primitive operations of the kind "upload this texture", "draw this quad", "present the frame". That contract is gfxdrv.h. The first driver would be Metal, in mtlterm.m.

The golden rule, the one I imposed on myself and never broke once: xdisp.c is not touched. The redisplay engine computes the glyph matrices exactly as always; I only hook into the drawing interface that already exists. If the experiment went wrong, Emacs was still Emacs.

In hindsight, this was the best decision of the whole project!

Phase 2: the Metal backend and the tyranny of the pixel

With the architecture clear, I dove into Metal. The technical plan was that of any modern text renderer:

1. Rasterize each glyph just once, via CoreText, into a grayscale texture (a glyph atlas in R8 format).
2. Draw the text as textured quads that sample that atlas.
3. Upload images (PNG, JPEG, SVG, GIF) as textures.
4. Composite the whole frame on the GPU, in a persistent texture, and present it.

On paper, two afternoons. In practice, weeks. The reason has a name: pixel parity.

My success criterion was not "it looks good". It was that the result be identical, pixel for pixel, to the original Cocoa backend. Same binary, with the GPU on and off, and the diff between the two captures had to be practically zero. I built a harness that launched the same Emacs twice, loaded an identical scenario, captured the screen on both and compared them with Python and PIL. The bar landed around 0.055% of differing pixels in the baseline, and anything that strayed from there was a bug to hunt down.

That harness was relentless, and it surfaced a collection of details I had to look at under a magnifying glass:

• The ink weight. CoreText and my shader applied antialiasing differently.
• The relief colors (the 3D borders of buttons and the mode-line) were not coming out right.
• There was an off-by-one in the vertical position of the glyphs.

We should not overlook that the way of drawing is completely different, both in approach and in architecture. That makes the bugs subtle and hard to detect.

Phase 3: the cursor that froze

Of all the bugs, the one that taught me the most was the cursor one.

I wanted animated cursor effects: a ring that expands when it jumps, a comet-like trail, that kind of visual candy the GPU does almost for free. I implemented them as a compositor layer on top of the frame, without touching the buffer content underneath. They worked perfectly... while I was typing. The moment I stopped touching the keyboard, the animation froze halfway. The culprit was Apple's synchronization mechanism, CADisplayLink: it dies at rest, Emacs's event loop does not feed it when there is no user input. While I typed, the keyboard events pumped the run loop and everything ran fine; the moment I stopped, there was no one to move the clock.

The solution was to stop depending on the system and move everything continuous to a Lisp timer. Cursor, buffer cross-fade and video, everything advances from a single "pump" in Emacs Lisp that ticks periodically and tells the driver "advance everything you have and present at most once". Later I unified the three timers into one with auto-pacing (60 Hz when there is a fade, 30 Hz otherwise, and it shuts itself off when there is nothing to animate).

Once this was solved, macOS was complete. Text, decorations, images, animated GIF, line numbers, fringes with custom bitmaps, mode-line, header-line, tab-bar, Retina/HiDPI at 2x, the four cursor types, splits, dynamic text-scale. Everything pixel-perfect against Cocoa.

Now it was time to add the things only the GPU can do:

• Video inside the buffer
• Shader-based cursor effects
• Cross-fade when switching buffers.

As an experiment I even put together a small YouTube frontend inside Emacs: it searched for the video and played it directly in a buffer, with the GPU compositing the frames over the text. A fun little silliness that is only possible when the frame is painted by the graphics card.

And the cross-fade when switching buffers, a smooth fade that on the GPU is just one more shader pass:

It was relatively simple, since the redisplay engine neither knows nor cares what I do on top of it; they are just compositing operations on the GPU.

Phase 4: packaging is half the work

Having the binary working on my machine and having something another person can install are two different planets. This phase has no glamour but it ate whole days.

Apple's signing and notarization were a labyrinth of their own. And when I added native-comp (AOT native compilation), about 1564 .eln files appeared that are also Mach-O code and also have to be signed one by one, with a secure timestamp, for notarization to accept them.

I published the first signed and notarized release, a Homebrew cask, and started using it daily along with a colleague. It worked. I was happy. I thought the hard part was behind me.

Then I decided to show it to the Emacs mailing list.

Phase 5: emacs-devel, or how to learn humility in an email thread

On June 8, 2026 I sent an [RFC PATCH] to emacs-devel with the subject "GPU display backend with a neutral driver layer (Metal on macOS)". I framed it carefully: I was not selling "Emacs with Metal", I was selling the abstraction. A neutral drawing layer plus a thin per-platform driver behind a small vtable, with Metal as the first driver, xdisp.c untouched, parity verified with an automatic harness, and the FSF copyright assignment already on file.

My first mistake was sending the complete patch, rather than an RFC with the idea, the design and a minimal demo. The response came fast:

Sean Whitton wrote:

"People don't normally post such large patches at once without first discussing the design issues with people on the list. Given this, I just have to ask, this isn't LLM-generated, is it?"

I answered honestly:

"100% created with LLM.

I understand that this is a rather large addition, and if it's rejected, I won't be offended. My intention was to share it because it's fully developed [...]; I'm using it daily without any problems (along with other colleagues)."

Whitton's reply was courteous and final:

"I'm afraid there is a policy conflict. The GNU project does not accept any LLM-generated contributions at present. Thank you for your interest in Emacs, anyway."

And there, in terms of "does this get merged?", the project died in less than a day. The GNU project does not, as of today, accept LLM-generated contributions. Period. No technical debate matters when it collides with a hard policy.

What I did not expect is that, far from closing the thread, it opened in three directions at once.

The turn toward "study subject"

Dmitry Gutov set the tone for what was coming:

"We cannot accept this as code contribution, but if you are already using it locally, it might be useful as a study subject. It might be more useful to test with a Linux port, though."

In other words: as code it does not get in, but as a reference or an experiment it might be worth something. And there, too, was the seed of what I would do next.

The freedom debate

And then Richard Stallman stepped in, forking the thread's subject to "GPU-specific code with no GPU-specific features?" and raising it to a moral question:

"In general the GPU is a disaster for software freedom: it turns your computer into a prison."

Later, insisting:

"They don't put physical chains on the user, but they do put digital chains on the user's computing. GPUs are a substantial part of what we are fighting to free people from."

Not everyone bought it. Arsen Arsenović answered with the sharpest technical objection in the thread:

"This is a bizarre comparison based on frivolous word association. GPU programming APIs such as Vulkan or OpenGL [...] can be implemented fully in software, and indeed are implemented using fully free software in Mesa, so there's no downside to using them from this perspective."

And Madhu brought up the uncomfortable fact that dismantles half the discussion:

"If you are using X11 on a modern (say post 2021) intel machine on linux, all your 2d graphics probably goes through the GPU backend, X11 windows are just textures."

They were right about something I could demonstrate: my OpenGL driver also runs on Mesa's software rasterizer (llvmpipe). In fact, the parity suite runs headless on it. In other words, the code does not require non-free GPU firmware to be exercised. I said so in the thread, although by then the debate had a life of its own.

The underlying technical doubt

The most substantive criticism, and the one that made me think the most, was neither the political nor the ideological one. It came from Eli Zaretskii, one of the historical maintainers:

"I'm not really surprised that using a GPU in the display backend yields performance gains that are not really spectacular with reasonable sizes of the frame: the design of the current display engine is optimized towards CPU-driven redisplay, so taking a better advantage of GPUs will probably need a more thorough redesign, not just a separate backend."

And Gerd Möllmann, the redisplay maintainer, finished it off with elegant indifference:

"It looks to me as if this adds GPU support without adding GPU-only features or changing the architecture of redisplay [...]. Can have performance benefits, maybe, don't know, but it's outside of my field of interest."

They were partly right. The engine is built to repaint small dirty rectangles on the CPU, and cairo does that extraordinarily well. Slipping a GPU underneath without redesigning the engine has a ceiling. But they were also partly making a point that can only be seen with a second backend and with numbers. And I had neither one yet.

The community had, without knowing it, written my roadmap for the following weeks: build a second backend (to validate the abstraction) and bring honest numbers (to settle Eli's doubt).

Phase 6: the OpenGL driver, or how to cash in the architecture bet

If my design's big promise was "the neutral layer is reused as-is, you only change the driver", the only way to prove it was to write a second driver from scratch and see how much shared code survived untouched.

I chose GNU/Linux over OpenGL ES 3 with EGL, on X11. The cross-platform counterpart of the Metal driver: I rasterize the glyphs with FreeType into a GPU atlas, render to an FBO and present by blitting to the window surface with eglSwapBuffers. The drawing policy, gfxterm.c, I reused entirely. And it worked: the second backend came out pixel-perfect against the stock GTK/cairo Emacs, on the same exhaustive test battery as macOS, running both on a real X server with a GPU and headless under Xvfb for the harness.

That was the moment the architecture stopped being a promise and became a fact. Writing the whole driver, with all its EGL and FreeType quirks, took me far less than the first one, because all the hard logic was already written and tested in the neutral layer.

But Linux brought its own hell, with the hardest bugs of the entire project. The worst one: when switching buffers, during a single flicker (one vblank), the half-painted startup dashboard leaked through, ghost images of other content. It took me days to discover that the root cause was not my GPU code, but the back buffer of X11's double-buffer extension (XDBE), which Emacs painted at startup and my backend never touched again.

Still, after a while of work and debugging, the OpenGL driver became stable and functional. Not perfect, but good enough to run the performance harness and compare it against cairo.

Phase 7: optimizing and bringing honest numbers

The results, on a laptop with an integrated AMD Radeon (Renoir) GPU, a 1616x912 frame, an 8000-line font-locked buffer:

On a laptop-sized frame, typing and line scroll are still slower than cairo, which is excellent at clipping small rectangles. My floor is one EGL buffer swap per redisplay; cairo's is a tiny damage rectangle with no swapchain. In absolute terms, everything is far above what is perceptible (the worst case, typing, is ~0.8 ms per keystroke), so it is a matter of throughput, not of responsiveness.

In short: a GPU backend does not beat a mature CPU rasterizer at static text.

But the same workloads at 4K (3760x2210) flip the result:

cairo's cost grows linearly with the pixel count; the GPU's barely moves. Image scroll is the extreme case: cairo re-blits the image from CPU memory every frame, the GPU re-composites an already-cached texture. There, plus the features that only exist on the GPU (video, cross-fades, cursor effects), is where the real value lies. Text throughput on a small screen is not.

Conclusion

Let's be honest, for everyday text on a normal screen there is no reason to switch; the CPU backend is just as fast or faster. The GPU earns its place in motion, effects and video at high pixel counts, things the CPU does more expensively or cannot do at all.

The backend will never be merged into Emacs, and that is fine. It collides with the policy of not accepting LLM-generated contributions, and that is a legitimate decision by the project that I respect. I keep it as a personal fork, behind --with-gpu, opt-in and disablable with an environment variable, and I use it daily.

Was it worth it, then? For me, without a doubt. I came out with a complete display backend on two platforms, with video inside the buffer and effects that stock Emacs cannot draw, with an architecture that proved it could hold up across two implementations, and with a pile of technical scars worth their weight in gold. But above all I came out with something I was not looking for: a public, hard and honest conversation, with people who have maintained this editor for decades, about performance, about software freedom and about the role of AI in the code we write. That conversation, quoted above in their exact words, is worth more than any merge.

Right now I am focusing my efforts on the OpenGL backend for GNU/Linux, where there is still much to polish and optimize. If you are interested in trying it, in the repository you will find a .deb with the test binaries.

My final advice, if you are considering something similar: chase the experiment that obsesses you even if you know it might not end where you imagined. I started out wanting my GPU to draw text and ended up learning about architecture, about rasterization, about packaging, about the culture of a 40-year-old project and about myself. The destination turned out to be irrelevant. The journey did not.

The code is at github.com/tanrax/emacs-gpu, and the full emacs-devel thread can be read in the June 2026 archive.

There was lots of discussion around Rahul's post on Emacs 31. It's the first link in the list below, so I won't repeat the links here. Also, I like visualizations, so I thought these force-directed graphs (Reddit) and text-based mindmaps (Reddit, lobste.rs) were pretty cool. Enjoy!

• Emacs 31:
  • Emacs 31 Is Around the Corner: The Changes I'm Already Daily Driving (Reddit, HN, lobste.rs, Irreal)
• Upcoming events (iCal file, Org):
  • Emacs Berlin: Emacs-Berlin Hybrid Meetup https://emacs-berlin.org/ Wed Jun 24 1000 America/Vancouver - 1200 America/Chicago - 1300 America/Toronto - 1700 Etc/GMT - 1900 Europe/Berlin - 2230 Asia/Kolkata – Thu Jun 25 0100 Asia/Singapore
  • Emacs APAC: Emacs APAC meetup (virtual) https://emacs-apac.gitlab.io/announcements/ Sat Jun 27 0130 America/Vancouver - 0330 America/Chicago - 0430 America/Toronto - 0830 Etc/GMT - 1030 Europe/Berlin - 1400 Asia/Kolkata - 1630 Asia/Singapore
  • EmacsATX: Emacs Social https://www.meetup.com/emacsatx/events/315091677/ Thu Jul 2 1600 America/Vancouver - 1800 America/Chicago - 1900 America/Toronto - 2300 Etc/GMT – Fri Jul 3 0100 Europe/Berlin - 0430 Asia/Kolkata - 0700 Asia/Singapore
  • M-x Research: TBA https://m-x-research.github.io/ Fri Jul 3 0800 America/Vancouver - 1000 America/Chicago - 1100 America/Toronto - 1500 Etc/GMT - 1700 Europe/Berlin - 2030 Asia/Kolkata - 2300 Asia/Singapore
  • Emacs.si (in person): Emacs.si meetup #7 2026 (v #živo) https://dogodki.kompot.si/events/88d59360-d89a-42cc-b567-ed39ac5186fb Mon Jul 6 1900 CET
• Beginner:
  • Emacs Teaches Emacs: The Missing README (YouTube 13:57, Reddit, Irreal, @chiply@fosstodon.org)
  • Charlie Holland: Juneau Something? Emacs Teaches You How to Fish! (YouTube 01:13:19, Reddit, Irreal, @chiply@fosstodon.org)
• Emacs configuration:
  • Marcin Borkowski: Disabling minor modes with local variables
  • For straight.el people: an overview of outdated packages, and control over what gets updated (Reddit)
  • Updated Chadmacs (Reddit)
  • Firemacs Review (Reddit)
• Emacs Lisp:
  • Tip: debug-on-variable-change (@lucashtns)
  • Xah Talk Show Ep795. emacs lisp. add width height to html image thumbnails. part 2 (01:01:50), part 3 (02:19:51)
  • Construindo um pacote do Emacs como um asteca (01:33:45)
• Appearance:
  • Ghosting cursor effect
  • Some cursor flare (Reddit)
  • Dave Pearson: More mode line tweaking
  • Modus Nordic (Mid-)Night: high-contrast themes using the Nord color palette using Modus Themes as the base
  • Protesilaos: Emacs: testing common colour values with the doric-themes
  • Protesilaos: Emacs: ef-themes version 2.2.0
  • Protesilaos: Emacs: modus-themes version 5.3.0
• Navigation:
  • Emacs Redux: Essential Structured Navigation and Editing Commands (Irreal)
  • Underappreciated Emacs built-ins: hideshow 6.0
  • Emacs HideShow Minor Mode For Folding And Unfolding 2026_06_21_03:01:51 (07:02)
  • Amazing bookmarks (or quick keymaps) (Reddit)
  • Marcin Borkowski: Scrolling pdfs in other windows (Irreal)
  • How to Split the Screen in Emacs (02:02)
• Dired:
  • Dired Global Script Runner: A Yazi-inspired global file marking system for Dired
• Writing:
  • luqtas/log-mode: cheap copy of Logseq with some extra goods · GitHub
• Org Mode:
  • RFC: Ideas for clearer Org clock idle resolution prompts? (Reddit)
  • [RFC] org-agenda log-mode is very confusing - Morgan Smith (Reddit)
  • [FR] add :company-doc-buffer, :company-kind etc properties for pcomplete in org-mode - stardiviner
  • devops.el - Infrastructure as an org file (Reddit)
  • v1.6.0 · kickingvegas/anju · context menu support for Org agenda (@kickingvegas@sfba.social)
  • Raymond Zeitler: Emacs Carnival: diary, Part 2 (Irreal)
  • org-mindmap v0.3.0 (Reddit, lobste.rs)
  • Exporting org files to PDF with the Eisvogel latex template (Reddit)
  • Org Mode requests: [FR] Exporter for ltx-talk
  • Notes on recent OrgDevMeetup (Reddit)
  • Org development: org-colview: Add quick help for column view
• Completion:
  • Underappreciated Emacs built-ins: completion-preview-mode
• Coding:
  • Meta Redux: CIDER 1.22 (“São Miguel”)
  • Start Guile shell script that listens on a port for REPL client - box.matto.nl (@mattof@snac.lab8.cz)
  • hgrsd/ztags: Generate ctags-based tags for your Zig project, including Zig sources and stdlib. (@hgrsd@hachyderm.io) - now supports etags output
  • ~shoshin/ruby-khipu - Implementation of the Inka Khipu as a data structure in Ruby. - sourcehut git (@shoshin@buzz.cicadas.surf) - literate programming
• Shells:
  • Ghostel is Fantastic (Github)
  • tmux-control : control-mode client for tmux (Reddit)
  • kitty-graphics.el 1.0.0: images, video, and documents in terminal Emacs (Reddit)
  • eat-serial: An eat term based serial terminal
• Web:
  • URL로부터 Title을 가져오고 Web Archive 링크를 생성하는 Emacs 함수 - (emacsian ohyecloudy)
• Mail, news, and chat:
  • Clatter: An IRCv3-compliant IRC client (Reddit)
  • Elfeed 4 0 0 使用分享 (49:47)
• Evil mode:
  • evil-mode tip: make \ allow one-off normal state execution (@rogerfarrell)
• Multimedia:
  • How I built a GPU backend for Emacs | Andros Fenollosa (@andros@activity.andros.dev)
    • Cómo construí un backend de GPU para Emacs | Andros Fenollosa
  • Emacs SVG rendering in force directed graph sims revisited (Reddit)
  • Speech to text with Whisper-cpp Emacs and whisper.el (55:56)
  • Alvaro Ramirez: ytr: YouTube radio for Emacs (Reddit, HN, Irreal)
• AI:
  • Bending Emacs Episode 14: Prototyping iOS apps with agent-shell, artist-mode, and Claude Skills (YouTube 26:39, Reddit)
• Community:
  • Fortnightly Tips, Tricks, and Questions — 2026-06-16 / week 24
  • Is anyone still using Emacs? - by Julio Merino (lobste.rs, HN, HN)
  • xvw.lol - Emacs, how it all started (for me) (HN, @xvw@merveilles.town)
    • xvw.lol - Emacs, comment tout a démarré (pour moi)
  • Sacha Chua: Emacs Chat 26: Ross A. Baker (YouTube 01:02:45)
• Other:
  • Raymond Zeitler: Emacs Carnival: diary, Part 1
  • Dave Pearson: become.el v1.4.0 - tidying files before saving
  • Document View (GNU Emacs Manual) (@annamalai@mathstodon.xyz) - can open PDFs as plain text
  • Monadic Sheep: Hello there! - Emacs Reader, PALE (picture and animation), canvas patch, Insidious YouTube client
  • Switching from the Mac port Build of Emacs to the Standard NS Build | Masutaka's ChangeLog Memo
    • Mac port 版 Emacs から、標準の NS 版に乗り換えられた | マスタカの ChangeLog メモ
• Emacs development:
  • gv.el: Allow use of `ignore` as a place (bug#81217)
  • Support OSC 8 hyperlinks in man pages
  • ; * etc/NEWS: Document 'newsticker-treeview-copy-url' (bug#81013).
  • VC-Dir shows key binding hints
• New packages:
  • clatter: An IRCv3-compliant IRC client (MELPA)
  • countdown-modeline: Display a color-coded countdown in the modeline (MELPA)
  • leadkey: Translate leader keys to key sequences (MELPA)
  • notmuch-multi: Prettified Notmuch UI For Multiple Accounts (MELPA)

Links from reddit.com/r/emacs, r/orgmode, r/spacemacs, Mastodon #emacs, Bluesky #emacs, Hacker News, lobste.rs, programming.dev, lemmy.world, lemmy.ml, planet.emacslife.com, YouTube, the Emacs NEWS file, Emacs Calendar, and emacs-devel. Thanks to Andrés Ramírez for emacs-devel links. Do you have an Emacs-related link or announcement? Please e-mail me at sacha@sachachua.com. Thank you!

You can e-mail me at sacha@sachachua.com.

I've been a happy ready-player user for some time now. I consider the Emacs package fairly feature-complete, for my needs anyway. Well almost.

While I've successfully migrated most of my music-listening to offline playback, there are the odd times when I enjoy streaming YouTube audio. I've pondered extending ready-player for this use case, but its current approach is fairly file-driven. For starters, it uses dired as a core abstraction.

Before venturing on a major refactoring, without even knowing if an Emacs streaming flow would stick, I decided to build a new package. Coincidentally, this enables me to experiment with the package UX without being restricted by ready-player's needs. And so that's what I did in my new YouTube radio package ytr.

ytr really is fairly experimental. I'm currently driving its development purely on current needs. Let's see where it goes. It borrows lots from ready-player, but its UX presents itself more as a widget. I'm kinda liking the experience. There isn't much to it: you add a channel URL, and its content metadata is automatically pulled and presented as a child frame. I've also sprinkled in some eye candy (animations), reminiscing about the Winamp days. Beware, these sweets require running on Emacs GUI.

ytr is powered by mpv and yt-dlp, the real streaming workhorses doing the heavy lifting.

ytr is available on GitHub if you're keen to check it out. Keep in mind this is a brand new package and a first iteration, so it may need some improvements. If you give it a try, I'd love to hear how you got on. I've only tested on macOS so far.

Make it sustainable, sponsor the effort

Liking ytr? Would like to see it evolve? Consider sponsoring the effort.

As I wrote earlier, I consider diary to be an underappreciated Emacs built-in.

I got interested in it again when I wanted to schedule a recurring meeting in Org for the third Tuesday of every month. I saw on Reddit that some folks use diary-float in place of the usual active timestamp to achieve this. So I added this after the meeting header to make it work:

  * Third Tuesday of the Month Club
  SCHEDULED: <(%%diary-float t 2 3) 19:00-20:00>

I have five meetings that use this method of automatic scheduling. I like this approach because of its simplicity and elegance. Unfortunately, it doesn't behave the same way as a recurring task.

When I mark a recurring task as complete, Org reschedules it for the next date on which it should occur. And it changes DONE to TODO to ensure the event shows up on the agenda for the next occurrence.

This doesn't happen for a task that's scheduled with diary-float. When marked complete, the headline remains at DONE; the next event won't show up on the agenda.

And so Fengyuan Chen wrote next-day-spec¹ to solve this issue. Unfortunately it doesn't work with the latest versions of Emacs.

One of the many recognized cognitive biases is called the Sunk Cost Fallacy², which impels an individual to favor an inferior (or incorrect) solution because a significant amount time, money, and/or effort has been invested in the solution. Well, I've invested time and effort in both diary-float and next-day-spec, so I've continued to endorse it as a solution.

But even if rescheduling did work, I think it's better to have each meeting scheduled as a subheading of the overall meeting topic, like this:

  * Third Tuesday of the Month Club
  ** DONE May 2026: <2026-05-19 Tue>
    :LOGBOOK:
    CLOCK: [2026-05-19 Tue 18:54]--[2026-05-19 Tue 20:12] =>  1:18
    :END:
    - Note taken on [2026-05-19 Tue 21:20] \\
    We ate pizza.  Again.
    ** TODO June 2026: <2026-06-23 Tue>
      ** TODO July 2026: <2026-07-21 Tue>

The advantage to this is that clocked time and notes are organized neatly within each individual subtopic, not aggregated into one logbook and a series of notes. If the aggregated time is desired, one could insert the log report. I'll review this in another post.

But it's fun to schedule events that occur on irregular dates, such as National Engineers Week (US), which is the week in which George Washington's birth anniversary occurs³. Here's how you can add it to an Org file:

  * TODO Celebrate Engineers Week!
  SCHEDULED: <%%(equal (calendar-gregorian-from-absolute (calendar-dayname-on-or-before 0 (calendar-absolute-from-gregorian (list 2 22 (calendar-extract-year date))))) date)>

Do you have a favorite use for dairy?

Bozhidar Batsov has an excellent post that considers structured editing using builtin Emacs commands. It turns out that all those commands (like forward-sexp) that you think of as Lisp-specific commands work in many other modes. The secret is that the target mode has to tell the commands how to find structure boundaries.

There are several ways of doing that. The oldest is to use the mode’s syntax table but that doesn’t work if the structure is bounded by things like structure … end. The more modern method is to provide functions that can find these boundaries and, of course, the most modern is to use Tree-sitter with an actual grammar of the target language.

Pay particular attention to the Ctrl+Meta commands. If you’ve done any Lisp programming, they’ll be familiar but they’re useful for a lot of other languages—even plane text. For example, I use Ctrl+Meta+Space all the time to progressively mark words in a text buffer. It’s a bit easier than using Ctrl+Space and then some motion command to do the same thing.

As Batsov says, the Ctrl+Meta commands keep getting smarter as more major modes teach them about their syntax. His post is full of good information that I haven’t mentioned here so be sure to head over and read it.

Hello there! This is MonadicSheep’s first blog post. Even though this is our first public post, we have been working on several projects over the last few months. This will be a brief overview of the projects and their developments.

Charlie Holland has a followup to his post on Emacs Help that I wrote about the other day. It’s a reconsidered, condensed version of the original post. As Holland puts it,

This is a condensed version of my very long June Emacs Carnival post on the same topic. I wanted to make this as I felt it would be more intuitive for beginners, who are most likely to benefit from learning Emacs’s auto-discovery features.

It actually is more useful both for n00bs and experienced users alike. The best example of that is his explicit calling out of what he calls “the prefix trick”. The idea is that there are a handful of prefixes that begin many help commands. One example is describe- that begins all the help commands that describe something: describe-function, describe-variable, etc. The “trick” is that you can type Meta+x describe and then Tab to get a list of all the describe commands. That’s something that most of us know implicitly but it’s useful to have it pointed out explicitly.

The other useful fact, which I wasn’t aware of, is that Meta+x which-key-show-top-level will show all the commands without a prefix.

The point of Holland’s followup is that you don’t need to memorize a lot of arcana to use the Emacs Help system. If you know the prefixes to use with Meta+x and Ctrl+h Ctrl+h to bring up the Help cheat sheet, you’re good to go.

Update [2026-06-23 Tue 11:15]: Added link to followup.

I just published the latest stable release of the Modus themes. The change log entry is reproduced further below. For any questions, you are welcome to contact me. I will now work to apply these same changes to emacs.git, so please wait a little longer for the updates to trickle down to you.

• Package name (GNU ELPA): modus-themes (also built into Emacs 28+)
• Official manual: https://protesilaos.com/emacs/modus-themes
• Change log: https://protesilaos.com/emacs/modus-themes-changelog
• Colour palette: https://protesilaos.com/emacs/modus-themes-colors
• Sample pictures: https://protesilaos.com/emacs/modus-themes-pictures
• Git repositories:
  • GitHub: https://github.com/protesilaos/modus-themes
  • GitLab: https://gitlab.com/protesilaos/modus-themes
• Backronym: My Old Display Unexpectedly Sharpened … themes.

5.3.0 on 2026-06-21

The Modus themes are in a stable state. To my mind, they provide the best “default theme” experience across the 40+ original themes I have carefully designed.

Modus is also a platform for making themes for Emacs. There are plenty of derivatives already. I am linking to them through the project’s README.md and am always happy to mention more packages—just let me know.

This version does not include many user-facing changes. Most of my work focused on making internal refinements.

Load the themes through the early-init.el

The Modus themes can now be loaded through the early-init.el file. The idea is to avoid the flash of light that occurs under certain conditions during startup.

This feature is the result of several changes to helper functions, especially those contributing to the modus-themes-generate-palette function that Modus derivatives may be relying on.

Thanks to Steven Allen for an intermediate refinement in pull request 194 and to Mike Olson for another relevant tweak in pull request 199:

• https://github.com/protesilaos/modus-themes/pull/194
• https://github.com/protesilaos/modus-themes/pull/199

Steven’s contribution no longer exists in the code base due to other changes I made, but was still useful at the time.

Both changes are small, meaning that their authors do not need to assign copyright to the Free Software Foundation.

Also thanks to Jacod “Jake” Gordon for reminding me to apply one of the new functions to the org-habit faces. This was done in issue 197: https://github.com/protesilaos/modus-themes/issues/197.

The underline for widget fields has the correct colour

Relevant faces use the palette entry for border (invoke the command modus-themes-preview-colors or modus-themes-preview-colors-current to view the entries in a theme’s palette).

A popular package that makes use of widget.el widgets is notmuch.

Thanks to ukiran03 for the contribution, which was done in pull request 193: https://github.com/protesilaos/modus-themes/pull/193. The change is small, meaning that ukiran03 does not need to assign copyright to the Free Software Foundation.

A palette can now have a bg-popup entry

This gives users and derivative themes the option to pick a suitable value for popup interfaces, such as those of the company and corfu packages.

Thanks to aikrahguzar for making this suggestion in issue 70 of my ef-themes repository (the ef-themes are built on top of the modus-themes since Modus version 5.0.0, Ef version 2.0.0): https://github.com/protesilaos/ef-themes/issues/70.

Support for faces or packages

• lin by Protesilaos.
• pulsar by Protesilaos.
• institution-calendar by Protesilaos.
• markdown-ts-mode by Rahul Martim Juliato and Stéphane Marks.
• trust-manager by Eshel Yaron.
• typst-ts-mode by Ziqi Yang. Thanks to Pranshu Sharma for suggesting its inclusion in issue 208: https://github.com/protesilaos/modus-themes/issues/208.
• new elfeed faces since the maintenance of the project was assumed by Daniel Mendler, Karthik Chikmagalur, and Ihor Radchenko. To this end, thanks to Steven Allen for pull request 217 that added the elfeed-show-* faces: https://github.com/protesilaos/modus-themes/pull/217

Internal refinements to the modus-themes-with-colors macro

It now correctly handles the order of default palette colours and user-defined palette overrides. Thanks to JD Smith for the contribution in pull request 191: https://github.com/protesilaos/modus-themes/pull/191.

The change is small, meaning that JD does not need to assign copyright to the Free Software Foundation.

The multiple-cursors are fine even when a bar is used

When the cursor-type is configured to be a bar, the fake cursors produced by the multiple-cursors package will still look right. Thanks to Elias Gabriel Perez for the change to the mc/cursor-bar-face in pull request 213: https://github.com/protesilaos/modus-themes/pull/213.

The blink-matching-paren-offscreen is the same as show-paren-match

This is for thematic consistency. Thanks to Troy Brown for suggesting this change in issue 209: https://github.com/protesilaos/modus-themes/issues/209.

Get vc-annotate look right

The built-in vc-annotate command relies on a user option to read color values. We cannot handle this nicely at the theme level. Users need to write their own configuration like this:

(defun my-modus-vc-annotate (&rest _)
  (modus-themes-with-colors
    (setq vc-annotate-background-mode nil)
    (setq vc-annotate-very-old-color fg-dim)
    (setq vc-annotate-color-map
          `(( 20. . ,red)
            ( 40. . ,red-cooler)
            ( 60. . ,red-warmer)
            ( 80. . ,yellow-warmer)
            (100. . ,yellow)
            (120. . ,yellow-cooler)
            (140. . ,green-warmer)
            (160. . ,green)
            (180. . ,green-cooler)
            (200. . ,cyan-cooler)
            (220. . ,cyan-warmer)
            (240. . ,cyan)
            (260. . ,blue-warmer)
            (280. . ,blue)
            (300. . ,blue-cooler)
            (320. . ,blue-intense)
            (340. . ,magenta-cooler)
            (360. . ,fg-dim)))))

(with-eval-after-load 'vc-annotate
  (my-modus-vc-annotate)
  (add-hook 'enable-theme-functions #'my-modus-vc-annotate))

[ The above code is relevant as of this writing. Though remember that I do not keep older publications up-to-date. The only source of truth is the manual of the Modus themes. ]

Two old user options are no longer needed

The user options modus-themes-completions and modus-themes-prompts are obsolete. They used to be relevant before the introduction of palette overrides.

Rewrote large parts of the manual

I did it for clarity, but also to remove notes that were specific to older versions of Emacs.

Many new ERT tests for the project

I have written many tests. They do not cover every single function, though the plan is to do that eventually. These tests are important to ensure that Modus is a solid platform for making derivative themes.

Much of this was done live: https://protesilaos.com/codelog/2026-04-10-emacs-spontaneous-live-modus-themes/.

Thanks to Benjamin Kästner for a couple of tweaks to a relevant macro in the tests’ file. This was done in pull request 212, with further changes by me: https://github.com/protesilaos/modus-themes/pull/212.

Links to projects related to Modus

In the README.md I now mention projects that are related to the Modus themes, such as derivative Emacs themes, but also ports for other editors.

There is also a link to my modus-themes-exporter package, which I developed during a live stream:

• https://github.com/protesilaos/modus-themes-exporter
• https://protesilaos.com/codelog/2026-04-13-emacs-live-develop-modus-themes-exporter-package/

Git commits

git shortlog 5.2.0..5.3.0 --summary --numbered
    123	Protesilaos
     2	Benjamin Kästner
     2	Steven Allen
     1	Elias Gabriel Perez
     1	JD Smith
     1	Mike Olson
     1	ukiran03

The ef-themes are a collection of light and dark themes for GNU Emacs that provide colourful (“pretty”) yet legible options for users who want something with a bit more flair than the modus-themes (also designed by me).

• Package name (GNU ELPA): ef-themes
• Official manual: https://protesilaos.com/emacs/ef-themes
• Change log: https://protesilaos.com/emacs/ef-themes-changelog
• Sample pictures: https://protesilaos.com/emacs/ef-themes-pictures
• Git repositories:
  • GitHub: https://github.com/protesilaos/ef-themes
  • GitLab: https://gitlab.com/protesilaos/ef-themes
• Backronym: Eclectic Fashion in Themes Hides Exaggerated Markings, Embellishments, and Sparkles.

Below are the release notes.

Version 2.2.0 on 2026-06-21

This version contains two new themes and several stylistic refinements to existing items in the collection.

Enjoy ef-arcadia and ef-atlantis themes

ef-arcadia is a light theme with a green, humid feel. ef-atlantis is a dark theme with aquatic colours.

Improved style for company and corfu popups

I have revised the colour that each theme applies to the popup background. It should now be more consistent with all other elements on display.

Thanks to aikrahguzar for suggesting a review in issue 70: https://github.com/protesilaos/ef-themes/issues/70.

The current line highlight for completions is easier to spot

This is the background of the selected candidate in the minibuffer while using the vertico package (among other similar interfaces). The colours I am now using are more consistent with their context and also work better as part of a popup completion interface, as noted above.

Palette refinements for several themes

I have made subtle changes to a few colour values. These are fine details. The overarching goal is to be consistent throughout.

Rahul M. Juliato has an informative post on what’s coming in Emacs 31. Juliato doesn’t mind living on the edge and has been tracking and using Emacs from the Master and emacs-31 branches. He says he likes to know “what’s in the box” and the way to learn what’s coming is to is to live in it. That’s a little too exciting for me and perhaps for you but Juliato’s post gives us a view of what to expect.

The list is a long one and his post reflects that. It’s a lengthy post but it does a good job of describing what to expect. The thing he’s happiest about is that with this release tree-sitter “just works”. Now installing new grammars is pretty much automatic and there are grammars for more languages.

For those of you who have to—or for some reason, choose to—use Markdown instead of Org mode, the new markdown-ts-mode will be a welcome addition. The new mode has an Org mode feel so Org users will feel comfortable using it.

For those of you who like the completion system making your mind up for you, there are many enhancements to eager completion. That definitely not something I would want; I hate having the system change what I’m typing without my asking for it.

There are several other changes. Check out Juliato’s post for the details. It looks to be a nice release with plenty of improvements. People like Juliato help the development process by thoroughly testing new features for bugs and for suggested improvements.

The minions are insisting that I let you know that you can and should view Juliato’s post in light mode by flipping the switch at the top of the page. Sorry for the boring announcement but none of us wants to deal with disgruntled minions.

Most of us learn Emacs one motion at a time – C-f for a character, M-f for a word, C-n for a line. Useful, but those commands don’t know anything about the structure of your code. Emacs has a whole other family of commands that operate on balanced expressions and definitions instead, and once they become muscle memory they’re hard to give up.

Lisp hackers know these commands intimately – they’re the foundation paredit builds on. What’s less appreciated is that they work in plenty of other languages too. I’ve been leaning on them heavily while building neocaml, my tree-sitter package for OCaml programming, so I’ll use OCaml for the examples here. The commands themselves are general, though, and most of what follows applies to any structure-aware major mode.

Sexps and defuns

Two terms show up everywhere in this corner of Emacs, and both are inherited from its Lisp roots:

• A sexp (“symbolic expression”) is a balanced expression: a literal, an identifier, a parenthesized group, a list, a function application – whatever the major mode considers one self-contained unit.
• A defun is a top-level definition. In Lisp that’s a defun; in OCaml it’s a let binding, a type definition, a module, and so on.

The names are Lispy, but the concepts are general, and that’s the whole point. Every command below is built on one of these two notions.

Moving around

These are the everyday workhorses. In the examples, █ marks point (the cursor).

The interesting thing about forward-sexp is that it moves over the largest expression starting at point. At the head of a function application, that’s the whole call:

let r = █List.map (fun x -> x + 1) numbers

After C-M-f:

let r = List.map (fun x -> x + 1) numbers█

But inside a collection it steps over one element at a time, which is exactly what you want when you’re editing the elements:

let xs = [ █aa; bb; cc ]

let xs = [ aa█; bb; cc ]

down-list and backward-up-list are a great pair for repositioning. The latter is especially nice in a structure-aware mode because it understands keyword-delimited blocks, not just parens. From deep inside a struct body, C-M-u climbs out to the enclosing module:

module M = struct
  let x = 1
  let y = █2
end

module M = █struct
  let x = 1
  let y = 2
end

Editing with structure

Movement is only half the story. The same structural knowledge powers a set of editing commands that are far more precise than their line- or character-based cousins.

kill-sexp removes a whole expression without you having to hunt for where it ends:

let xs = █(List.rev ys) @@ tl

let xs = █ @@ tl

transpose-sexps swaps the expressions on either side of point – a one-keystroke way to fix arguments you passed in the wrong order:

let path = Filename.concat dir █file

let path = Filename.concat file dir█

(There’s much more to say about transposition – I covered the whole family in Transpose All The Things.)

delete-pair unwraps a bracketed group: put point on the opening delimiter and it deletes both it and its match.

let area = pi *. █(r *. r)

let area = pi *. █r *. r

delete-pair has a subtle dependency on structure that I ran into head-on while working on neocaml – it relies on the mode’s notion of a sexp to find the matching delimiter. I wrote that adventure up separately in Removing Paired Delimiters in Emacs.

Finally, raise-sexp replaces the enclosing expression with the sub-expression at point. It’s the fastest way I know to strip a wrapper – here, dropping a Some around a call:

let result = process (Some █(find_opt key tbl))

let result = process █(find_opt key tbl)

One caveat: raise-sexp needs something to raise into. Invoke it at the top level of a binding, where nothing surrounds the expression, and it’ll complain about unbalanced parentheses. Reach for it inside a call, a list, or a parenthesized expression.

The same key, different behavior

Here’s the part that trips people up: these commands behave differently from one major mode to the next, because each mode gets to define what “an expression” or “a definition” actually means. They do it through a few buffer-local hooks – chiefly forward-sexp-function (which backs C-M-f/C-M-b and everything built on them, including kill-sexp, transpose-sexps, and delete-pair) and beginning-of-defun-function / end-of-defun-function for defun motion. What plugs into those hooks has changed a lot over the years.

The classic backing: syntax tables and regexps

For most of Emacs’s history, structural commands rested on the syntax table – the per-mode table that classifies each character as an open or close delimiter, a string quote, a word or symbol constituent, and so on. scan-sexps and scan-lists walk the buffer counting delimiters according to that table, and that’s what forward-sexp falls back on when a mode sets nothing special. It’s wonderfully cheap and works in any buffer, even plain text – but it’s purely lexical. It counts brackets and respects quoting, yet has no idea what a function or a block actually is. That’s why vanilla backward-up-list can’t climb out of a begin ... end or OCaml struct ... end block: those aren’t bracket characters, so as far as the syntax table is concerned they don’t exist.

Modes that wanted more had two classic options:

• SMIE (the Simple Minded Indentation Engine). Modes like ruby-mode and octave-mode feed SMIE a small operator-precedence grammar, and smie-setup points forward-sexp-function at smie-forward-sexp-command. Suddenly C-M-f understands keyword-delimited blocks like if ... end, not just parens.
• Regexps for definitions. A beginning-of-defun-function that scans for a header pattern, and an imenu-generic-expression for the imenu index. Quick to write, but heuristic – easily fooled by code inside strings and comments, or by unconventional formatting.

The tree-sitter backing: a real parse tree

Tree-sitter modes answer the same questions from an actual concrete syntax tree. forward-sexp-function becomes treesit-forward-sexp; on Emacs 30+, a mode declares named “things” – sexp, list, sentence, defun, text – via treesit-thing-settings, and the navigation commands consult them. Defun motion goes through treesit-beginning-of-defun (driven by treesit-defun-type-regexp), and imenu through treesit-simple-imenu-settings.

Because it’s the real grammar rather than a delimiter count, it’s accurate exactly where the lexical approach has to guess. That’s why, earlier, C-M-f could treat the whole List.map ... application as one node, and C-M-u could climb out of a paren-less struct block – and why a stray brace inside a string never throws it off. The price of admission is a compiled grammar and a reasonably recent Emacs.¹

This layering is also why a command like delete-pair can quietly misbehave: it leans on the mode’s forward-sexp-function to find the matching delimiter, so if that disagrees with the buffer’s syntax table you get surprising deletions. Getting these foundations right is a big part of what makes a structure-aware major mode feel solid.

What about paredit?

As mentioned in the beginning of this articles, all of this probably reminds (some of) you of paredit – and it should. paredit takes the same structural ideas and turns them up to eleven, adding slurping, barfing, splicing, and the famous guarantee that your parens always stay balanced. The built-in commands here are the humbler, mode-agnostic ancestors of those ideas.

For non-Lisp languages there are spiritual successors built on tree-sitter. Combobulate is the most ambitious – a full structural editing and navigation package for tree-sitter modes, with drag, splice, and “move by sibling” commands. puni takes a different tack, offering paredit-style soft deletion that works across many languages by leaning on forward-sexp-function. (If you do mix paredit with other tools, mind the keybindings – I wrote about some common clashes in Paredit Keybinding Conflicts.)

More than movement and editing

Once a mode knows how to find sexps and defuns, a surprising number of other features come along for the ride – all powered by the same structural framework:

• narrow-to-defun (C-x n d) – narrow the buffer to just the current definition. Wonderful for focusing on one function at a time, and it uses the exact same defun detection as C-M-a/C-M-e.
• which-function-mode – show the name of the definition point is in, in the mode line. It needs the mode to know where definitions begin and end.
• imenu – jump to a definition by name. Same structural underpinning.
• Folding – outline-minor-mode, hs-minor-mode, and the tree-sitter outline support on Emacs 30+ all fold along structural boundaries.
• Expanding the region – repeatedly hitting C-M-SPC grows the selection by sexp, and packages like expreg generalize that to grow by structural node.

Wrapping up

The C-M--prefixed commands are some of the best returns on investment in all of Emacs. They’re not Lisp-only, they’re not tree-sitter-only, and they quietly get smarter as major modes teach Emacs about their syntax. Learn the handful in the tables above – C-M-f/C-M-b, C-M-u/C-M-d, C-M-SPC, C-M-k, C-M-a/C-M-e – and you’ll feel the difference in every language you touch.

And if a couple of these (delete-pair, raise-sexp) feel essential but lack default bindings, give them keys in your major mode of choice. Your future self, mid-refactor, will thank you.

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