Planet Emacslife

Flymake has been quietly sitting in my config for years doing exactly what it says on the tin, squiggly lines under things that are wrong, and I mostly left it alone. But recently I noticed I was doing the same little dance over and over: spot a warning, squint at the modeline counter, run `M-x flymake-show-buffer-diagnostics`, scroll through the list to find the thing I was actually looking at, then flip back. Two windows, zero connection between them.

So I wired it up properly, and while I was in there I gave it a set of keybindings that feel right to my muscle memory.

The obvious bindings for stepping through errors are `M-n` and `M-p`, and most people using flymake bind exactly those. The problem is that in my config `M-n` and `M-p` are already taken, they step through simply-annotate annotations (which is itself a very handy thing and I am not giving it up!). So I shifted a key up and went with the shifted variants: `M-N` for next, `M-P` for previous, and `M-M` to toggle the diagnostics buffer.

 (setq flymake-show-diagnostics-at-end-of-line nil)
 (with-eval-after-load 'flymake
 (define-key flymake-mode-map (kbd "M-N") #'flymake-goto-next-error)
 (define-key flymake-mode-map (kbd "M-P") #'flymake-goto-prev-error))

With M-M I wanted it to be a bit smarter than just “open the buffer”. If it is already visible I want it gone, if it is not I want it up. The standard toggle pattern:

 (defun my/flymake--diag-buffer ()
 "Return the visible flymake diagnostics buffer, or nil."
 (seq-some (lambda (b)
 (and (with-current-buffer b
 (derived-mode-p 'flymake-diagnostics-buffer-mode))
 (get-buffer-window b)
 b))
 (buffer-list)))

 (defun my/flymake-toggle-diagnostics ()
 "Toggle the flymake diagnostics buffer."
 (interactive)
 (let ((buf (my/flymake--diag-buffer)))
 (if buf
 (quit-window nil (get-buffer-window buf))
 (flymake-show-buffer-diagnostics)
 (my/flymake-sync-diagnostics))))

Now the interesting bit. What I really wanted was a follow mode, something like how the compilation buffer tracks position or how Occur highlights the current hit. When my point lands on an error in the source buffer, the corresponding row in the diagnostics buffer should light up. That way the diagnostics window becomes a live index of where I am rather than a static dump and think in general this is how a lot of other IDEs work.

I tried the lazy route first, turning on hl-line-mode in the diagnostics buffer and calling hl-line-highlight from a post-command-hook in the source buffer. The line lit up once and then refused to move. Nothing I did would shift it. This is because hl-line-highlight is really only designed to be driven from the window whose line is being highlighted, and I was firing it from afar.

Ok, so why not just manage my own overlay:

 (defvar my/flymake--sync-overlay nil
 "Overlay used to highlight the current entry in the diagnostics buffer.")

 (defun my/flymake-sync-diagnostics ()
 "Highlight the diagnostics buffer entry matching the error at point."
 (when-let* ((buf (my/flymake--diag-buffer))
 (win (get-buffer-window buf))
 (diag (or (car (flymake-diagnostics (point)))
 (car (flymake-diagnostics (line-beginning-position)
 (line-end-position))))))
 (with-current-buffer buf
 (save-excursion
 (goto-char (point-min))
 (let ((found nil))
 (while (and (not found) (not (eobp)))
 (let ((id (tabulated-list-get-id)))
 (if (and (listp id) (eq (plist-get id :diagnostic) diag))
 (setq found (point))
 (forward-line 1))))
 (when found
 (unless (overlayp my/flymake--sync-overlay)
 (setq my/flymake--sync-overlay (make-overlay 1 1))
 (overlay-put my/flymake--sync-overlay 'face 'highlight)
 (overlay-put my/flymake--sync-overlay 'priority 100))
 (move-overlay my/flymake--sync-overlay
 found
 (min (point-max) (1+ (line-end-position)))
 buf)
 (set-window-point win found)))))))

My first pass at the walk through the tabulated list did not work. I was comparing (tabulated-list-get-id) directly against the diagnostic returned by flymake-diagnostics using eq, and it was always false, which meant found stayed nil forever and the overlay never moved. A dive into flymake.el revealed why. Each row in the diagnostics buffer stores its ID as a plist, not as the diagnostic itself:

 (list :diagnostic diag
:line line
:severity ...)

So I need to pluck out :diagnostic before comparing. Obvious in hindsight, as these things always are. With plist-get in place the comparison lines up and the overlay moves exactly where I want it, tracking every navigation command.

The fallback lookup using line-beginning-position and line-end-position is there because flymake-diagnostics (point) only returns something if point is strictly inside the diagnostic span. When I land between errors or on the same line as an error but a few columns off, I still want the diagnostics buffer to track, so I widen the search to the whole line.

Finally, wrap the hook in a minor mode so I can toggle it per buffer and enable it automatically whenever flymake comes up:

 (define-minor-mode my/flymake-follow-mode
 "Sync the diagnostics buffer to the error at point."
 :lighter nil
 (if my/flymake-follow-mode
 (add-hook 'post-command-hook #'my/flymake-sync-diagnostics nil t)
 (remove-hook 'post-command-hook #'my/flymake-sync-diagnostics t)))

 (add-hook 'flymake-mode-hook #'my/flymake-follow-mode)
 (define-key flymake-mode-map (kbd "M-M") #'my/flymake-toggle-diagnostics)

The end result is nice. M-M pops the diagnostics buffer, M-N and M-P walk through the errors, and as I navigate the source the matching row in the diagnostics buffer highlights in step with me. If I close the buffer with another M-M everything goes quiet, and I can still step through with M-N/M-P on their own.

Three little keybindings and twenty lines of elisp, but they turn flymake from a static reporter into something that actually feels connected to where I am in the buffer.

A recent Mastodon post showing the days until the next U.S. election got me to wonder, “how can I compute that in Emacs?” Turns out, this is trivial with the Org mode function org-time-stamp-to-now doing the timestamp computation for you.

We can wrap org-time-stamp-to-now in an internal function cc/--days-until that generates a formatted string of the days until a target date.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

(defun cc/--days-until (target &optional template)
  "Formatted string of days until TARGET.

- TARGET: date string that conforms to `parse-time-string'.
- TEMPLATE : format string that includes ‘%d’ specifier.

If TEMPLATE is nil, then a predefined format string will be
used."
  (let* ((template (if template
                       template
                     (concat "%d days until " target)))
         (days (org-time-stamp-to-now target))
         (msg (format template days)))
    msg))

From there we can then start defining commands that use cc/--days-until. The command cc/days-until shown below will prompt you with a date picker to enter a date. Note that you can enter a date value (e.g. “Dec 25, 2026”) in the mini-buffer prompt for org-read-date.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

(defun cc/days-until (arg)
  "Prompt user for date and show days until in the mini-buffer.

Use `org-read-date' to compute days until to display in the mini-buffer.

If prefix ARG is non-nil, then the computed result is stored in the
 `kill-ring'."
  (interactive "P")
  (let* ((target (org-read-date))
         (msg (cc/--days-until target)))
    (if arg
        (kill-new msg))
    (message msg)))

Going back to the original motivator for this post, here’s an implementation of days until the next two major U.S. election dates with the command cc/days-until-voting.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

(defun cc/days-until-voting (arg)
  "Days until U.S. elections in 2026 and 2028.

If prefix ARG is non-nil, then the computed result is stored in the
 `kill-ring'."
  (interactive "P")
  (let* ((midterms (cc/--days-until "2026-11-03" "%d days until 2026 midterms"))
         (election (cc/--days-until "2028-11-07" "%d days until 2028 presidential election"))
         (msg (format "%s, %s" midterms election)))
    (if arg
        (kill-new msg))
    (message msg)))

The result of M-x cc/days-until-voting as of 8 April 2026 is:

209 days until 2026 midterms, 944 days until 2028 presidential election

It’s so human to want to know how long it’s going to take. Feel free to build your own countdown clocks using the code above. May your journey to whatever you plan be a happy one!

I wondered yesterday:

...those question headers are displaying differently, with the background colour no longer spanning the width of the window. I'd like to understand why.

Turns out it was pretty straightforward:

diff --git a/quiz.el b/quiz.el
index 2dbe45d..c1ba255 100644
--- a/quiz.el
+++ b/quiz.el
@@ -40,7 +40,8 @@
 (defface quiz-question-number-face
   '((t :height 1.3
        :background "black"
-       :foreground "white"))
+       :foreground "white"
+       :extend t))
   "Face for the question number."
   :group 'quiz)

and so v1.7 has happened.

It looks like, perhaps, at some point in the past, :extend was t by default, but it no longer is? Either way, explicitly setting it to t has done the trick.

Floofcode over that the Emacs subreddit asks a question that resonates with me. He notes that he often has a repetitive task and wonders whether it would be worthwhile writing some Elisp to automate it. Usually, he has to repeat the task several times before he gets fed up and fixes it for good. He wonders how other people deal with this. Do they have to repeat the task a certain number of times before automating it or is the criterion more subjective.

I can relate. This happens to me all the time. I keep doing the same task over and over until one day I realize that I’m being stupid and spend a few minutes dashing off a bit of Elisp that solves the problem once and for all. Every time, I tell myself, “Well, I won’t that mistake again. Next time I’m going to get this type of task automated right away.” Of course, the next time the same thing happens.

As to floofcode’s question, I would guess that it depends on the person. For me, it’s a subjective matter. The amount of time I’ll spend repeating the same boring task over and over varies but it always ends in a fit of anger when I ask myself why I’m still doing things manually. The thing is, when I’m repeatedly doing the task manually, I’m not wondering whether I should automate it. That happens at the end when I realize I’ve been stupid.

I guess the answer is something of the sort that after you’ve repeated the task twice, just automate it. Sure sometimes you’ll lose and waste time but in my experience it will most often be a win. I wish I could learn this.

Today's Emacs Lisp package tidy-up is of a package I first wrote a couple of employers ago. While working on code I often found myself viewing FASTA files in an Emacs buffer and so I thought it would be fun to use this as a reason to knock up a simple mode for highlighting them.

fasta.el was the result.

While I doubt it was or is of much use to others, it helped me better understand simple font-locking in Emacs Lisp, and also made some buffers look a little less boring when I was messing with test data.

As for this update: it's the usual stuff of cleaning up deprecated uses of setf, mostly.

If bioinformatics-related Emacs Lisp code written by a non-bioinformatician is your thing, you might also find 2bit.el of interest too. Much like fasta.el it too probably doesn't have a practical use, but it sure was fun to write and taught me a few things along the way; it also sort of goes hand-in-hand with fasta.el too.

Conventional file managers have conditioned me to expect that a single left-button mouse click (<mouse-1>) will select a file (or directory) and double-click will open it. This is not the default behavior of Dired, where a single click is an open action. I find this far too twitchy for my taste.

This post shows how to make Dired mouse interaction align with a conventional file manager where:

• Single-click on a file or directory will move the point to it, making it the implicit target for any subsequent Dired command.

• Left double-click on file or directory will open it.

• Selecting multiple files is emulated using Dired marking, in this case using the binding M-<mouse-1> to toggle marking a file.

The first two points above can be addressed with the global variable mouse-1-click-follows-link. Dired uses this variable to control its mouse behavior, but we don’t want to change it everywhere, just for Dired buffers. This can be implemented by setting mouse-1-click-follows-link locally as a hook to dired-mode-hook:

1
2
3
4

(add-hook
 'dired-mode-hook
 (lambda ()
   (setq-local mouse-1-click-follows-link 'double)))

To address multiple file selection, we can define a function cc/dired-mouse-toggle-mark and bind it to M-<mouse-1>.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

(defun cc/dired-mouse-toggle-mark ()
  "Toggle mark of a Dired item via mouse."
  (interactive)
  (unless (use-region-p)
    (mouse-set-point last-input-event)
    (if (char-equal (char-after (line-beginning-position)) dired-marker-char)
        (call-interactively #'dired-unmark)
      (call-interactively #'dired-mark))))

(keymap-set dired-mode-map "M-<mouse-1>" #'cc/dired-mouse-toggle-mark)

Coupled with Anju support for a Dired specific context menu and many basic file manager operations can be done in Dired via mouse with minimal fuss.

The other day, I wrote about repeat mode. My take was that it was a way repeating certain commands without having to retype their, possibly, complex prefixes. All of that is true but as Karthik informed me in a comment, there is much, much more to repeat mode than simply repeating commands.

It is a way, he says, of grouping a set of related commands together into a sort of mode. Thus, there is more to Ctrl+x } than simply repeating the enlarge window command. Once you type Ctrl+x you can type any of {, }, ^, v to resize the window in any direction. The Ctrl+x enables a keymap with those four single keys to resize the current window, defining, in effect, a “resize window mode”.

Four years ago, Karthik wrote a long post that explains all this and, at least on an intuitive level, how it works. My first thought was to add an update to my post that pointed to Karthik’s and I did that but then I thought that his post was so good that I should devote a new post to it so that anyone who missed it the first time would see it.

Repeat mode really is an excellent facility—Karthik says it’s a cornerstone of his Emacs usage—and every Emacser should be familiar with it. If nothing else, it’s worth enabling repeat mode so that you can use the built in repeat maps. You can see what they are by running the command describe-repeat-maps.

A quick little refresh of one of my old packages, this time quiz.el. This is a nice little distraction when you're working in Emacs, letting you spin up a quick trivia quiz in a buffer.

It's backed by the Open Trivia Database, so there's a good few subjects, questions, and levels of difficulty to play with.

The only changes I've made to it in this release are the usual clean-ups of the deprecated uses of setf, plus I've added q as a binding to the quiz window to quickly quit the quiz.

I might have to come back and revisit it soon, as it looks like the default face choices could probably do with a rethink, and I can see at the moment that the attempt at a window-wide "header" for each question isn't working any longer. For comparison, here's how the package looked when running back when I first wrote it back in 2017:

Leaving aside the fact that I was still running a very light Emacs then, those question headers are displaying differently, with the background colour no longer spanning the width of the window. I'd like to understand why.

Good artists borrow, great artists steal.

– Pablo Picasso

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

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

Performance Tweaks

Disable Bidirectional Text Scanning (Doom Emacs)

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

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

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

Skip Fontification During Input (Doom Emacs)

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

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

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

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

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

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

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

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

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

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

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

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

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

Kill Ring (Emacs’s Clipboard History) and Clipboard

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

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

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

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

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

No Duplicates in the Kill Ring (Doom, Prot)

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

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

Persist the Kill Ring Across Sessions (Doom, Prot)

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

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

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

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

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

Editing

Auto-Chmod Scripts on Save (Multiple Configs)

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

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

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

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

Sane Syntax in re-builder (Multiple Configs)

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

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

(setq reb-re-syntax 'string)

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

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

Prevent ffap from Pinging Hostnames (Centaur Emacs)

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

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

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

Windows

Proportional Window Resizing (Purcell, Prot)

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

(setq window-combination-resize t)

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

Reversible C-x 1 (Purcell)

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

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

(winner-mode +1)

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

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

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

Misc

Faster Mark Popping (Purcell, Centaur, Prot)

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

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

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

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

Recenter After save-place Restores Position (Doom Emacs)

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

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

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

Auto-Select Help Windows (Prot)

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

(setq help-window-select t)

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

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

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

While I have been doing a lot of hacking on blogmore.el, I haven't forgotten my plan to revisit and refresh some of my older personal packages. This evening I've paid some attention to expando.el.

This started life a long time ago, as part of my grab-bag of handy functions that got carried around and copied from machine to machine, until I did a big tidy-up of everything back in 2017 and turned various things into packages that I managed via a self-hosted (well, GitHub pages hosted) package index.

It's a pretty simple but very useful bit of code that lets me quickly macroexpand a sexp at point and pretty print it into a display window. I've often found it indispensable when it came to writing my own macros.

This release simply adds a lexical-binding header to the file, and also adds a q key binding to the resulting view window so that it can be quickly and easily closed.

Also, as with all my other personal packages, I've swapped away from using delpa to simply using :vc to pull it in.

(use-package expando
  :vc (:url "https://github.com/davep/expando.el" :rev :newest)
  :bind
  ("C-c e" . expando-macro))

Or perhaps I should say...

(progn
  (use-package-vc-install
   '(expando (:url "https://github.com/davep/expando.el") nil) nil)
  (defvar use-package--warning69
    #'(lambda (keyword err)
        (let
            ((msg
              (format "%s/%s: %s" 'expando keyword
                      (error-message-string err))))
          (display-warning 'use-package msg :error))))
  (condition-case err
      (progn
        (if (fboundp 'expando-macro) nil
          (autoload #'expando-macro "expando" nil t))
        (let*
            ((name "C-c e") (key [3 101])
             (kmap
              (or (if (and nil (symbolp nil)) (symbol-value nil) nil)
                  global-map))
             (kdesc
              (cons (if (stringp name) name (key-description name))
                    (if (symbolp nil) nil 'nil)))
             (binding (lookup-key kmap key)))
          (require 'bind-key)
          (let
              ((entry (assoc kdesc personal-keybindings))
               (details
                (list #'expando-macro (if (numberp binding) nil binding))))
            (if entry (setcdr entry details)
              (add-to-list 'personal-keybindings (cons kdesc details))))
          (define-key kmap key #'expando-macro)))
    ((debug error) (funcall use-package--warning69 :catch err))))

Despite having bumped it from 2.x to 3.x yesterday, I'm calling v4.0 on blogmore.el today. There's a good reason for this though. While tinkering with some of the configuration yesterday, and also answering a configuration question last night, I realised that it made sense to make some of the internals into public utility functions.

Now, sure, Emacs Lisp doesn't really have internals in the private function sense, but I've always liked the approach that a package-- prefix communicates "internal, might go away" vs package- which tells me "this is a stable part of the API of this package". With this in mind I've always tried to write my code using this convention. I did this with blogmore.el too and a lot of the code had the blogmore-- prefix.

There's plenty of code in there that someone might want to make use of, if they wanted to add their own commands, or do fun things with the configuration. So with this in mind I've "promoted" a bunch of code to being "public" and, in that case, I feel this deserves another major version bump¹.

Things that are now part of the "public" interface include:

• blogmore-clean-time-string
• blogmore-get-frontmatter
• blogmore-remove-frontmatter
• blogmore-set-frontmatter
• blogmore-slug
• blogmore-toggle-frontmatter
• blogmore-with-post

Each one is documented via its docstring (just a quick Ctrl+h f function-name RET away) and hopefully is pretty self-explanatory.

blogmore-with-post is especially handy as it provides a quick and easy way of pulling information from a post file. So something like this:

(blogmore-with-post "~/write/davep.github.com/content/posts/2026/04/2026-04-05-blogmore-el-v3-1.md"
  (list
   (blogmore-get-frontmatter "title")
   (blogmore-get-frontmatter "date")))

resulting in:

("blogmore.el v3.1" "2026-04-05 20:04:44+0100")

Meaning that this snippet from yesterday's post:

(with-temp-buffer
  (insert-file-contents-literally file)
  (parse-iso8601-time-string
   (blogmore--clean-time-string (blogmore--get-frontmatter-property "date"))))

becomes:

(blogmore-with-post file
  (parse-iso8601-time-string
   (blogmore-clean-time-string (blogmore-get-frontmatter "date"))))

Not massively different, but it reads better and now all the calls are to the "public API" of the package.

Not all the changes are "promoted internals". I've also added a blogmore-remove-tag command (and also added it to the transient menu).

I've also changed the way that blogmore-add-tag works so that, now, if it's called from the transient, it immediately goes back to the tag input prompt, allowing for another tag to be immediately selected (you can quit out of this with Ctrl+g). Removal of a tag works in a similar way, making things a lot quicker.

I've also added some extra tests too, which makes it even easier for me to make future changes with confidence. The more I work with it the more I appreciate that ERT is available.

I know it’s scary, but sometimes you have to delete files, and once they’re gone—they’re gone. I guess that was why GUI systems invented the trash folder. The trash is a safe place to store files you want to delete, just in case you made a mistake.

In the UNIXy and Emacs worlds, once you delete that file, it’s gone, so you better have your story straight.

rm file.txt
rm -rf directory/

rm -rf /*

The post The Emacs Way: Deleting Files appeared first on Chris Maiorana.

View in the Internet Archive, watch or comment on YouTube, or email me.

Chapters:

• 00:41:21 epwgraph
• 00:54:56 learning languages

Thanks for your patience with the audio issues! At some point, I need to work out the contention between all the different processes that I want to be listening to the audio from my mic. =)

In this livestream, I categorize Emacs News for 2026-04-06, show epwgraph for managing Pipewire connections from Emacs, and share some of my language learning workflows.

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

Bozhidar Batsov has a post that mentions how M-x shows a lot of commands many of which make no sense in the current context. This has never bothered me because after inputting a few (fuzzy) letters, the display converges on the command I’m looking for. Others, are not so sanguine and find the long list annoying.

It turns out that there’s an easy fix for this: read-extended-command-predicate. As of Emacs 28, You can set this variable to one of 3 values—or nil​—to control the filtering of commands in the candidate list. These are:

command-completion-default-include-p

Exclude on those commands tagged for a different mode.

command-completion-using-modes-and-keymaps-p

Include only commands tagged for the current buffer and those commands that have a keybinding active in the current buffer.

command-completion-using-modes-p

Show only commands tagged for the current mode.

The first option is the most conservative and general and is what Batsov recommends for everyday use.

Batsov also explains how functions can declare what mode or modes they’re appropriate for. That’s simply a matter of listing them in the interactive declaration. There are a lot more details in Batsov’s post so be sure to take a look. The read-extended-command-predicate mechanism is similar to the execute-extended-command-for-buffer mechanism that I wrote about previously.

As I said, the long list doesn’t bother me but if it annoys you, this may be the answer.

Update [2026-04-07 Tue 12:05]: prefix → predicate

Way back in 2013 I wrote about the deprecation of flet and how noflet could fill the gap. Thirteen years later, it’s probably time for a proper overview of what replaced flet in cl-lib and when to use each option.

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

A Bit of History

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

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

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

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

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

The Three Replacements

cl-flet: Local Functions (No Recursion)

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

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

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

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

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

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

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

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

cl-labels: Local Functions (With Recursion)

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

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

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

Mutual recursion works too:

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

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

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

cl-letf: Temporary Global Override

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

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

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

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

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

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

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

Quick Reference

In other words:

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

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

There's a lot of buzz around the remote code execution thing that involves Git, but it seems to be more of a Git issue than an Emacs one. This might be a workaround if you want, and in the meantime, don't check out git repositories you don't trust. There's no page for the Emacs Carnival for April yet, but you can start thinking about the theme of "newbies/starter kits" already, and I'm sure Cena or someone will round things up afterwards. Enjoy!

• Workaround for the Git-related security issue that lots of people are talking about (@stackeffect@social.tchncs.de)
• Upcoming events (iCal file, Org):
  • Emacs.si (in person): Emacs.si meetup #4 2026 (v #živo) https://dogodki.kompot.si/events/c4ee8c26-c668-491e-91b3-b466578b83e2 Mon Apr 6 1900 CET
  • Emacs Paris: S: Emacs workshop in Paris (online) https://emacs-doctor.com/ Tue Apr 7 0830 America/Vancouver - 1030 America/Chicago - 1130 America/Toronto - 1530 Etc/GMT - 1730 Europe/Berlin - 2100 Asia/Kolkata - 2330 Asia/Singapore
  • OrgMeetup (virtual) https://orgmode.org/worg/orgmeetup.html Wed Apr 8 0900 America/Vancouver - 1100 America/Chicago - 1200 America/Toronto - 1600 Etc/GMT - 1800 Europe/Berlin - 2130 Asia/Kolkata – Thu Apr 9 0000 Asia/Singapore
  • Atelier Emacs Montpellier (in person) https://lebib.org/date/atelier-emacs Fri Apr 10 1800 Europe/Paris
  • London Emacs (in person): Emacs London meetup https://www.meetup.com/london-emacs-hacking/events/313909207/ Tue Apr 14 1800 Europe/London
  • Emacs Berlin: In-Person-Only Emacs-Berlin Stammtisch https://emacs-berlin.org/ Tue Apr 14 1900 Europe/Berlin
  • M-x Research: TBA https://m-x-research.github.io/ Wed Apr 15 0800 America/Vancouver - 1000 America/Chicago - 1100 America/Toronto - 1500 Etc/GMT - 1700 Europe/Berlin - 2030 Asia/Kolkata - 2300 Asia/Singapore
  • Protesilaos Stavrou: Emacs live stream with Sacha Chua on 2026-04-16 17:30 Europe/Athens
• Emacs configuration:
  • Announcing Anju (Reddit) - mouse interactions for modeline, context menu, and main menu
  • Emacs Redux: Repeat Mode: Stop Repeating Yourself (Irreal)
  • backpack 0.4.0 - adds self-documenting inventory browser (Reddit)
• Emacs Lisp:
  • Almighty Lisp: Lisp & Emacs Essentials - almightylisp.com (HN)
  • Dave Pearson: nukneval.el v1.3 unload and re-evaluate
  • Creating an Emacs Package from Concept to MELPA (Part 7) (57:13)
  • How to run a function when my buffer selection changes? - updated with window-state-change-hook
  • Yay Emacs live: Reorganizing my Emacs configuration so that my defuns are tangled to separate files (01:48:56)
  • Sacha Chua: YE11: Fix find-function for Emacs Lisp from org-babel or scratch (YouTube, 08:19)
• Appearance:
  • New package: outline-stars.el (Reddit)
  • occult.el - collapse buffer regions into single-line summaries (Reddit)
  • Make the left margin shine!
  • Senka07/yotsuba-emacs-theme · GitHub (Reddit)
• Navigation:
  • Tip about using other-window-prefix C-x 4 4
  • Tip about using windmove
• Writing:
  • Curtis McHale: Check Spelling in Emacs (YouTube 06:38)
  • Dave Pearson: blogmore.el v3.1
• Denote:
  • Protesilaos Stavrou: Emacs: new sequence scheme for the ‘denote-sequence’ package
• Org Mode:
  • [EMACS LAB] #3: Introduction to Org Mode (01:57:55)
  • aravindps/org-gtd: Things 3 style GTD for Emacs — org-mode agenda views, ⌘ keybindings, context tags. Works with Doom and vanilla Emacs. · GitHub (r/emacs, r/orgmode)
  • [BLOG] #27 bbb:OrgMeetup on Wed, February 11, 19:00 UTC+3 - Ihor Radchenko (@yantar92@fosstodon.org) notes
  • Import, export, and integration:
    • lopeztel/ox-dnd-html: Emacs export org files to D&D themed html · GitHub (Reddit)
    • Adding org-protocol support (Reddit)
    • Sacha Chua: Extract PDF highlights into an Org file with Python (YouTube 04:27)
    • James Endres Howell: My first advice! (in Emacs Lisp) - specifying HTML boilerplace for org-static-blog
    • RSS feeds for your org-mode website (@bgtdsword@toot.io)
    • Org-mode - Various font sizes LaTeX (04:14)
  • Org development:
    • ol: Allow targets as search option in id: links
    • org-babel: Fix and extend `org-babel-update-intermediate' variable
    • Query before attempting to overwrite existing attachment/DnD/yank file
    • Merge branch 'bugfix'
    • etc/ORG-NEWS: Remove announcement about bugfix
• Completion:
  • Emacs Redux: Declutter M-x with read-extended-command-predicate
  • [RELEASE] let-completion v0.2.0: full overhaul of Elisp completion - 46 binding forms, function argument candidates, expandable registry, fully customizable two-column annotations (Reddit)
  • rougier/nano-vertico: Emacs / nano + vertico · GitHub (Reddit)
• Coding:
  • Mike Olson - eglot-python-preset and eglot-typescript-preset: Now on MELPA (Reddit)
  • Function to make eglot add IWYU headers without doing an autocomplete in the buffer
  • Dave Pearson: make-phony.el v1.3 for Makefiles
  • Daskeladden/shipit: Code review in Emacs · GitHub (Reddit)
• Shells:
  • Ghostel - terminal emulator powered by libghostty (Reddit)
• Mail, news, and chat:
  • Thanos Apollo: Bringing jabber.el Back From the Dead (@debacle@framapiaf.org)
  • mastodon.el 2.0.14 - jump to quoting toot, bugfixes, annotations (@mousebot@todon.nl)
• Multimedia:
  • Using Android TTS in Emacs
• Fun:
  • Anybody interested in writing SDL games in Emacs Lisp?
    • Emacs + SDL: unblocking the unblockable (emacs-devel)
  • Dave Pearson: eg.el v1.2 Norton Guide?, thinks.el v1.13 thought bubbles, binclock.el v1.12 binary clock, obfusurl.el v2.2 obfuscating URLs
• AI:
  • I run my company from Emacs (HN)
  • Crafting an AI-Driven Workflow System - System Crafters Live! (01:52:03)
  • Will using Emacs give you an edge in the AI-era? (45:08, Reddit, Reddit)
  • The Agent-Native Editor Was Invented in 1976
• Community:
  • Emacs ATX Meetup. April 2026. - YouTube (2:04:58)
  • Sacha Chua: #YayEmacs 10: Emacs coaching with Prot: Emacs workflows and streaming (YouTube 01:06:30)
    • Sacha Chua: Thinking about Emacs coaching goals with Prot
    • Protesilaos Stavrou: Emacs coaching with Sacha Chua
  • Emacs Carnival March 2026: Mistakes and Misconceptions
    • The Comfort Trap (@len@toot.si)
    • Christian Tietze: Emacs Mistakes and Misconceptions That Held Me Back in 2019
    • Einar Mostad: Emacs mistakes and misconceptions
  • Prot Asks: Hjalmar about Emacs for music, the joy of art, and Internet sociability (02:04:24)
  • Alvaro Ramirez: …and then there were three (expect delays) (Irreal)
  • A Cult AI Computer’s Boom and Bust - YouTube (Irreal)
• Other:
  • Emacs Docs (Reddit, @maxxcan@mastodon.social)
  • Thanos Apollo: Gnosis 0.10: Import Anki, Merge Everything Into One
  • doom emacs install on manjaro linux walkthrough on hyper-v vm (17:29)
• Emacs development:
  • On keybindings and the slow erosion of help's utility - long discussion
  • New option vc-dir-auto-hide-up-to-date
  • * lisp/vc/diff-mode.el (diff-mode-read-only-map): Bind 'v'.
  • * etc/NEWS: Announce Org update.
  • ; Fix documentation of last change
  • Recursively check dependencies for package compatibility
  • Inform macOS Accessibility Zoom of cursor position (bug#80624)
  • New macro setopt-local and function set-local (bug#80709)
  • Add xref-edit-mode (bug#80616)
• New packages:
  • compilation-history: Track compilation history in SQLite (MELPA)
  • corg: Header completion for org-mode (MELPA)
  • evim: Evil Visual Multi - Multiple cursors for evil-mode (MELPA)
  • ghostel: Terminal emulator powered by libghostty (MELPA)
  • meshmonitor-chat: Chat client for MeshMonitor (Meshtastic) (MELPA)
  • occult: Collapse and reveal buffer regions (MELPA)
  • org-dt: Dynamic templating loader (MELPA)
  • org-grimoire: Emacs-native static site generator (MELPA)
  • org-invox: Invoice management for contractors using Org mode (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.

This is the third article in a small series inspired by my recent cleanup of Prelude and my personal Emacs configuration, following the ones on repeat-mode and read-extended-command-predicate. I’ve been going through the Emacs 28-30 changelogs for features I had ignored so far, and this one from Emacs 30 immediately caught my eye.

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

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

(minibuffer-regexp-mode 1)

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

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

How Does This Compare to re-builder?

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

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

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

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

[ The stream will be recorded. You can watch it later. ]

Tonight I will work on my denote package. There is a feature branch I implemented this morning and am now ready to continue refining the code. The immediate goals:

• Update unit tests that are still calling deprecated functions.
• Write new tests, starting with the denote-dired command and all its ancillary functions.
• Review all the commands that filter the query buffers (which are produced by commands such as denote-grep, denote-backlinks, denote-query-contents-link).
• Edit the manual accordingly.

I expect the stream to go on for 2-3 hours, but we will see.

I will keep the chat open in case there are any comments. I am happy to respond to them.

Watch on Internet Archive, watch/comment on YouTube, download captions, or email me

Where can you define an Emacs Lisp function so that you can use find-function to jump to it again later?

• A: In an indirect buffer from Org Mode source block with your favorite eval function like eval-defun (hint)nope

  • C-c ' (org-edit-special) inside the block; execute the defun with C-M-x (eval-defun), C-x C-e (eval-last-sexp), or eval-buffer.

        (defun my-test-1 () (message "Hello"))
    

• B: In an Org Mode file by executing the block with C-c C-c (hint)nope

    (defun my-test-2 () (message "Hello"))
  

• C: In a .el file (hint)yup

  file:///tmp/test-search-function.el : execute the defun with C-M-x (eval-defun), C-x C-e (eval-last-sexp), or eval-buffer

• D: In a scratch buffer, other temporary buffer, or really any buffer thanks to eval-last-sexp (hint)nope

  (defun my-test-4 () (message "Hello"))

Only option C works - it's gotta be in an .el file for find-function to find it. But I love jumping to function definitions using find-function or lispy-goto-symbol (which is bound to M-. if you use lispy and set up lispy-mode) so that I can look at or change how something works. It can be a little frustrating when I try to jump to a definition and it says, "Don't know where blahblahblah is defined." I just defined it five minutes ago! It's there in one of my other buffers, don't make me look for it myself. Probably this will get fixed in Emacs core someday, but no worries, we can work around it today with a little bit of advice.

I did some digging around in the source code. Turns out that symbol-file can't find the function definition in the load-history variable if you're not in a .el file, so find-function-search-for-symbol gets called with nil for the library, which causes the error. (emacs:subr.el)

I wrote some advice that searches in any open emacs-lisp-mode buffers or in a list of other files, like my Emacs configuration. This is how I activate it:

(setq sacha-elisp-find-function-search-extra '("~/sync/emacs/Sacha.org"))
(advice-add 'find-function-search-for-symbol :around #'sacha-elisp-find-function-search-for-symbol)

Now I should be able to jump to all those functions wherever they're defined.

(my-test-1)
(my-test-2)
(my-test-3)
(my-test-4)

Note that by default, M-. in emacs-lisp-mode uses xref-find-definitions, which seems to really want files. I haven't figured out a good workaround for that yet, but lispy-mode makes M-. work and gives me a bunch of other great shortcuts, so I'd recommend checking that out.

Here's the source code for the find function thing:

(defvar sacha-elisp-find-function-search-extra
  nil
  "List of filenames to search for functions.")

;;;###autoload
(defun sacha-elisp-find-function-search-for-symbol (fn symbol type library &rest _)
  "Find SYMBOL with TYPE in Emacs Lisp buffers or `sacha-find-function-search-extra'.
Prioritize buffers that do not have associated files, such as Org Src
buffers or *scratch*. Note that the fallback search uses \"^([^ )]+\" so that
it isn't confused by preceding forms.

If LIBRARY is specified, fall back to FN.

Activate this with:

(advice-add 'find-function-search-for-symbol
 :around #'sacha-org-babel-find-function-search-for-symbol-in-dotemacs)"
  (if (null library)
      ;; Could not find library; search my-dotemacs-file just in case
      (progn
        (while (and (symbolp symbol) (get symbol 'definition-name))
          (setq symbol (get symbol 'definition-name)))
        (catch 'found
          (mapc
           (lambda (buffer-or-file)
             (with-current-buffer (if (bufferp buffer-or-file)
                                      buffer-or-file
                                    (find-file-noselect buffer-or-file))
               (let* ((regexp-symbol
                       (or (and (symbolp symbol)
                                (alist-get type (get symbol 'find-function-type-alist)))
                           (alist-get type find-function-regexp-alist)))
                      (form-matcher-factory
                       (and (functionp (cdr-safe regexp-symbol))
                            (cdr regexp-symbol)))
                      (regexp-symbol (if form-matcher-factory
                                         (car regexp-symbol)
                                       regexp-symbol))

                      (case-fold-search)
                      (regexp (if (functionp regexp-symbol) regexp-symbol
                                (format (symbol-value regexp-symbol)
                                        ;; Entry for ` (backquote) macro in loaddefs.el,
                                        ;; (defalias (quote \`)..., has a \ but
                                        ;; (symbol-name symbol) doesn't.  Add an
                                        ;; optional \ to catch this.
                                        (concat "\\\\?"
                                                (regexp-quote (symbol-name symbol)))))))
                 (save-restriction
                   (widen)
                   (with-syntax-table emacs-lisp-mode-syntax-table
                     (goto-char (point-min))
                     (if (if (functionp regexp)
                             (funcall regexp symbol)
                           (or (re-search-forward regexp nil t)
                               ;; `regexp' matches definitions using known forms like
                               ;; `defun', or `defvar'.  But some functions/variables
                               ;; are defined using special macros (or functions), so
                               ;; if `regexp' can't find the definition, we look for
                               ;; something of the form "(SOMETHING <symbol> ...)".
                               ;; This fails to distinguish function definitions from
                               ;; variable declarations (or even uses thereof), but is
                               ;; a good pragmatic fallback.
                               (re-search-forward
                                (concat "^([^ )]+" find-function-space-re "['(]?"
                                        (regexp-quote (symbol-name symbol))
                                        "\\_>")
                                nil t)))
                         (progn
                           (beginning-of-line)
                           (throw 'found
                                   (cons (current-buffer) (point))))
                       (when-let* ((find-expanded
                                    (when (trusted-content-p)
                                      (find-function--search-by-expanding-macros
                                       (current-buffer) symbol type
                                       form-matcher-factory))))
                         (throw 'found
                                 (cons (current-buffer)
                                       find-expanded)))))))))
           (delq nil
                 (append
                  (sort
                   (match-buffers '(derived-mode . emacs-lisp-mode))
                   :key (lambda (o) (or (buffer-file-name o) "")))
                  sacha-elisp-find-function-search-extra)))))
    (funcall fn symbol type library)))

I even figured out how to write tests for it:

(ert-deftest sacha-elisp--find-function-search-for-symbol--in-buffer ()
  (let ((sym (make-temp-name "--test-fn"))
        buffer)
    (unwind-protect
        (with-temp-buffer
          (emacs-lisp-mode)
          (insert (format ";; Comment\n(defun %s () (message \"Hello\"))" sym))
          (eval-last-sexp nil)
          (setq buffer (current-buffer))
          (with-temp-buffer
            (let ((pos (sacha-elisp-find-function-search-for-symbol nil (intern sym) nil nil)))
              (should (equal (car pos) buffer))
              (should (equal (cdr pos) 12)))))
      (fmakunbound (intern sym)))))

(ert-deftest sacha-elisp--find-function-search-for-symbol--in-file ()
  (let* ((sym (make-temp-name "--test-fn"))
         (temp-file (make-temp-file
                     "test-" nil ".org"
                     (format
                      "#+begin_src emacs-lisp\n;; Comment\n(defun %s () (message \"Hello\"))\n#+end_src"
                      sym)))
         (sacha-elisp-find-function-search-extra (list temp-file))
         buffer)
    (unwind-protect
        (with-temp-buffer
          (let ((pos (sacha-elisp-find-function-search-for-symbol nil (intern sym) nil nil)))
            (should (equal (buffer-file-name (car pos)) temp-file))
            (should (equal (cdr pos) 35))))
      (delete-file temp-file))))

You can comment on Mastodon or e-mail me at sacha@sachachua.com.

When I first started writing blogmore.el it was just going to be a handful of commands that let me spin up a new blog post, and insert the odd link here and there when needed. Initially it only handled a single blog, and everything it did was based around how I lay my personal blog out, and was also very much geared to how I'd made BlogMore work.

But then I wanted to use it to edit both my personal blog and my photoblog. So then I had to add support for configuring different ways of laying out posts for different blogs, etc.

Still, it was mostly written as a personal tool that worked for my stuff. I tried to make it so that it was easy enough to configure (and let's be fair: it's for Emacs and written in Emacs Lisp, it's kind of hard to not be very configurable if you're happy to get your hands dirty with some coding), but there were still some parts of it that weren't as easy to change as I'd have liked.

Also, when I'd originally added the multi-blog configuration, I'd chosen a format for the list of blogs that was an assoc-list of pure lists wrapped by a cl-defstruct to make for easier access. It worked well but was very positional in its nature.

So when the request came in to be able to have better control over the name of the file when starting a new post, which meant I was going to need to rearrange the structure again, it was time to try and do something about it.

Which is how I'm now on v3.1 (yes, there was a v3.0 but I quickly found something in that that needed fixing¹). It's a major version bump because I've totally changed how the blogmore-blogs variable holds the data.

From now on I'm using EIEIO to create a class that holds all of the data for a given blog. This, I believe, makes the code easier to read and should also make it more resilient to the addition of any new properties. Also thanks to how such classes can work with the customize system the customize experience remains pretty much the same too.

Personally I don't use the customize UI, instead I declare everything via use-package. As of the time of writing my declaration for blogmore looks like this:

(use-package blogmore
  :ensure t
  :defer t
  :vc (:url "https://github.com/davep/blogmore.el" :rev :newest)
  :init
  (add-hook 'blogmore-new-post-hook #'end-it)
  (blogmore-work-on "blog.davep.org")
  :custom
  (blogmore-blogs
   (list
    (blogmore-blog
     :title "blog.davep.org"
     :posts-directory "~/write/davep.github.com/content/posts/"
     :post-subdirectory-function (lambda () (format-time-string "%Y/%m/")))
    (blogmore-blog
     :title "seen-by.davep.dev"
     :posts-directory "~/write/seen-by/content/posts/")))
  :bind
  ("<f12> b" . blogmore))

There's a bunch of other changes and tweaks under the hood in this release too. All of these should come together to make blogmore.el a little more configurable than it was before. I think, to get the best out of it, anyone wanting to configure it "just so" for their purposes will still have to do a little bit of work, which makes me want to spend some time soon writing some proper documentation, complete with examples of how you might achieve different things.

One big change I've made under the hood is to the code that is used when you insert a link to a post (blogmore-link-post). When this runs it lets me pick a file in your filesystem that is a post from my currently-active blog. Once it has the filename it needs to turn it into a root-relative link. So this:

~/write/davep.github.com/content/posts/2026/04/01/2026-04-01-foo.md

needs to become:

/2026/04/01/foo.html

Until now I just did some regexp faffing that took the 2026-04-01- at the start of the filename and swapped each - for /. Nice and easy. Simple enough to code up and get things working a few weeks back. Not at all flexible.

So as a proof-of-concept of how sophisticated someone could get with configuring this I've changed blogmore-default-post-maker-function from this:

(defcustom blogmore-default-post-maker-function
  (lambda (file)
    (replace-regexp-in-string
     (rx bos (group (+ digit)) "-" (group (+ digit)) "-" (group (+ digit)) "-")
     "\\1/\\2/\\3/"
     (file-name-base (file-name-sans-extension file))))
  "Default function to generate a link for a blog post from its filename."
  :type 'function
  :group 'blogmore)

and turned it into this:

(defcustom blogmore-default-post-maker-function
  (lambda (file)
    (format
     "%s/%s"
     (format-time-string
      "%Y/%m/%d"
      (with-temp-buffer
        (insert-file-contents-literally file)
        (parse-iso8601-time-string
         (blogmore--clean-time-string (blogmore--get-frontmatter-property "date")))))
     (replace-regexp-in-string
      (rx bol (= 4 digit) "-" (= 2 digit) "-" (= 2 digit) "-")
      ""
      (file-name-base file))))
  "Default function to generate a link for a blog post from its filename."
  :type 'function
  :group 'blogmore)

So whereas before I was simply messing with the file's name, now I'm loading the date frontmatter from the chosen file and using that to create the date portion of the path in the URL that I use on my blog. The benefit here is that someone might want to keep the date portion of the path in the URL, but never want it as part of the Markdown source file's name, and so this change means they can call the file anything they want; it doesn't look at that but instead uses the actual date from the post's frontmatter.

I think this nicely demonstrates that, especially thanks to how powerful Emacs and Emacs Lisp are, it's fairly easy to make blogmore.el work just the way you want. I think I've provided almost all the hooks necessary to configure it all sorts of ways, but if you do happen to use it and run into something I might have missed, let me know.

As many you know, I was a Vim user for a couple of decades before I found the one true editor. One of the things I miss from Vim is the easy to use repeat command. If you’re in command mode and perform some command, you can repeat that command by simply pressing .. Sadly, Emacs doesn’t have anything similar. There are a couple of repeat commands: one for simple commands and another for “complex” commands but I was never able to internalize them.

Happily, there is repeat mode that allows you to repeat a command by omitting the prefix and pressing the last key. For example, if you want to repeat the command to enlarge a window horizontally (Ctrl+x }) you can simply repeat the } as many times as needed.

As Bozhidar Batsov explains, this doesn’t work with every key sequence but it is easy to add the functionality to multikey sequences. The TL;DR is that you have to provide a special keymap that maps the last key(s) to their action(s). Batsov has a worked example to show you how to do it. It’s not very hard. But, it turns out, it can be even easier. Omar Antolín explains in a comment that there is also a macro, defvar-keymap that abstracts all the boilerplate away and makes it really easy to define and install a new repeat map.

Repeat mode still isn’t as nice as Vim’s repeat but it can reduce the friction of repeating certain commands. Take a look at Batsov’s post for the details.

Update [2026-04-06 Mon 11:05]:

Karthik Chikmagalur has an excellent write-up on repeat mode that shows it’s useful for much more than simply repeating a command. See his comment below.

It was really fun to learn about advising Lisp functions to extend functionality in Emacs. My first use case was to run a custom function every time a certain function in Bastian Bechtold’s org-static-blog is called. Of course, I could customize that function directly in my own fork, but Lisp advice allows you to modify functions without clobbering them directly. This approach has aesthetic and practical advantages.

But I’ve struggled to understand the concepts and implementation of advice. Today I posted to Mastodon about how excited I was to get my first working use, and Philip asked me to share the code.

My problem was specifying HTML boilerplate that org-static-blog puts in each post when it publishes all the static files, using string variables like org-static-blog-page-header. These strings are complex enough that I put them in their own files, like these lines in the #header.html file that specifies the page metadata:

<script type="module" src="https://esm.sh/emfed@"></script>
<meta name="author" content="James Endres Howell">
<meta name="referrer" content="no-referrer">
<link href="static/style.css" rel="stylesheet" type="text/css" />
<meta name="fediverse:creator" content="@jameshowell@fediscience.org">
<meta property="og:image" 
      content="https://jamesendreshowell.com/static/education-of-james-endres-howell.png">

First, Stack Exchange and I solved the problem of reading a file into a string. (?! How is this not a native function!? Maybe I missed something obvious.)

(defun jeh/file-to-string (file)
  "Return a string that is the contents of FILE."
  (with-temp-buffer
    (insert-file-contents file)
    (buffer-string)))

And then, for example:

(setq org-static-blog-page-header
      (jeh/file-to-string 
       (expand-file-name "#header.html" org-static-blog-template-blocks-directory)))

The unscratched itch was that every time I edit one of these files, I always, but always, forget to update the appropriate variable with the contents of the file! And so publishing doesn’t reflect the changes, and I get confused, and then I remember….

Here is the solution:

(defun jeh/org-static-blog-read-templates (&rest ignore)
  "Set org-static-blog-page -header, -preamble, -postamble variables
by reading files from `org-static-blog-template-blocks-directory'."
  (setq org-static-blog-page-header             ;;; HTML to put in the <head> of each page.
        (jeh/file-to-string 
         (expand-file-name "#header.html" org-static-blog-template-blocks-directory)))
  (setq org-static-blog-page-preamble           ;;; HTML to put before the content of each page.
        (jeh/file-to-string 
         (expand-file-name "#preamble.html" org-static-blog-template-blocks-directory)))
  (setq org-static-blog-page-postamble          ;;; HTML to put after the content of each page.
        (format (jeh/file-to-string 
                 (expand-file-name "#postamble.html" org-static-blog-template-blocks-directory))
                (number-to-string emacs-major-version)
                (number-to-string emacs-minor-version)
                org-version)))

;;; Re-read the template files before publishing,
;;; so changes will be included in output.
(advice-add #'org-static-blog-publish :before #'jeh/org-static-blog-read-templates)

The function jeh/org-static-blog-read-templates sets the variables org-static-blog-page-header, org-static-blog-page-preamble, and org-static-blog-page-postamble to the contents of the appropriate files. Making that function a hook to the function which generates all the static pages, org-static-blog-publish, solves my problem. But there is no hook for it! I had a suspicion that add-advice could give me the same result, and—I hope you’re sitting down—I read the fine manual and learned that the syntax of the last line accomplishes that very thing.

Of course, advice-add (and related functions) can do much more! Maybe as I learn I will be able to customize functions from other packages without just banging on a local fork.

There's no question that the experiment that is BlogMore has resulted in me blogging more. Although my previous setup wasn't exactly all friction, there's something about "owning" most of the tools and really knowing how they work, and being able to quickly modify them so they work "just so", that makes me more inclined to quickly write something up.

I can see this if I look at the numbers in the archive for this blog. In March alone I wrote 43 posts; that's more than I wrote in any whole year, other than 2023. While I suspect this will start to calm down as work on BlogMore and blogmore.el settles down, I sense I'll be writing a bit more often for some time to come.

Because of this I decided to do a little bit of housekeeping on the posts directory in the blog's source repository. Originally I had the Markdown source for every post all in one directory. Then last month I broke those down by year. Then earlier today, seeing how this year is going, I decided to break 2026 down by month.

Then I realised I had a problem in blogmore.el. It assumed that the Markdown file for a new post (blogmore-new) would always be created in a subdirectory named after the year, underneath the defined posts directory. Until today that was the case¹, but now I wanted it to work differently.

So this is why I'm making a second release in one day: I added the ability to configure the subdirectory where a new post is created. I've changed the default now so that it assumes the user wants the subdirectory to be YYYY/MM/DD (because more granular feels like the right default). In my case I don't want that, I just want YYYY/MM, but now I can configure that. The value that is set is a function that returns the name of the subdirectory, so in the case of my blog I have it as:

(lambda () (format-time-string "%Y/%m/"))

On the other hand, for my photoblog I want the full date as a subdirectory so I can leave it as the default. The whole use-package for blogmore now looks like:

(use-package blogmore
  :ensure t
  :defer t
  :vc (:url "https://github.com/davep/blogmore.el" :rev :newest)
  :init
  (add-hook 'blogmore-new-post-hook #'end-it)
  (blogmore-work-on "blog.davep.org")
  :custom
  (blogmore-blogs
   '(("blog.davep.org"
      ;; Root directory for posts.
      "~/write/davep.github.com/content/posts/"
      ;; Subdirectory for new posts, relative to the root.
      (lambda () (format-time-string "%Y/%m/")))
     ("seen-by.davep.dev"
      ;; Root directory for posts.
      "~/write/seen-by/content/posts/")))
  :bind
  ("<f12> b" . blogmore))

Technically this is a breaking change because it bumps the meaning of each "position" in the values within blogmore-blogs. However, in my case, because I was only ever defining the blog name and the top-level directory for the posts (both mandatory), this didn't break anything; I also strongly suspect nobody else is using this so I very much doubt I'm messing with someone else's setup². If I have I apologise; do let me know.

Anyway, all of this goes to explain why the heck I made two releases of the same package back to back in the same day. This is what happens when my namesake is having fun outside and so I just want to sit on the sofa, hack on some code, and watch the chaos in the garden.

Irreal readers can’t help but know who Álvaro Ramírez is, if for no other reason that I’m always blathering on about his Journelly app that is my most used and useful iOS app. But of course, Ramírez has many other excellent apps, many of which are Emacs packages. In particular, there is his dwim-shell-command that allows you to automate shell commands—particularly those with complex invocations—from the comfort of Emacs. There’s also his take on music players, an uniform AI access app, and a lot more besides.

You can check out his blog posts or take a look at his iOS/macOS/Emacs applications. He’s been an independent developer for some time but now he’s taken on a new role: fatherhood. He’s now the proud dad of a new son. He tells us that his output may slow down a bit because, after all, he has to start working on his son’s init.el.

Like most people, I imagine, I first ran into transient when first using magit. I took to it pretty quickly and it's always made sense to me as a user interface. But... I've never used it for any code I've ever written.

I think, incorrectly, I'd half assumed it was going to be some faff to set up, and of course for a good while it wasn't part of Emacs anyway. Given this, I'd always had it filed under the heading "that's so neat I'll give it a go one day but not at the moment".

Meanwhile... ever since I did the last big revamp of my Emacs configuration, I found myself leaning into a command binding approach that does the whole prefix-letter-letter thing. For reasons I can't actually remember I fell into the habit of using F12¹ as my chosen prefix key. As such, over the past 10 or so years (since I greatly overhauled my Emacs setup), I've got into setting up bindings for commands that follow this prefix convention.

So when I created blogmore.el I set up the commands following this pattern.

(use-package blogmore
  :ensure t
  :defer t
  :vc (:url "https://github.com/davep/blogmore.el" :rev :newest)
  :init
  (add-hook 'blogmore-new-post-hook #'end-it)
  (blogmore-work-on "blog.davep.org")
  :custom
  (blogmore-blogs
   '(("blog.davep.org" "~/write/davep.github.com/content/posts/")
     ("seen-by.davep.dev" "~/write/seen-by/content/posts/")))
  :bind
  ("<f12> b b" . blogmore-work-on)
  ("<f12> b n" . blogmore-new)
  ("<f12> b e" . blogmore-edit)
  ("<f12> b d" . blogmore-toggle-draft)
  ("<f12> b s c" . blogmore-set-category)
  ("<f12> b a t" . blogmore-add-tag)
  ("<f12> b u d" . blogmore-update-date)
  ("<f12> b u m" . blogmore-update-modified)
  ("<f12> b l p" . blogmore-link-post)
  ("<f12> b l c" . blogmore-link-category)
  ("<f12> b l t" . blogmore-link-tag))

It works well, it makes it nice and easy to remember the bindings, etc. Nobody needs me to sell them on the merits of this approach.

Then I got to thinking last night: why am I setting up all those bindings when I could probably do it all via a transient? So that was the moment to actually RTFM and get it going. The first version was incredibly quick to get up and running and I was kicking myself that I'd taken so long to actually look at the package properly.

This morning I've worked on it a little more and the final form is still pretty straightforward.

(transient-define-prefix blogmore ()
  "Show a transient for BlogMore commands."
  [:description
   (lambda ()
     (format "BlogMore: %s\n"
             (if (blogmore--chosen-blog-sans-error)
                 (blogmore--blog-title)
               "No blog selected")))
   ["Blog"
    ("b"  "Select blog" blogmore-work-on)]
   ["Post"
    ("n" "New post" blogmore-new :inapt-if-not blogmore--chosen-blog-sans-error)
    ("e" "Edit post" blogmore-edit :inapt-if-not blogmore--chosen-blog-sans-error)
    ("d" "Toggle draft status" blogmore-toggle-draft :inapt-if-not blogmore--blog-post-p)
    ("c" "Set post category" blogmore-set-category :inapt-if-not blogmore--blog-post-p)
    ("t" "Add tag" blogmore-add-tag :inapt-if-not blogmore--blog-post-p)
    ("u d" "Update date" blogmore-update-date :inapt-if-not blogmore--blog-post-p)
    ("u m" "Update modified date" blogmore-update-modified :inapt-if-not blogmore--blog-post-p)]
   ["Links"
    ("l c" "Link to a category" blogmore-link-category :inapt-if-not blogmore--blog-post-p)
    ("l p" "Link to a post" blogmore-link-post :inapt-if-not blogmore--blog-post-p)
    ("l t" "Link to a tag" blogmore-link-tag :inapt-if-not blogmore--blog-post-p)]])

With this in place I can simplify my use-package quite a bit, just binding a single key to run blogmore.

(use-package blogmore
  :ensure t
  :defer t
  :vc (:url "https://github.com/davep/blogmore.el" :rev :newest)
  :init
  (add-hook 'blogmore-new-post-hook #'end-it)
  (blogmore-work-on "blog.davep.org")
  :custom
  (blogmore-blogs
   '(("blog.davep.org" "~/write/davep.github.com/content/posts/")
     ("seen-by.davep.dev" "~/write/seen-by/content/posts/")))
  :bind
  ("<f12> b" . blogmore))

Now, when I'm working on a blog post, I can just hit F12 b and I get a neat menu:

Better still, because of how transient works, I can ensure that only applicable commands are available, while still showing them all. So if I've not even got a blog selected yet:

Or with a blog selected but not actually working on a post yet:

So far I'm really liking this approach, and I'm tempted to lean into transient more with some of my packages now. While on the surface it does seem that it has the downside of the binding choices being dictated by me, the fact is that the commands are all still there and anyone can use their own bindings, or I guess override the transient itself and do their own thing.

This is another article inspired by my recent cleanup of Prelude and my personal Emacs config, following the one on repeat-mode. I’ve been going through the Emacs 28-30 changelogs looking for features I had overlooked, and this small one from Emacs 28 turned out to be a real gem.

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

Emacs 28 added a simple way to fix this:

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

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

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

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

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

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

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

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

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

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

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

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

A Note for Vertico/Orderless Users

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

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

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

I’ve been going through the Emacs 28-30 changelogs recently as part of a big update to Prelude and my personal config, looking for features I never got around to trying. repeat-mode is one I wish I’d adopted sooner.

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

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

(repeat-mode 1)

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

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

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

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

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

Defining Your Own Repeat Maps

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

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

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

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

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

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

Keep hacking!

I realized that one of the mistakes I often make with Emacs is not asking other people for help, so I experimented with a coaching session with Prot. With his permission, here's a recording of our conversation.

View in the Internet Archive, watch/comment on YouTube, download the captions, or e-mail me your thoughts.

You can comment on Mastodon or e-mail me at sacha@sachachua.com.

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

The other day I had a coaching session with Sacha Chua. Sacha asked me if she could record and publish it, to which I agreed. More here: https://sachachua.com/blog/2026/04/yayemacs-10-emacs-coaching-with-prot-packaging-emacs-lisp//.

Our next meeting will be done live on the 16th of April 2026 at 10:30 America/Toronto, 17:30 Europe/Athens time: https://youtube.com/live/djE_pVlgDHg.

I will check with Sacha how she imagines doing this. Though I am the laissez faire type, so will adapt as we go.

[ Note that all my coaching sessions are private: I never share details of my meetings. This is an exception because Sacha asked me about it. ]

jabber.el is an XMPP client for Emacs, originally written in 2003. Development slowed over the years, though contributors kept the package working across Emacs releases.

I took over as maintainer with the goal of modernizing the protocol support.

Now, jabber.el is the most XEP-complete text-based client in existence.

What Changed

For those, like me, who count XEPs like Pokemon:

• OMEMO encryption (XEP-0384) via a C dynamic module wrapping picomemo
• OMEMO media sharing (XEP-0454)
• OpenPGP for XMPP (XEP-0373) using Emacs’ built-in EPG
• Stream Management (XEP-0198) with session resume
• Message Archive Management (XEP-0313)
• Message Carbons (XEP-0280)
• Delivery Receipts (XEP-0184) and Chat Markers (XEP-0333)
• Message Correction (XEP-0308), Replies (XEP-0461), Moderation (XEP-0424/0425)
• Chat State Notifications (XEP-0085)
• Client State Indication (XEP-0352)
• Blocking Command (XEP-0191)
• HTTP File Upload (XEP-0363)
• Direct TLS (XEP-0368) with dual SRV lookup
• Real Time Text (XEP-0301)
• PubSub (XEP-0060)
• Bookmarks (XEP-0402 with XEP-0048 fallback)
• SQLite message storage replacing flat-file history
• MUC Self-Ping (XEP-0410)

Almost caught them all

No other text-based XMPP client has this level of protocol coverage. jabber.el now rivals Dino and Gajim, the major graphical clients.

OMEMO

OMEMO requires a Signal Protocol implementation. That means C.

jabber-omemo-core.c is 763 lines wrapping picomemo through Emacs' dynamic module API. The Elisp layer handles XMPP integration: PubSub bundle publishing, stanza encryption, session persistence in SQLite, and trust management.

It also provides AES-256-GCM for OMEMO media sharing (XEP-0454).

Why Emacs

Emacs is not just the editor I write jabber.el in. It is the runtime, the test harness, and the application.

I develop in the same instance where I chat. Fix a bug, eval changes, and the fix is live in my running session. Seconds, not minutes.

Emacs provides most of what a chat client needs out of the box: SQLite for storage, GnuTLS for encryption, EPG for OpenPGP, EWOC for list display, Transient for menus.

Distribution is through NonGNU ELPA, which handles everything.

jabber.el is just an M-x package-install RET jabber RET away from install.

Why XMPP

XMPP is the only federated, open-standard messaging protocol that works in practice. I use it for all my daily communication. My friends are on WhatsApp, Discord and IRC – gateways bridge these networks transparently.

One client, one interface, every chat network I need.

More on the gateway setup I use in a future post.

What’s Next

• XEP-0444 Message Reactions
• OMEMO 0.8+ (picomemo supports both; the C layer is ready)
• Roster rework – flat, query-based contact list sorted by activity

You can now import Anki decks into gnosis.

The entire Anki ecosystem, thousands of community-maintained decks across every subject, is accessible from Emacs. I can finally keep track of the AnKing deck changes.

If you can’t beat them, import them.

Anki import

gnosis-anki-import reads .apkg files and converts them into gnosis themata. It resolves Anki’s note type templates to extract question/answer pairs, normalizes tags, and strips Anki system tags like marked and leech.

Re-importing the same deck is safe. Each imported note keeps its Anki GUID, so gnosis detects duplicates and skips them. When AnKing pushes an update, I just re-import and only the new notes come in.

Tens of thousands of notes & themata, managed from a text editor. As it should be.

One package, one database

org-gnosis was merged into gnosis. Maintaining two packages with two databases for what is fundamentally one system was, in retrospect, an act of bureaucratic self-harm. Nodes, journal, and themata now share a single gnosis.db. The migration imports existing org-gnosis data automatically.

Export and import

The old org-file export format is gone. Exports are now .gnosis SQLite databases. Importing shows a diff buffer with NEW and CHANGED entries before applying, so you see exactly what will change before committing.

Combined with GUID tracking, this makes gnosis collections maintainable over time rather than one-shot imports. Share a deck with a friend, they modify it, you re-import. No data lost, no duplicates.

Other

• Decks were removed. They were a restriction, not a feature. Existing deck names were converted into tags.
• N+1 queries eliminated throughout the codebase.
• Dashboard rendering is 3-4x faster via a custom gnosis-tl module.
• Review dates stored as integers; due/overdue queries run in SQL.
• Git operations are fully async.
• Saving .org.gpg files no longer triggers redundant decryption.
• Post-failure interval capped at 7 days.
• Interval fuzz prevents review clustering.
• Tag bulk operations: rename, regex rename, merge case duplicates.
• Dropped emacsql for built-in sqlite.

Back when I first really got into writing Emacs Lisp code, one of the first things I got very used to and really fell in love with was being able to eval-last-sexp (C-x C-e) the code I was writing, either to test it right there in the buffer, or to cause it to be bound so I could use it elsewhere. It was so different from any other mode of working I'd used before and it was really addictive as a way of hacking on code.

Also quite quickly I got used to the fact that eval-last-sexp wasn't so helpful with things like a defvar or a defconst, if I was changing them up to try out new ways of doing things with the code I was working on; there I had to remember to get used to using eval-defun (C-M-x). Hardly a great problem, but something to keep in mind¹.

Pretty quickly, as I worked on longer packages, I found myself wanting to, in effect, unload a whole buffer of code and evaluate it again. From this desire came nukneval.el.

The original version of this has been sat around since 2002 or so, perhaps a little earlier, and has served me well every time I've been messing with a new package. While I suspect there is (now, perhaps was then too?) a better way of doing things, the approach used in nukneval helped me learn some things and served me well (and still does). Now it's muscle-memory to run it.

The way it works is quite simple: go to the start of a buffer, read each form, check if the car is of a given list of symbols, decide if it's something I want to unbind, and then pick either makunbound or fmakunbound and use that on the symbol. Finally, once the end of the buffer has been hit: eval-buffer.

I've just released v1.3 as part of my slow wander through my old Emacs Lisp packages, with this release cleaning up a deprecated use of setf to move point, and also rewriting the code so it's a bit cleaner and also gives better feedback.

A wee bit over 5 years back I wrote a tiny package to quickly insert PHONY target markers into a Makefile. While it's far from my most-used package, it's one that gets a call on occasion, so it's one I still carry around in my Emacs configuration.

Given I'm currently engaging in a slow background process of cleaning up some of my Emacs Lisp packages, removing some obsoleted practices, I've given make-phony.el a little bit of attention.

As well as dropping the use of setf to set point to the start of a line, I also tweaked the code a little so that it only inserts a PHONY if there isn't already one there. While that's hardly been a problem for me, it just felt like a neat bit of cleaning up to how it works.

The denote-sequence package is an optional extension to denote that empowers users to write “sequence notes”, else “folgezettel”, in the style of Niklas Luhmann.

Sequence notes are created in relation to other notes, as parent, child, or sibling. denote-sequence communicates such relationships by writing a “sequence” to the file name, in accordance with the Denote file-naming scheme (technically, it uses the optional SIGNATURE component of the file name, which is defined as a free-form field for users to use as they see fit—so this is just one application of it).

The package supported two schemes before

The exact presentation of such sequences is subject to the user option denote-sequence-scheme. The package has hitherto supported two schemes, the numeric and alphanumeric.

In the numeric scheme, each level of depth is delimited by the equals sign. The sequence 1=2=3 thus has three levels of depth. It means “the third child of the second child of the first parent”.

By contrast, the alphanumeric scheme relies on the alternation between numbers and letters to communicate levels of depth. The above example is thus expressed as 1b3.

The new alphanumeric-delimited scheme

Many users have told me that the alphanumeric scheme looks cleaner. Though I think it is hard to read when sequences get really long, like 2a13c6d2a. To this end, the new sequence scheme augments the alphanumeric style with delimiters that are placed after the first level of depth and every third level of depth thereafter. Thus: 2=a13=c6d=2a.

Users may find this easier to work with.

Remember the denote-sequence-convert command

This command has been part of the package since its inception. It can convert from one sequence scheme to the others.

denote-sequence-convert has a “do what I mean behaviour” with regard to which file or files it should operate on:

• When called from inside a file with a Denote sequence, it operates on the current file.

• When called from a Dired buffer, it operates on all the marked files.

• When there are no marked files in the Dired buffer, it operates on the file at point.

The target sequence scheme for the conversion is whatever is assigned to the user option denote-sequence-scheme. If, however, denote-sequence-convert is called with a prefix argument (C-u by default), then it will prompt for the target sequence scheme.

Coming in version 0.3.0

I just merged the code into trunk. Users who are building the package from source can try the new feature right away. Otherwise, it will be available in the next stable version of the package. I hope to have that ready some time in mid-April.

• Package name (GNU ELPA): denote-sequence
• Official manual: https://protesilaos.com/emacs/denote-sequence
• Git repository: https://github.com/protesilaos/denote-sequence
• Backronym: Denote… Sequences Efficiently Queue Unsorted Entries Notwithstanding Curation Efforts.

The other day, my partner and I went into the hospital as two and came out as three. This week, I became a father. From the second I cuddled this little fella, I felt like I'd known him my entire life. I love him so much.

Since going indie dev full-time, I've enjoyed a great degree of flexibility to work on personal projects. This has enabled me to share more via blog posts and YouTube videos, but also dedicate more time to projects like agent-shell. It is now my most popular Emacs package, receiving lots of attention from users (bug reports, pull requests, discussion, etc). If you've been in touch recently and haven't heard from me, now you know why. Fatherhood is new to me. I'll need a little time to adjust while finding my footing.

While my hope is to continue working on my indie projects, sustainability is now… errm, a tad more important. If you get value out of my work, please consider sponsoring. Better yet, if you use my tools at work, consider getting your employer to sponsor me instead. I also run a blogging service and offer a handful of iOS/macOS apps. If you're keen to journal or take quick notes on iOS, Journelly is my take on it. Bonus points for Emacs users, as it saves entries to an org file.

Now, please excuse me while I start crafting my son's first init.el…

ps. This post was stitched up from a handful of seconds here and there, in between all the sleep-deprived but loving activities currently rocking my world.

Following on from yesterday's release, I've bumped blogmore.el to v2.5. The main change to the package is the thing I mentioned yesterday about the toggle of the draft status. The draft toggle yesterday was pretty simple, with it working like:

• If there is no draft frontmatter, draft: true is added
• If there is any draft frontmatter, it is removed

This meant that if you had draft: false set and you went to toggle, it would be removed, which is the same as setting it to draft: false.

Unlikely to generally be an issue, but I also couldn't let that stay like that. It bothered me.

So now it works as you'd expect:

• If there is no draft frontmatter, draft: true is added
• If draft: true is there, it is removed
• If draft: false is there, it is set to draft: true

Much better.

Another change is that I fixed a problem with older supported versions of Emacs. I didn't know this was a problem because I'm running 30.2 everywhere. Meanwhile, thanks to package-lint-current-buffer from package-lint.el, I have:

Package-Requires: ((emacs "29.1"))

in the metadata for the package. Turns out though that sort used to require two parameters (the sequence and the predicate), whereas now it's fine with just one (it will accept just the sequence and will default the predicate). So of course blogmore.el was working fine for me, but would have crashed for someone with an earlier Emacs.

As for how I found this out... well I finally, for the first time ever, dived into using ERT to write some tests. While I've used testing frameworks in other languages, I'd never looked at this with Emacs Lisp. It works a treat and is great to work with; I think I'll be using this a lot more from now on.

Having got tests going I realised I should run them with GitHub actions, which then meant I managed to discover setup-emacs. Having found this the next logical step was to set up a matrix test for all the versions of Emacs I expect blogmore.el to work on. This worked fine, except... it didn't. While the tests worked locally, they were failing for some Emacsen over on GitHub.

And that's how I discovered the issue with sort on versions earlier than the one I'm using locally.

All in all, that was a good little period of hacking. New things discovered, the package improved, and a wider range of support for different versions of Emacs.

Chris Mariana has an interesting post about making Git commit messages with Magit. Well crafted commit messages, he says, can tell a story about your project than can valuable in the future. The secret is in the “well crafted” part.

Rather than a bunch of messages like “Small edits” or “tweaked the foobar”, your commit message should describe what you actually did. Maiorana is a writer and his examples reflect a writing project rather than coding but everything he says applies regardless of what type of files you’re committing. Take a look at his post for examples of both good and bad commit messages.

The other nice thing about his post is that he shows how to use Git reporting to do some rough analysis. Magit, of course, has easy ways of doing this. Again, see Maiorana’s post for the details.

Finally, he offers some suggestions for writing better commit messages. These are aimed more at the story writer than the coder but, again, they can help someone writing code too;

I must admit to being guilty of writing terrible commit messages, especially for my blog posts. I’m very apt to use Maiorana’s example of “minor edit” instead of saying what I actually fixed. Sometimes, it just fixing a typo in which case “fixed typo” is fine but usually it’s something more extensive and a meaningful commit message helps me locate the commit I’m looking for.

I started using Emacs in the spring of 2022. I had been curious about it for a while and watched some videos by Protesilaos Stavrou and David Wilson that made it seem wroth trying. I thought I could try it out for a while to give it a chance and if it did not deliver, I could go back to Vim. At the time, I had been a Vim user for a couple of years and had simplified and improved the efficiency in my computing by using more CLI and TUI programs like NewsBoat (instead of gPodder and Liferea) and Calcurse (instead of Thunderbird Calendar) that I had then configured to use Vim keybindings. I felt that Vim's modal editing, even though I had become quite efficient, was a bit cumbersome even though people on YouTube boasted about how intuitive it felt to them (after "just" years of training their muscle memory), and I had trouble remembering some keybindings in Vim until I put a poster on the wall beneath my external screen with a keyboard and what every key did. I installed Emacs before a trip to Fredrikstad (maybe in the winter vacation or Easter vacation?) and on the ferry between Moss and Horten on my way back, I started working through the Emacs tutorial. Two years earlier, I did the same on the same ferry with the Vim tutor, but unlike the Emacs tutorial, I had to do the Vim tutor many times for the contents to really stick.

Even though I was exposed to the idea of Emacs as a cohesive environment before trying it through videos by Prot and David Wilson, I think a misconception I had early on was that it was a text editor like Vim, but with a bit more extensibility. It is not completely wrong because it is the better of the two/three best text editors in my present opinion, and that joke about it being an OS lacking only a decent text editor is obviously a joke for anyone that has used it for enough time to get to know it. For instance, I soon discovered that Emacs default keybindings made me faster than modal Vim keybindings since there are one or two key presses less for every edit. You don't have to press Esc to get into Normal Mode and you don't have to press i, o, a… to get into Insert Mode in addition to pressing keys for moving around. I had heard tales of awful key chords, but in reality, text editing used a modifier like Ctrl or Alt plus a key to move around, and I could just write to write. It felt a lot more natural and intuitive than Vim to me, even after using Vim for two years. Keybindings were also easier to remember in Emacs since they were mnemonic. (F for forward, b for backward, n for next, p for previous, d for delete, y for yank — and w for kill? Some years later, Mike Zamansky cleared that up in a video where he mentioned w was for whack, which made me laugh.)

Without the experience of a more cohesive workflow within Emacs, it is hard to imagine how useful an Elisp interpreter built around text editing can really be. Not having to bind keys to get your TUI programs to have the same keybindings as your text editor is one efficiency advantage of doing most things inside Emacs over (Neo)Vim + CLI and TUI programs, but the ability to extend or change functionality for anything you do with Elisp through well-documented functions and variables is the real superpower of doing most things within Emacs. People can tell you that, but to understand it, you have to experience it. It is not just a text editor with a scripting language for extensions, it is a programming language environment built around text editing. The use of a Lisp is also a great advantage since it is simple, easy and fast to learn and more efficient to use than other programming languages.

I did not have much time to explore Emacs in the beginning since I taught English while also studying IT, so in the start, I replaced Vim with Emacs as a text editor and kept using the rest of my CLI, TUI and GUI programs as I did before. I configured Emacs with settings from the Emacs from scratch video series by David Wilson. That worked well, and it improved my text editing speed, but I missed out on one of the main advantages of Emacs which is the cohesive work environment without context switching that Prot and David Wilson talked about until I found more time later to look into what else Emacs could do for me. I sort of knew all along that there was more to gain, and I did start to use Elfeed quite early on as a replacement for Newsboat, but otherwise, I kept using Emacs mainly as a text editor. There is nothing wrong with that, but to really gain the advantages of the cohesive work flow you can get by using Emacs, integrating other stuff into Emacs makes sense. Later on when I had more time, I did slowly replace one program at a time with Emacs modes or Emacs packages.

I think one of my main mistakes when learning Emacs was to rely too much on videos, blog articles and searches online instead of reading up more on the built-in documentation. The info reader felt a bit foreign with its somewhat strange keybindings and even though I realised C-h was there with a lot of other functionality as well, I did not really start using C-h k to find out what keybindings did, C-h m to find out what I could do in a mode, C-h v for looking up what a variable is or C-h f to look up functions, until a couple of years later. This was also related to not having much time to invest into learning Emacs in the start since I had started teaching at the vocational IT and Media production study line in the autumn of 2023 while still studying IT which made me extremely busy with making teaching materials since there exists no books for any of my subjects and at the time not much material was available on NDLA, a Norwegian digital learning portal used a lot in upper secondary (= US high) schools. If I had spent less time reading blogs and watching videos, but instead read up on the manuals and started using the built-in documentation more, early on, I think I might have come further faster. On the other hand, the great thing with blog posts and videos is that you get inspired by what and how other people use Emacs. Since configuring Vim is somewhat limited compared to programming Emacs, I was used to find most of the information I needed online and just occasionally dip into :help in Vim. Both the built-in documentation and online content are valuable, but I mainly relied on online content in the start which was a mistake.

I've been trying to find a good workflow for highlighting interesting parts of PDFs, and then getting that into my notes as images and text in Emacs. I think I've finally figured out something that works well for me that feels natural (marking things.

I wanted to read through Prot's Emacs configuration while the kiddo played with her friends at the playground. I saved the web page as a PDF and exported it to Noteful. The PDF has 481 pages. Lots to explore! It was a bit chilly, so I had my gloves on. I used a capacitative stylus in my left hand to scroll the document and an Apple Pencil in my right hand to highlight the parts I wanted to add to my config or explore further.

Back at my computer, I used pip install pymupdf to install the PyMuPDF library. I poked around the PDF in the Python shell to see what it had, and I noticed that the highlights were drawings with fill 0.5. So I wrote this Python script to extract the images and text near that rectangle:

import fitz
import pathlib
import sys
import os

BUFFER = 5

def extract_highlights(filename, output_dir):
    doc = fitz.open(filename)
    s = "* Excerpts\n"
    for page_num, page in enumerate(doc):
        page_width = page.rect.width
        page_text = ""
        for draw_num, d in enumerate(page.get_drawings()):
            if d['fill_opacity'] == 0.5:
               rect = d['rect']
               clip_rect = fitz.Rect(0, rect.y0 - BUFFER, page_width, rect.y1 + BUFFER)
               img = page.get_pixmap(clip=clip_rect)
               img_filename = "page-%03d-%d.png" % (page_num + 1, draw_num + 1)
               img.save(os.path.join(output_dir, img_filename))
               text = page.get_text(clip=clip_rect)
               page_text = (page_text
                            + "[[file:%s]]\n#+begin_quote\n[[pdf:%s::%d][p%d]]: %s\n#+end_quote\n\n"
                            % (img_filename,
                               os.path.join("..", filename),
                               page_num + 1,
                               page_num + 1, text))
        if page_text != "":
            s += "** Page %d\n%s" % (page_num + 1, page_text)
    pathlib.Path(os.path.join(output_dir, "index.org")).write_bytes(s.encode())

if __name__ == '__main__':
    if len(sys.argv) < 3:
        print("Usage: list-highlights.py pdf-filename output-dir")
    else:
        extract_highlights(sys.argv[1], sys.argv[2])

After I opened the resulting index.org file, I used C-u C-u C-c C-x C-v (org-link-preview) to make the images appear inline throughout the whole buffer. There's a little extra text from the PDF extraction, but it's a great starting point for cleaning up or copying. The org-pdftools package lets me link to specific pages in PDFs, neat!

To set up org-pdftools, I used:

(use-package org-pdftools
  :hook (org-mode . org-pdftools-setup-link))

Here's my quick livestream about the script with a slightly older version that had an off-by-one bug in the page numbers and didn't have the fancy PDF links. =)

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

I've just released a little update to blogmore.el, adding blogmore-toggle-draft as a command. This came about in connection with the feature request that resulted in BlogMore v2.7.0 being released.

While I don't personally use draft for my posts, I can see the utility of it and if someone were to happen to use blogmore.el, it could be useful to have this bound to a handy key combination.

As for how it works: that's simple. When run, if there is no draft: frontmatter property, then draft: true is added. If draft: is there it is removed. Yes, it does mean that it will also remove draft: false too but... eh. Okay, fine, I might handle that case as a followup but I couldn't really imagine someone wanting to keep draft: false in the frontmatter.

If a post is ready to go, why bother with a header that means the same thing when it's not there?

Some time in the late 1990s, after I'd been using GNU Emacs for a few years¹, I grabbed a copy of Writing GNU Emacs Extensions. While I'd obviously created and added to and tinkered with my ~/.emacs some, I'd never written any non-trivial code. I feel it was around 1998 or 1999 that I really started to get into trying to write actual extensions, thanks to that book.

I can't remember what the first complete package was. I think it was actually 5x5.el² but it might also have been binclock.el. Honestly, it's so long ago now that I don't have any good recollection and I don't have any record³. All of which is to say, binclock.el is one of my oldest bits of Emacs Lisp code, so it seemed fair that while I'm cleaning things up, I should give it a tidy too.

For anyone curious: it's a very simple binary clock type of thing. It opens a very small window and, depending on your settings, shows the time in various ways, all of which are in some way a binary display.

I can't say I've honestly ever had it running for more than a few moments, as an amusement, but I do remember it being a really helpful body of code to work on to help get familiar with Elisp. So, 27 years on from when I first opened the buffer to create it, it's tweaked and tidied and hopefully ready for another 27.

Would be cool if I'm around long enough to give it yet another tweak then.

This bit of Emacs Lisp absolutely comes from a more innocent time on the Internet. Looking at it, it seems I wrote the first version, at least as a proper package, back in 2001. It's very possible that I carried a non-package version of it around as part of dp-lib.el¹ for some time before, so it might date from the late 1990s. While we weren't absolutely innocent back then, the idea of a slightly-risky-looking URL wasn't quite so bad as it is now.

So obfusurl.el came about from my time on Usenet, where sometimes you'd want to post a URL that would otherwise be a spoiler. This package was my solution to that. It's a simple idea: keep the protocol and domain and so on visible, just hide the remaining part. So rather than post:

https://blog.davep.org/about/

You'd post:

https://blog.davep.org/%61%62%6f%75%74/

I suppose this is still useful today, although I would expect a lot of people to be way less likely to want to attempt that click -- readable domain or not.

But, anyway, the code needed a tidy and cleanup for today's Emacs and Emacs Lisp. So obfusurl.el v2.2 now exists.

Okay, that's it then; this is turning into a thing I think. Second in an occasional series of posts where I tidy up some of my old Emacs packages. This time I dug out eg.el and cleaned up some of the frowned-upon behaviour.

For anyone who doesn't know it: eg.el is one of many Norton Guide readers I've written over the years. This particular one was possibly the most fun as it was the most unlikely one to write and also, I think it's fair to say, my most ambitious one as well. It also holds a special place for me in that the bulk of it was written on trains during multiple trips up to Scotland, before I finally moved here (on the MacBook Air I mentioned the other day).

As I look at it now, I sort of want to give it a proper revisit. I've written more Norton Guide code since (see AgiNG for example) and have learnt better ways to handle certain things, and I also have an even bigger Norton Guide collection to test against. All of this could make for an even better Emacs implementation.

I also suspect that, this time around, I can do a better job of handling the colour and retaining the original Norton Guide reader look and feel. But, for now, the code has been tidied up and should keep working for some time yet.

Following up on Emacs Carnival March 2026: Mistakes and learning to reach out: I want to get better at learning with other people's help, so I'm going to experiment with engaging Prot as an Emacs coach. Our first session is this week. Time to lay the groundwork!

If I meet with Prot twice a month for three months, that's a budget of €60 (~CAD 100), which is a reasonable size for an experiment especially since I still have the budget set aside from the Google Open Source Peer Bonus and lovely folks already donated to cover the costs for EmacsConf. When I schedule something with someone, the accountability makes it easier to get stuff done and out the door. For this, a real person is much better than AI because:

• I get to take advantage of Prot's very large context window, and he knows stuff about the Emacs, the community, and me that I might not remember to mention
• He can ask real questions and prod at things that are unclear or contradictory, unlike the confirmation bias of LLMs
• He might point out things that wouldn't occur to me to ask about
• It triggers my "I promised someone I'd do this" thing
• I get to support an individual worth supporting rather than contributing to the concentration of wealth and information in for-profit entities

My motivations:

• I want to make better use of my focused time during the rest of the schoolyear. For the next three months, my schedule will be fairly predictable and I'll have regular chunks of focused time. Over the past two months, I've averaged around 10 hours of Emacs-related stuff per week (including 1.5 hours or so for Emacs News). I'm currently thinking about language learning and speech input. EmacsConf is on the horizon and will probably ramp up after September, but I can also think ahead of workflow improvements or ways to collaborate with other people. I might put together an Emacs News Highlights presentation. Also, I'm always looking out for ways to build the community.

  Summer break during July and August will shake things up again, but I might be able to find some focused time early morning or evening. I'd like to be in a good position to make the most of those time fragments.

• I want to improve my Emacs Lisp development workflow and learn more about libraries and techniques that might be useful. I'm beginning to have more time to sharpen the saw and I'm curious about all the cool stuff that I missed or skimmed over the past ten years. What are some useful setups for completion, debugging, navigation, etc.?
  • Current: I sporadically use the extra awesomeness in seq, pcase, lispy, erefactor, ert, buttercup, and undercover, but not consistently. I'd like to reduce the friction and make these habitual.
  • Areas of friction / improvement:
    • writing tests, especially for things that are more interactive
    • navigating code that might be scattered in literate config files or in Emacs Lisp files
    • forgetting to restart or to make sure all code is saved; running tests via Emacs batch mode will help, as will package-isolate and restart-emacs
• I want to improve my workflows for writing, making videos, and streaming. If I get better at sharing what I'm working on, I might be able to connect with more people and bounce ideas around. Also, accountability might help me nudge this over the threshold. I probably still need to work in stops and starts, so I want to reduce the friction. I'm curious about other people's workflows for sharing. I like joining meetups, but I tend to share stuff only if no one else has anything planned, because I have my blog and my YouTube channel in case I want to share anything with a wider group of people. I just have to actually post things.

  • Current: ~1.5 Emacs posts a week aside from Emacs News, attending meetups, sporadically adding short video demos to posts

    Average number of Emacs-related posts that aren't Emacs News

    (let* ((start "2026-02-01")
           (end "2026-03-31")
           (posts (my-blog-posts
                   start end
                   (lambda (o)
                     (and (member "emacs" (alist-get 'categories o))
                          (not (member "emacs-news" (alist-get 'categories o)))))))
           (count (length posts)))
      (my-weekly-average count start end))
    

  • Goal: 2-3 non-News posts a week, one video a month, one stream or meetup a month; maybe also beyond looking at the numbers, it might be interesting to build more momentum around a topic, set up trails/navigation, cultivate more of a digital garden
  • Areas of friction / improvement:
    • Resisting "one more tweak"
    • Streaming: Still need to get the hang of talking to myself or having half-conversations with chat: can be worked around by scheduling a session with Prot and opening it to the public
    • Hiding private information or setting up a separate Emacs for demonstration
    • Harvesting videos/clips/notes afterwards
• I want to move more of my configuration into files and libraries that other people can reuse, like sachac/learn-lang and sachac/speech-input. I can also separate the function definitions from the configuration in my code so that people can reuse the functions if they want.
  • Areas of friction / improvement
    • renaming things when I want to move them to a library
    • duplicating small functions (ex: simplify string)
    • figuring out how to make it possible for someone else to start using my stuff

Starting questions for Prot:

• Meta: what are people finding useful for coaching and behaviour change, like learning new keyboard shortcuts or workflows?
• Your literate config exports to individual .el files. I could probably do something similar to separate my functions from my personal config in order to make it easier for people to reuse parts of my config. Is it worth doing so? Do people tell you that they use those private Emacs Lisp files by loading them, or do they mostly rely on your published packages?
• Does the division into multiple .el files work fine if you need to bisect your configuration?
• Do you have some tweaks to make it easier to jump to function definitions considering a literate configuration?
• What's your general process for migrating things from your config to a repository or package?

Could be fun. Let's experiment!

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

Given the recent spate of hacking on some Emacs Lisp, I've got a real taste for hacking on some more. Or, more to the point, revisiting some of the packages I have in Melpa and tidying them up where necessary.

The main thing I'll need to address is cutting back on all my old setf ways. I liked that approach to doing things, it made lots of sense and felt elegant; sadly the Emacs maintainers didn't seem to agree.

So... kicking this off I've released v1.13 of thinks.el. This is a bit of nonsense I wrote back in the days when Usenet was still pretty busy and the place to be (well, okay, back in 2000 when I was still hanging out on Usenet). The package itself lets you quickly and easily...

. o O ( ...write some text and then mark it all and then run a command and )
      ( have it turned into something that looks a little like a thought   )
      ( bubble.                                                            )

It has some variations on how the bubble looks, and also lets you use customize to tweak the characters to use, and also has an "extra silly" mode too.

Updating this wasn't too bad. Mostly just a case of turning some instances of (setf (point) ...) into (goto-char ...), and also modifying one instance of incf to be cl-incf.

Honestly, I don't know how useful this package is to anyone anymore. Most folk don't even know what Usenet is these days, and all the "social" places seem to favour non-monospaced fonts, meaning the bubbles would look pretty terrible anyway.

On the other hand, it seems a shame to not update it, and perhaps someone somewhere still uses it to make some pithy parenthetical remark, possibly about September never ending.

I've bumped blogmore.el to v2.3. The main change in this release, which I've had on my mental to-do list for a couple of days now, revolves around categories, tags and case.

I've got BlogMore set up so that it's pretty relaxed about case when it comes to categories and tags; so when it comes to generated files and URLs everything collapses to lowercase. However, blogmore.el wasn't taking this into account.

While it wasn't a serious issue, it did have the side-effect that, if you had a tag of lisp and a tag of Lisp, both would appear in the list of tags you could complete from. Also, when you went to add a tag to the tags frontmatter (via the blogmore-add-tag command), if you selected Lisp and lisp was already there, you'd end up with both versions after the command finished.

So earlier I changed things up a little; first cleaning up when loading pre-existing values and then ensuring the newly-set tags are deduplicated.

This now means I can edit and update a post even faster, without needing to worry about accidentally duplicating tags. This in turn reduces the friction to writing a post for my blog. That is, after all, the whole point of the name of the package and the blogging tool it's connected to!

Spell checking in Emacs is one of those things that should just work but requires a bit of setup to get right, especially if you want a specific dictionary like Canadian English. This post walks through getting hunspell running in Doom Emacs with the keybindings you need to actually use it.

Installing Hunspell

Doom's spell module supports both aspell and hunspell. After looking around it seemed like hunspell had better dictionary support for non-US English variants, so it was my choice for Canadian spell checking.

Hunspell is available for Ubuntu, Fedora, and macOS via Hombrew. I'm on NixOS so I'd add the two packages I need and then run sudo nixos-rebuild switch to get them installed.

environment.systemPackages = with pkgs; [
  hunspell
  hunspellDicts.en-ca
];

Enabling the Spell Module

Open ~/.config/doom/init.el and find the :checkers section. Enable the spell module with the +flyspell flag:

:checkers
syntax
(spell +flyspell)

The +flyspell flag uses Emacs' built-in flyspell, which works reliably with hunspell. I didn't use the +hunspell flag because after some looking around I'd need to generate a list of words.

Run doom sync and restart Emacs after changing init.el.

Configuring the Dictionary

In ~/.config/doom/config.el, tell Emacs to use hunspell and set your dictionary:

(setq ispell-program-name "hunspell"
      ispell-dictionary "en_CA")

Swap en_CA for en_GB, en_AU, etc. if you need a different variant. The dictionary name needs to match what hunspell has installed — you can check with hunspell -D in a terminal to see available dictionaries.

Reload your config with SPC h r r.

Turning Spell Checking On

Flyspell doesn't run automatically everywhere — Doom enables it in text and org buffers by default, but you can toggle it manually with:

When active, misspelled words are underlined.

Navigating and Fixing Mistakes

Once flyspell is running, these are the keybindings you'll use most:

When you press z =, a list of suggestions pops up numbered. Press the corresponding number to accept a correction.

You can also right-click a highlighted word to get suggestions if you prefer the mouse.

Adding Words to the Dictionary

If flyspell flags something that's correct like a name, a technical term, or an acronym you have a couple of options:

Words added with z g go into ~/.aspell.en_CA.pws (or equivalent for your dictionary) and won't be flagged again.

Changing Dictionaries on the Fly

If you switch between languages in different files, you can change the active dictionary without touching your config:

M-x ispell-change-dictionary

Type the dictionary name (e.g. en_GB) and flyspell will re-check using that dictionary for the current session.

Sacha Chua contacted me to schedule a coaching session later this week. She wrote about it here: https://sachachua.com/blog/2026/03/thinking-about-coaching-goals-with-prot/.

I maintain a strict privacy policy with everyone I meet. Specifically, I do not say anything about our meeting. But since Sacha has already published this information, I am happy to do this in the open.

What follows are some comments on her post.

Testing interactive functions

writing tests, especially for things that are more interactive

What helps here is to think of the interactive part as the way to get the arguments. If the interactivity is more involved, then you want to think how it can be broken down into smaller routines. Each routine should eventually be reduced to a function that can be called non-interactively with a certain argument. This way, your tests are easier to reason about.

Consider this example:

(defun my-greet-person (name)
  "Return Hello string to person with NAME."
  (format "Hello %s" name))

The substantive part of the test would be something like this:

(let ((name "Sacha"))
  (string= (my-greet-person name) "Hello Sacha"))

Now add interactivity to the function:

(defun my-greet-person (name)
  "Return Hello string to person with NAME.
When called interactively, prompt for NAME.  Else NAME is a string."
  (interactive (list (read-string "Whom to greet: ")))
  (format "Hello %s" name))

Even though this function can be called interactively, the test is the same because the interactive simply sets the value of name.

There will, of course, be more complex scenaria. We can think how best to approach them. Though this is the general idea.

Navigating Lisp code across many files

navigating code that might be scattered in literate config files or in Emacs Lisp files

What I find helpful:

• Use the Emacs bookmarking system. I add a bookmark for anything I visit frequently. Then I can find what I need with bookmark-jump or consult-buffer (from Daniel Mendler’s consult package).
• Have a single root for all your programming projects. In my case this is ~/Git/.
• In that directory, create subdirectories with areas of interest. One of them should be specific to the projects you maintain. For example, I have ~/Git/emacs-community/ and ~/Git/Projects/. The latter consists of everything I develop/maintain.
• With these directories in place, you can always rely on a recursive Grep to find what you need.
• Otherwise, we have xref-find-definitions as well as all the help functions like describe-function which normally link to the file where the definition is.

Sharing with others

If I get better at sharing what I’m working on, I might be able to connect with more people and bounce ideas around.

Getting better is nice. I think here the goal is to structure what you are sharing in a certain way. Then people can use it more easily. Once that happens, you will receive more feedback.

Also, accountability might help me nudge this over the threshold.

This is key. When we make a promise in earnest, we are motivated to deliver on it. The fact that you have published this adds to the effectiveness of it.

I’m curious about other people’s workflows for sharing. I like joining meetups, but I tend to share stuff only if no one else has anything planned, because I have my blog and my YouTube channel in case I want to share anything with a wider group of people. I just have to actually post things.

Each person is different and there is no one answer to rule them all. What I do, as someone who publishes on a number of topics, is to reach a point that is an honest representation of my current level. This point is not approaching perfection, as that is a trap. If it were about perfection, I would never publish anything!

Once I do what is within my current level, I am casual about it. In other words, I do not need to prove that I am worthy of it—I am already there and this is my current normal state. This makes the process of writing less emotionally challenging (well, not challenging at all). It also opens me to learn more. I am not defensive or argumentative because, fundamentally, I feel secure with what I have: I am not hiding something and do not worry about what others may think.

About your case, I get the impression that you are already improving your content. It starts by recognising that there is improvement to be had. Then, you write blog posts such as the one I am now commenting on, which show that you have put thought into your processes. In other words, you are mindful of your current state. Whatever I may point out during our meeting will thus be easier for you to incorporate in your thinking. Why? Because you already know the space, as it were, and so you will have a good intuition of where to put the new thing.

Getting used to streaming

Streaming: Still need to get the hang of talking to myself or having half-conversations with chat: can be worked around by scheduling a session with Prot and opening it to the public

I am happy to do this in public. Either as a coaching session or some collaborative live stream. We can discuss the details.

At any rate, “practice makes perfect”. The only way to get used to talking to the camera is to do it enough times. I can talk at length, though I still find it hard to laugh when I am by myself, so I look dead serious in all of my monologues. Whereas, say, in the “Prot Asks” series I often laugh. This is because I have a natural response towards someone. Talking to the selfie camera does not create in me the same friendly emotions.

Sharing code

renaming things when I want to move them to a library

Before finding a name, you need to have a clear vision for the package: what is it meant to do. Then try to think about words that describe either the goal or the workflow. Use phrases, like what you have with “speech input”. Those work fine.

Come up with placeholder names if you are not sure. Then, once you are ready to share the package, do a final round of thinking to check if you can think of a more suitable name. Otherwise just use some descriptive phrase.

This concerns the prefix for the entire package. Though your code may still consist of different areas of focus. For example, in my denote package there is a subset of functionality related to “rename” operations. All of those share a compound prefix of the name of the package plus the name of the area they are specialising in like this helper function: denote-rename-buffer--format. By the name alone, I can tell that it relates to the “rename” operation and, specifically, is ancillary to denote-rename-buffer.

I can provide concrete suggestions for your code.

duplicating small functions (ex: simplify string)

You may choose to put those in their own package. Though I personally do not mind a little bit of duplication/repetition when that is easier to maintain. The principle of not repeating yourself is good in general, though there are cases where trying to avoid it is not worth the effort.

figuring out how to make it possible for someone else to start using my stuff

For any non-trivial code you write, you want to treat it like its own “package”. In other words, it exists in a file of its own, it has all the require calls for its dependencies, defines defcustom variables if it must, uses autoload where relevant, and has a provide call at the end. Even if you never move it out of your configuration, you have already done the work of clearing up your thoughts/code. Others will already benefit from that, as they can now copy the file with greater confidence in its utility.

Questions for Prot

Meta: what are people finding useful for coaching and behaviour change, like learning new keyboard shortcuts or workflows?

Each person has their own goals. Some enjoy a pair programming session. Others like me to check on their progress and to provide feedback. Plus, there is more than the purely Emacs component: I make comments about matters of perspective, whether it is about some piece of code or life in general.

Those granted, I do not collect any data about the people I meet. I do not ask them for testimonials or feedback. I prefer not to do that because I do not wish to ever have to handle private information. I like my meetings to be nice and simple. Plus, I do not want to manipulate or influence the behaviour of people.

Your literate config exports to individual .el files. I could probably do something similar to separate my functions from my personal config in order to make it easier for people to reuse parts of my config. Is it worth doing so? Do people tell you that they use those private Emacs Lisp files by loading them, or do they mostly rely on your published packages?

Most rely on my packages. I design those to be as flexible as possible and maintain them accordingly.

The individual .el files of my configuration are helpful to me. I stay in the flow of designing my code in a package-ready way. If anybody needs to use it, then they already have something that is close to an actual package.

Do you have some tweaks to make it easier to jump to function definitions considering a literate configuration?

No, I have not had a need for this. When I choose to work on some part of my configuration, I navigate to the relevant heading (with something like consult-outline) and then use org-edit-special to edit the source block.

You will show me what you have been doing, which may give me some ideas.

What’s your general process for migrating things from your config to a repository or package?

It all starts with splitting the code into many .el files. Make sure one file is not entangled with other files. Or, at least, put in the effort to list every other file as a dependency and write the necessary require for it.

Have one such file for each area of focus. This way you can reason about what you have and what may be missing. A clear initial idea will determine the direction of the package long-term. The reason is that it establishes boundaries: what to do and what not to do.

From there, you can decide if some file is of value to other users. If you think it is, then start implementing defcustom variables for it, define the commands that users would want, and have autoload directives for them if they are meant as points of entry.

It really feels like BlogMore has kicked off a whole new thing when it comes to personal hacking. During the past few years I've developed a lot of Python applications and libraries, and have had a ton of fun doing so, but during that time I've not really done anything with writing stuff for Emacs.

To a large degree I think this says something about how stable Emacs is for me (I've been using it for a touch over 30 years at this point, you'd think I'd be kind of settled with it), but it's still always fun to have a reason to hack on some Lisp code. There's little doubt my Lisp -- especially Emacs Lisp -- has got a wee bit rusty.

So I'm having a lot of fun at the moment falling into the rabbit hole of expanding on and tinkering with blogmore.el. The reason I've just made v2.2 is a good example of exactly this. There are no real user-facing changes in the code, it was all things I just wanted to tidy up.

The main thing that has been bugging me for the past day is the repeating boilerplate that resulted from adding all the different current-blog-aware setting getter functions. There were 7 different functions, all looking like this:

(defun blogmore--post-maker-function ()
  "Get the post maker function for the current blog."
  (or
   (blogmore--blog-post-maker-function (blogmore--chosen-blog))
   blogmore-default-post-maker-function))

Exact same pattern, the only thing different being the name of the getter function being called on, and the name of the variable that contained the global default value.

So just a little earlier I cleaned this up using one of my favourite things about Lisp: defmacro. There's something about macros that makes me really like coding in Lisp, and which I cite as a really good thing when asked why I like Lisp, but which I always seem to utterly fail to explain well. Macros feel like one of those things you just have to experience for yourself to really get¹.

Now, thanks to this:

(defmacro blogmore--setting (setting)
  "Generate a function to get the value of SETTING for the current blog."
  `(defun ,(intern (format "blogmore--%s" setting)) ()
     ,(format "Get the %s for the current blog." setting)
     (or (,(intern (format "blogmore--blog-%s" setting)) (blogmore--chosen-blog))
         ,(intern (format "blogmore-default-%s" setting)))))

all those 7 functions can collapse to this²:

(blogmore--setting post-template)
(blogmore--setting post-maker-function)
(blogmore--setting category-maker-function)
(blogmore--setting tag-maker-function)
(blogmore--setting post-link-format)
(blogmore--setting category-link-format)
(blogmore--setting tag-link-format)

Now the code is shorter, cleaner, and if I need to change anything I only need to change it in one place. Sure, the latter part especially is one of those "you could do that with a function too" things (have the work in one place), but here I can get the language to write me a whole load of functions, all of which refer to different functions and variables, each one based off just the one symbol.

The point of all of this being: v2.2 of blogmore.el is now out, it adds nothing for the user (who I suspect is only me anyway), but I had an absolute blast dusting off more of my Emacs Lisp knowledge and getting back the urge to code even more Emacs Lisp.

All of this has even got me tidying up my ~/.emacs.d/ and has me thinking I should go back through some of my older code and clean up all that legacy nonsense.

The recent post “You don’t not need the mouse” by noa ks speaks to a sentiment that I’ve had for some time. Using the mouse in Emacs can be a good, daresay delightful, experience. Unfortunately though, Emacs has antiquated default settings that presume we’re all still using a 90’s style 3-button workstation mouse. In addition, the overreliance on reusing menu keymaps for both the main and context menus results in poor user experience. I feel strongly that context menus populated this way feel more like an inventory than a thoughtful selection of commands relevant to context.

Thankfully, Emacs offers the mechanisms to sculpt mouse interactions to contemporary (circa 2026) expectations. Over the past three years, I’ve taken advantage of them to implement the following features:

• Mode Line

  • Right mouse click on blank space to pop-up a window management menu
  • Left mouse click on buffer name to pop-up a customizable list of buffers
  • Double click on blank space to toggle current window to maximize or return to prior window configuration

• Context Menu

  • Context-aware commands for selected text (use-region-p)
  • Context-aware commands for Org and Dired mode

• Main Menu

  • Add Bookmarks menu
  • Reorganize Help menu

Several months ago, I decided these mouse interaction changes should be generalized into a package that others could use. So began the Anju project.

Today I’m happy to announce that Anju v1.0 is now available on MELPA.

Learn more details about Anju in its User Guide.

As Anju is new, I’m always open to constructive feedback on it. Let me know what you think. Work on Anju is ongoing with the plan to keep adding improvements to it over time, in particular with supporting more context menus for different modes.

I've given blogmore.el a wee bump to v2.1. This release fixes a small problem I noticed today when I tried to use it to edit the tags for a post on my photoblog: the code to find and gather properties from posts didn't handle deeply-nested directory hierarchies for the post markdown files. I should have noticed this when I first wrote the code, but of course I was so busy testing against my primary blog, which only goes one sub-level deep, that I never noticed it wasn't going to work deeper.

So rather than using grep to look for things like foo/**/*.md I swapped to a combination of find and grep. Which works, but is slightly (but noticeably) slower.

Then I got to thinking that if I was doing this by hand, on the command line, I'd be using ripgrep anyway. Given this I might as well use it here. Of course, not everyone who might use blogmore.el will have rg installed so it makes sense to look for that and use it if it's available, otherwise fall back on find/grep.

There's still some low-priority cleaning up I want to do around this; an obvious change I want to make being one where I want to collapse all cases of the same word (Tree vs tree, etc) into one "hit"¹. For now though, as always, it's working well enough for my needs and this change fixed an obvious issue I ran into.

Anyone who’s been around Irreal for a while knows of my fascination with Lisp Machines. Part of my love or Emacs is that it’s (sort of) a reimagining of the Lisp Machines. Sadly, I never had a chance to work on an actual Lisp Machine but my fascination and love for them continues.

The idea of the Lisp machine is that although it had pretty much standard hardware components, it had specialized microcode that optimized it for running Lisp. For me, the real win was the software more than the hardware. That software still exists but is encumbered so it’s not available without a steep payment or a bit of piracy. That means that for those who, like me, love the idea of the Lisp Machine, the closest we’re going to get is Emacs.

Ketrainis over at Asianometry has an excellent video that recounts the history of the Lisp machines from their birth to their demise. They were hundreds—perhaps thousands—of times slower than today’s cheap laptop but they were built by and for hackers and everything was user customizable just as with Emacs. Even the microcode could be reprogrammed. Joe Marshall has a great post that describes his reprogramming the Lisp Machne microcode to break DES.

This customizability was a huge benefit that every Emacs user will identify with. If the software didn’t support what you needed it to do, you could simply change it—even at the microcode level—to get the behavior you needed.

Ketrainis’ video is 45 minutes, 21 seconds longs so you’ll definitely need to schedule some time but if you have any interest in Lisp Machines, it’s worth your while.

It's not too late to write about mistakes and misconceptions as part of the Emacs Carnival for March and not too early to think about the theme of "Newbies/Starter Kits" which Cena will be hosting for April. Who knows, maybe those ideas can become part of the newcomers presets. It could be fun to explore something like notes for Emacs beginners and see where you end up.

Also, I'm looking forward to seeing if these tips for reloading Emacs Lisp code can help me avoid little bugs from leftover code.

Enjoy!

• Upcoming events (iCal file, Org):
  • EmacsATX: Emacs Social https://www.meetup.com/emacsatx/events/313720093/ Thu Apr 2 1600 America/Vancouver - 1800 America/Chicago - 1900 America/Toronto - 2300 Etc/GMT – Fri Apr 3 0100 Europe/Berlin - 0430 Asia/Kolkata - 0700 Asia/Singapore
  • M-x Research: TBA https://m-x-research.github.io/ Fri Apr 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 #4 2026 (v #živo) https://dogodki.kompot.si/events/c4ee8c26-c668-491e-91b3-b466578b83e2 Mon Apr 6 1900 CET
  • OrgMeetup (virtual) https://orgmode.org/worg/orgmeetup.html Wed Apr 8 0900 America/Vancouver - 1100 America/Chicago - 1200 America/Toronto - 1600 Etc/GMT - 1800 Europe/Berlin - 2130 Asia/Kolkata – Thu Apr 9 0000 Asia/Singapore
  • Atelier Emacs Montpellier (in person) https://lebib.org/date/atelier-emacs Fri Apr 10 1800 Europe/Paris
• Beginner:
  • Emacs Getting Started - notes in org-roam
  • Emacs Describes Almost Everything Within It 2026 03 30 03:29:50 (10:02)
• Emacs configuration:
  • general.el to Conquer Emacs Keybindings - Bicycle For Your Mind
  • compile-angel.el - Ensure that all Emacs Lisp files are always byte-compiled and native-compiled [Release 1.2.0]​
  • Emacs Redux: Emacs Prelude: Redux
• Emacs Lisp:
  • Emacs Redux: Reloading Emacs Lisp Code (Irreal)
  • rossabaker/better-calculate-lisp-indent.el: Improves indentation of quoted and backquoted lists in Emacs lisp - Codeberg.org (@ross@social.rossabaker.com)
• Appearance:
  • Emacs Redux: Automatic Light/Dark Theme Switching
  • Emacs Redux: Creating Emacs Color Themes, Revisited
  • A small victory: Emacs core modification in C to set line-height less than the default
  • Bozhidar Batsov: Batppuccin: My Take on Catppuccin for Emacs
• Navigation:
  • treesitedit-mark-sexp is useful
• TRAMP:
  • The new TRAMP alternatives are probably not worth it
• Writing:
  • Chris Maiorana: Let the commits tell the story (Irreal)
  • my minimalist emacs setup for writing (21:43)
  • blogmore.el v2.0 - davep - setting up multiple blogs (@davep@fosstodon.org) and 2.1
• Denote:
  • Protesilaos Stavrou: Emacs: another spontaneous live stream for denote-sequence (YouTube)
  • Emacs: spontaneous live stream to implement a denote-sequence feature (02:13:01)
• Org Mode:
  • Sacha Chua: Categorizing Emacs News items by voice in Org Mode
  • Curtis McHale: Goodbye Longform Hello Emacs (YouTube 16:59, Irreal)
  • Chris Maiorana: OrgFolio | Turn your scattered interests into cultivated obsessions (Irreal)
  • aleksozolins/org-taube: Email-first capture pipeline for Org mode · GitHub (Reddit)
  • Org development:
    • Fixed org-babel-execute:awk to work on remote machines
    • ox-latex: Make brackets around LATEX_CLASS_OPTIONS optional
• Coding:
  • iquiw/emacstreak: GitHub streak stats on Emacs · GitHub (@iquiw@mstdn.jp)
  • Migrating from asdf and direnv to mise | Masutaka's ChangeLog Memo (@masutaka@mstdn.love) - fixing ruby-lsp not working in Emacs
  • neocaml 0.6: dune major/minor mode, flymake backend (@bbatsov@hachyderm.io)
  • Emacs Redux: Paredit’s Keybinding Conflicts (Irreal)
  • Marcin Borkowski: Disabling Eslint in one line with Tide
  • James Dyer: Simply Annotate 0.9.8: Threaded Conversations on Your Code (Github, Reddit)
  • flymake-janet: A Flymake backend for the Janet language [v0.2.0]​
  • Bozhidar Batsov: Neocaml 0.6: Opam, Dune, and More
  • Einar Mostad: Use python shell from virtual environment if there is one in Emacs
  • Bozhidar Batsov: fsharp-ts-mode: A Modern Emacs Mode for F#
  • Monday Live Coding with Emacs. 3/23/2026 #coding #livecoding #emacs #learnc (01:20:11)
• Shells:
  • Edit Shell Commands in Emacs with CTRL-X CTRL-E (15:43)
• Web:
  • Emacs Webpaste Is A Tool To Use Online Pastebin Services 2026_03_25_03:57:04 (18:01)
• Mail, news, and chat:
  • Code for reminding you about forgotten attachments
  • andros/meshmonitor-chat.el - chat client for Meshtastic mesh networks (@andros@activity.andros.dev)
• Fun:
  • Random Character Generator | Citizens of the Imperium (@kensanata@tabletop.social)
• Community:
  • Fortnightly Tips, Tricks, and Questions — 2026-03-24 / week 12
  • Emacs as a programmable workbench (Reddit)
  • Emacs Carnival March 2026: Mistakes and Misconceptions
    • EWW fragments: fixing my own mistakes | acdw.net
    • Sacha Chua: Emacs Carnival March 2026: Mistakes and learning to reach out
    • My Emacs misconceptions - box.matto.nl
  • Emacs Redux: Happy 13th Birthday, Emacs Redux!
  • Prot Asks: Arkadiusz about blindness, Emacspeak, Hyperbole, Chinese and Slavic culture | Protesilaos Stavrou (YouTube 01:57:23)
  • xenodium wants to know if people want to sponsor Org Mode + Google Sheets sync (@xenodium@indieweb.social)
• Other:
  • Fix idle timer leak when saving buffers by kommen · Pull Request #165 · Malabarba/aggressive-indent-mode · GitHub (@kommen@hachyderm.io)
  • Emacs on the go on a Zinwa Q25 on Android
• Emacs development:
  • emacs-devel:
    • new branch scratch/ert-play-keys lets ERT interactively play keystrokes during tests
    • How can we improve shorthands? - Richard Lawrence
    • monitoring GC
    • "GNU ELPA packages with NonGNU ELPA dependencies" (a very long thread) that people who maintain packages in GNU ELPA might want to know about (Reddit)
  • Implement new Dired handling of errors from 'ls'
  • Add predicate for initial_terminal
  • New user option 'whitespace-global-mode-buffers'
• New packages:
  • ancient-theme: A theme about ruins (MELPA)
  • anju: Mouse UX Customizations (MELPA)
  • clj-doc-browse: Browse Clojure library docs from classpath JARs (MELPA)
  • eglot-typescript-preset: Eglot preset for TypeScript (MELPA)
  • eldoc-mouse-nov: Preview epub link for mouse hover (NonGNU ELPA)
  • flywrite: Inline writing suggestions via LLM (MELPA)
  • fsharp-ts-mode: Major mode for F# code (MELPA)
  • llm-test: LLM-driven testing for packages (MELPA)
  • ros-face: Syntax highlighting for ROS files (MELPA)
  • tetris-60: Retro ASCII Tetris (MELPA)
  • vterm-editor: Edit text in a buffer and send it to vterm (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.

Pull up git log --oneline on a project—or open the Magit log with l l from the status buffer and you might see two slightly different stories.

Either you’ll see this:

f31e4a2 WIP
c8b29f1 some minor edits
9aa55d3 chugging through
8f72cc0 some tweaks
3d19c44 some more tweaking

Or you’ll see something like this:

f31e4a2 Finished the confrontation scene w/ Megan
c8b29f1 Fleshed out Ethan's backstory in chapter two
9aa55d3 Bar fight scene, in
8f72cc0 Further developed Ethan's voice
3d19c44 Initial commit, project structure and outline

Both sets of commits represent the same amount of work. The only difference is the two minutes it took to write a real commit message instead of a placeholder.

There’s been a lot of discussion in recent years about what to name your branches, which can be anything you want. However, has anyone taken a hard look at some of the hard-coded git terminology, like the word “commit”? In my Git For Writers handbook, I compared commits to “save states” or “snapshots.” I’d always felt the word “commit” sounded too permanent and fixed, but that’s not the case at all.

The word commit has a richer meaning than at first appears. Derived from a Latin root meaning to entrust, it’s the same as committing something to memory, or entering a transaction into a ledger, more like a notation than a final verdict. That’s exactly what you’re doing when you commit your work in git: entrusting a session or chunk of work to the record. Nothing is declared finished or locked in, but you are merely saying: this is what I did today or this is where I was when I stopped today.

a1f3309 Initial commit, project structure and notes
b22e117 Opened the story, established the narrator's tone
cc49852 Drafted the first scene, setting and introduction
d78f441 Pushed through the second scene, conflict introduced
e830192 A turn, starting to click
f91b004 Rough draft complete
g04a215 First revision pass, tightened the opening
h17d331 Cut the second paragraph of scene one entirely
i2a8c62 Addressed group critique notes, softened the ending
j30f577 Final proofread pass
k498d00 Submitted to Mudflap Review

git log --oneline --stat

git diff --word-diff HEAD~1

git tag -a rough_draft -m "Rough draft finished, 62,000 words"

The post Let the commits tell the story appeared first on Chris Maiorana.

It took me a decade to try Emacs again, for reasons totally unrelated to computer programming (task management!), and a lot of effort by my pal Sascha Fast. In hindsight, I realize I had to learn a couple of things first.

• Emacs is clumsy and old. I didn’t know that a GUI Emacs version existed, could display images and scroll somewhat smoothly, coming from an IT department with SUN terminals where we used Emacs on the command-line to edit some .c source files. By modern standards, it’s lean and snappy and can do interesting things using your OS’s window manager for multi-frame workflows (like displaying a ‘Speedbar’ for symbol navigation). In 2026, Emacs will learn to efficiently draw at 60+ FPS to a canvas, multiple in parallel even, to display movies and play video games. I’m not joking!

• Text is not enough. Text, I realized eventually, is plenty! The customizable Org Agenda got me hooked: filter through tasks, display a magic ‘UI’ that fits my needs, amazing. That’s all possible because Emacs deals with (not necessarily file-backed) buffers all the way down. With directory listings, server management, and using Emacs to complement and complete computing all around, the game has changed. Instead of TUI, I read for … EUI?

• I’ll only use this for to-do’s. I absolutely didn’t. 7 years (oh god) later I’m still discovering new excused to use Emacs for new things. Starting with task management, I also made this my Writeroom-like writing workspace, used it for copy-editing books and innumerable blog posts in various projects, tweaked and learned to love a custom key binding mechanism, moved light scripting over, then more and more programming and web development tasks. Email, chat, eventually LLM chat interfaces and Agentic Engineering; everything is being swallowed by the Universal Paperclip machinery that is this weird Lisp interpreter.

• I will copy and paste config snippets most of the time. I used StackOverflow, Sacha Chua’s blog, Xah Lee’s blog and Elisp reference as stepping stones. I still grab stuff from other people’s configurations and test-drive them. But I also found a strange joy in writing Lisp, and got into reading Structure and Interpretation of Computer Programs and finally understood the mechanics and beauty of the composition so much better. In a way, it helped me think more clearly about functions, composition, and what makes good software.

I didn’t sign up for all that happened at first. But I got sucked in, and as I mentioned in passing so many times, Emacs is an isle of computing freedom in an environment of ever tighter sandboxes, locking-down and dumbing down computers, making the operating system UI ugly as sin – it’s not great to be in love with computers unless you find your way onto a capable Linux machine. Or, like me, who’s stuck on a Mac for work, use Emacs to maintain their sanity. (That’s probably not a line any longer-term Emacs user ever said.)

Get new posts delivered to your inbox — subscribe.

What I'm up to right now · Work with me · Apps

Creating Emacs color themes is a topic I hadn’t thought much about in recent years. My first theme (Zenburn) has been in maintenance mode for ages, and Solarized mostly runs itself at this point. But working on my ports of Tokyo (Night) Themes and Catppuccin (Batppuccin) made me re-examine the whole topic with fresh eyes. The biggest shift I’ve noticed is that multi-variant themes (light/dark/high-contrast from a shared codebase) have become the norm rather than the exception, and that pattern naturally leads to reusable theming infrastructure.

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

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

The Classic Approach

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

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

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

(provide-theme 'my-cool-theme)

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

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

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

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

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

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

Every Multi-Variant Theme Is a Mini Framework

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

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

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

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

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

Meta-Themes

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

Solarized

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

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

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

Modus Themes

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

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

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

Theming Frameworks

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

Autothemer

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

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

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

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

Base16 / Tinted Theming

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

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

From Scratch vs. Framework: Pros and Cons

When to Use What

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

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

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

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

Parting Thoughts

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

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

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

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

After kicking off blogmore.el, and then tinkering with it more and more, I've found it really quite helpful while writing posts. One thing I have noticed though -- given I use BlogMore for this blog and my photoblog -- is that I wanted to be able to use the package for working with more than one blog.

So today I found myself with some time to kill and the result is that blogmore.el v2.0 has now been released. This version allows for setting up multiple blogs, each with their own settings for where posts live, how their paths are formatted, and so on.

To handle this I've also added the blogmore-work-on command so that the active blog can be quickly changed.

All of this can be configured using Emacs' customize feature.

This has all changed since v1.x, where most of the customize options have now been renamed to include -default- in their name. The idea here is that what was the value for a setting previously is now the default value if a given blog hasn't had that setting defined.

For any given blog you wish to work with, you configure a name (for your own reference) and the path to the posts. Optionally you can also set lots of other values too.

If a value is left on Default, then the corresponding default setting will be used; if it's set, then that value is used for that specific blog.

The defaults out of the box match how I do things with my blogs, of course, so the configuration is pretty straightforward. As of the time of writing my use-package for blogmore.el looks like this:

(use-package blogmore
  :vc (:url "https://github.com/davep/blogmore.el" :rev :newest)
  :init (add-hook 'blogmore-new-post-hook #'end-it)
  :custom
  (blogmore-blogs
   '(("blog.davep.org" "~/write/davep.github.com/content/posts/")
     ("seen-by.davep.dev" "~/write/seen-by/content/posts/")))
  :bind
  ("<f12> m b" . blogmore-work-on)
  ("<f12> m p n" . blogmore-new)
  ("<f12> m p e" . blogmore-edit)
  ("<f12> m s c" . blogmore-set-category)
  ("<f12> m a t" . blogmore-add-tag)
  ("<f12> m u d" . blogmore-update-date)
  ("<f12> m u m" . blogmore-update-modified)
  ("<f12> m l p" . blogmore-link-post)
  ("<f12> m l c" . blogmore-link-category)
  ("<f12> m l t" . blogmore-link-tag))

In the above you can see that I've set only the blog title and posts path for each blog in blogmore-blogs; the remaining values are all implied nil and so will be defaulted. The full list of values for any given blog are:

(BLOG-NAME
 POSTS-DIRECTORY
 POST-TEMPLATE
 POST-MAKER-FUNCTION
 CATEGORY-MAKER-FUNCTION
 TAG-MAKER-FUNCTION
 POST-LINK-FORMAT
 CATEGORY-LINK-FORMAT
 TAG-LINK-FORMAT)

where:

• BLOG-NAME is the descriptive name to use for the blog.
• POSTS-DIRECTORY is the directory where the blog's posts are stored.
• POST-TEMPLATE is a template for new posts. If nil, blogmore-default-template is used.
• POST-MAKER-FUNCTION is a function that takes a filename and returns a string to be used in the post's URL. If nil, blogmore-default-post-maker-function is used.
• CATEGORY-MAKER-FUNCTION is a function that takes a category name and returns a string to be used in the category's URL. If nil, blogmore-default-category-maker-function is used.
• TAG-MAKER-FUNCTION is a function that takes a tag name and returns a string to be used in the tag's URL. If nil, blogmore-default-tag-maker-function is used.
• POST-LINK-FORMAT is a format string for the post's URL, where %s is replaced with the value returned by the post maker function. If nil, blogmore-default-post-link-format is used.
• CATEGORY-LINK-FORMAT is a format string for the category's URL, where %s is replaced with the value returned by the category maker function. If nil, blogmore-default-category-link-format is used.
• TAG-LINK-FORMAT is a format string for the tag's URL, where %s is replaced with the value returned by the tag maker function. If nil, blogmore-default-tag-link-format is used.

While I very much doubt any of this is useful to anyone else, it's at least flexible for my purposes and can probably be configured to someone else's purpose should they happen to be using BlogMore and Emacs.

There are, I suppose, a few Lisp programmers using Emacs who resist paredit but most of the rest of us have long since succumbed to its charms. It can be a bit difficult to get used to but once you do, it’s a tool you don’t want to live without.

There is a problem though. Since Paredit’s introduction 20 years ago, Emacs has added new default keybindings some of which conflict with the existing Paredit keybindings. I can remember having to remap some of Paredit’s keybindings to avoid this.

Bozhidar Batsov has a nice post that discusses these conflicts and how to deal with them. My use of Paredit is mostly restricted to a small subset of its commands so I haven’t experienced the full impact of these conflicts. Even for those commands I do use—like slurp and barf—the conflict doesn’t bother me because I never use the arrow keys to move the cursor.

If you use more of the Paredit commands, take a look at Batsov’s post for his suggestions for resolving them. Or, you could switch to Fuco1’s smartparens, which avoids these conflicts while providing the same functionality and extending it to other file types.

One thing for sure, if you use paredit-splice-sexp you’ll want to resolve its conflict because Emacs uses Meta+s as the search map prefix and that is too useful to forego.

In any event if you’re a Paredit or Smartparens user, you should definitely take a look at Batsov’s post.

Most theme families these days ship both light and dark variants. For example, Tokyo Themes has tokyo-day (light) alongside tokyo-night, tokyo-storm, and tokyo-moon (all dark). Batppuccin has batppuccin-latte (light) and batppuccin-mocha, batppuccin-macchiato, batppuccin-frappe (dark). But switching between them manually gets old fast. Here are a few ways to automate it.

Following the OS Appearance (macOS + Emacs Plus)

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

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

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

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

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

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

Following the OS Appearance (Cross-Platform)

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

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

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

Time-Based Switching with circadian.el

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

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

You can also use fixed hours if you prefer:

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

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

Rolling Your Own with run-at-time

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

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

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

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

Which One Should You Pick?

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

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

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

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

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

I have been busy improving my annotation package! Simply Annotate, the latest release is 0.9.8 and I have put in a bunch of new features, so it felt like a good time to step back and show what the package actually does at this point, because honestly, quite a lot has changed since I last wrote about it.

There are annotation packages out there already, annotate.el being the most established. And they are good! But I kept running into the same friction: I wanted threaded conversations directly on my code, I wanted multiple display styles I could combine, and I wanted the whole thing to be a single file with no dependencies that I could drop onto an air-gapped machine and just use (yup, that again!)

So I built my own!, this is Emacs, after all.

At its core, simply-annotate lets you attach persistent notes to any text file (or Info manual, or dired buffer) without modifying the original content. Annotations are stored in a simple s-expression database at ~/.emacs.d/simply-annotations.el. The entire package is a single elisp file, requires Emacs 28.1+, and has zero external dependencies.

Basic setup is two lines:

(use-package simply-annotate
 :bind-keymap ("C-c a" . simply-annotate-command-map)
 :hook (find-file-hook . simply-annotate-mode))

Or if you prefer require:

(require 'simply-annotate)
(global-set-key (kbd "C-c a") simply-annotate-command-map)
(add-hook 'find-file-hook #'simply-annotate-mode)

Open a file, select some text, press C-c a j, and you have your first annotation. M-n and M-p step through them.

I am always fiddling around with styles, themes, backgrounds e.t.c, so I thought I would build this tinkering enthusiasm into this package. Simply-annotate has five display styles, and you can layer them together:

• Highlight – classic background colour on the annotated region
• Tint – a subtle background derived from your current theme, lightened by a configurable amount. Adapts automatically when you switch themes
• Fringe – a small triangle indicator in the fringe, minimal and unobtrusive
• Fringe-bracket – a vertical bracket spanning the full annotated region in the fringe, with a proper top cap, continuous vertical bar, and bottom cap
• Subtle – overline and underline bracketing the region, barely visible but there when you need it

You can combine them, so (tint fringe-bracket) gives you a gentle background wash with a clear fringe bracket showing exactly where the annotation spans. Cycle through styles with C-c a '.

Toggle inline display with C-c a / and annotation content appears as box-drawn blocks directly in your buffer:

 some annotated code here
 ▴
┌─ ✎ [OPEN/NORMAL] ──────────────
│ This function needs refactoring.
│ The nested conditionals are hard
│ to follow.
└─────────────────────────────────

New in 0.9.8 is the inline pointer, that little ▴ connecting the box to the annotated text. It is indented to the exact column where the annotation starts, so you always know what the comment refers to.

The fun bit is that the pointer is just a string, and it supports multiline. So you can customise it to whatever shape you like:

;; Simple arrow (default)
(setq simply-annotate-inline-pointer-after "▴")
(setq simply-annotate-inline-pointer-above "▾")

;; Heavy L-bracket (my current favourite)
(setq simply-annotate-inline-pointer-after "┃\n┗━▶")
(setq simply-annotate-inline-pointer-above "┏━▶\n┃")

;; Speech bubble tail
(setq simply-annotate-inline-pointer-after " ╰┐")
(setq simply-annotate-inline-pointer-above " ╰┐")

;; Decorative diamond
(setq simply-annotate-inline-pointer-after "◆")
(setq simply-annotate-inline-pointer-above "◆")

There is a full list of copy-paste options in the Commentary section of the elisp file. Set to nil to disable the pointer entirely.

So I think this is where simply-annotate really differs from other annotation packages. Every annotation is a thread. You can reply to it with C-c a r, and replies can be nested under any comment in the thread, not just the root. It prompts with a hierarchical completing-read menu showing the comment tree.

Each thread has:

• Status – open, in-progress, resolved, closed (C-c a s)
• Priority – low, normal, high, critical (C-c a p)
• Tags – freeform hashtags for organisation (C-c a t)
• Author tracking – configurable per-team, per-file, or single-user

The comment tree renders with box-drawing characters so the hierarchy is always clear:

┌— ® [OPEN/NORMAL] —
| james dyer (03/29 08:27)
| This is the original comment
| L james dyer (03/29 08:27)
| | here is a reply to this comment
| | L james dyer (@3/29 08:27)
| | and a reply within a reply!!
| L james dyer (03/29 08:28)
| Here is another reply to the original comment
└────────────────────

For team collaboration:

(setq simply-annotate-author-list '("Alice" "Bob" "Charlie"))
(setq simply-annotate-prompt-for-author 'threads-only)
(setq simply-annotate-remember-author-per-file t)

Annotations exist at three levels: file (whole-file overview), defun (function or block description), and line (individual elements). There is also an all pseudo-level that shows everything at once, which is the default.

Cycle levels with C-c a ] and C-c a [. The header-line shows counts per level (FILE:2 | DEFUN:5 | LINE:3) with the active level in bold, so you always know where you are, my idea here is to lean towards a coding annotation tool to help teach code or help to remember what has been implemented, so the levels start at a broad file overview and enables you to switch instantly to a more granular level.

The org-mode listing (C-c a l) gives you a foldable, navigable overview of all annotations in the current file, grouped by level. Press n and p to step through headings, RET to jump to source.

New in 0.9.6, the tabular listing (C-c a T) opens a fast, sortable table using tabulated-list-mode (a feature in Emacs I am starting to leverage more). Columns for Level, Line, Status, Priority, Comments, Tags, Author, and the first line of the comment. Click column headers to sort. This is brilliant for getting a quick birds-eye view of all the open items in a file.

For the global view, simply-annotate-show-all gathers annotations from every file in the database into a single org-mode buffer.

Enable simply-annotate-dired-mode and dired buffers show fringe indicators next to files that have annotations. You can see at a glance which files have notes attached:

(add-hook 'dired-mode-hook #'simply-annotate-dired-mode)

Info manuals are also fully supported. Annotations are tracked per-node, and the listing and jump-to-file commands navigate to Info nodes seamlessly.

Press C-c a e and you can edit the raw s-expression data structure of any annotation. Every field is there: thread ID, status, priority, tags, comments with their IDs, parent-IDs, timestamps, and text. C-c C-c to save. This is the escape hatch for when the UI does not quite cover what you need.

Rather than writing paragraphs about how simply-annotate compares to other packages, I have put together a feature matrix in the README. The short version: if you want threaded conversations, multiple combinable display styles, annotation levels, a smart context-aware command, and zero dependencies in a single file, this is the package for you. If you need PDF annotation, go with org-noter or org-remark, they are excellent at that.

(use-package simply-annotate
 :bind-keymap ("C-c a" . simply-annotate-command-map)
 :hook (find-file-hook . simply-annotate-mode))

(with-eval-after-load 'simply-annotate
 (add-hook 'dired-mode-hook #'simply-annotate-dired-mode))

The package is available on GitHub on melpa at simply-annotate or https://github.com/captainflasmr/simply-annotate. There is also an Info manual if you run M-x info and search for simply-annotate.

I promised I’d take a break from building Tree-sitter major modes, and I meant it. So what better way to relax than to build… color themes? Yeah, I know. My idea of chilling is weird, but I genuinely enjoy working on random Emacs packages. Most of the time at least…

Some Background

For a very long time my go-to Emacs themes were Zenburn and Solarized – both of which I maintain popular Emacs ports for. Zenburn was actually one of my very first open source projects (created way back in 2010, when Emacs 24 was brand new). It served me well for years.

But at some point I got bored. You know the feeling – you’ve been staring at the same color palette for so long that you stop seeing it. My experiments with other editors (Helix, Zed, VS Code) introduced me to Tokyo Night and Catppuccin, and they’ve been my daily drivers since then.

Eventually, I ended up creating my own Emacs ports of both. I’ve already published emacs-tokyo-themes, and I’ll write more about that one down the road. Today is all about Catppuccin. (and by this I totally mean Batppuccin!)

Why Another Catppuccin Port?

There’s already an official Catppuccin theme for Emacs, and it works. So why build another one? A few reasons.

The official port registers a single catppuccin theme and switches between flavors (Mocha, Macchiato, Frappe, Latte) via a global variable and a reload function. This is unusual by Emacs standards and breaks the normal load-theme workflow – theme-switching packages like circadian.el need custom glue code to work with it. It also loads color definitions from an external file in a way that fails when Emacs hasn’t marked the theme as safe yet, which means some users can’t load the theme at all.

Beyond the architecture, there are style guide issues. font-lock-variable-name-face is set to the default text color, making variables invisible. All outline-* levels use the same blue, so org-mode headings are flat. org-block forces green on all unstyled code. Several faces still ship with #ff00ff magenta placeholder colors. And there’s no support for popular packages like vertico, marginalia, transient, flycheck, or cider.

I think some of this comes from the official port trying to match the structure of the Neovim version, which makes sense for their cross-editor tooling but doesn’t sit well with how Emacs does things.¹

Meet Batppuccin

Batppuccin is my opinionated take on Catppuccin for Emacs. The name is a play on my last name (Batsov) + Catppuccin.² I guess you can think of this as @bbatsov’s Catppuccin… or perhaps Batman’s Catppuccin?

The key differences from the official port:

Four proper themes. batppuccin-mocha, batppuccin-macchiato, batppuccin-frappe, and batppuccin-latte are all separate themes that work with load-theme out of the box. No special reload dance needed.

Faithful to the style guide. Mauve for keywords, green for strings, blue for functions, peach for constants, sky for operators, yellow for types, overlay2 for comments, rosewater for the cursor. The rainbow heading cycle (red, peach, yellow, green, sapphire, lavender) makes org-mode and outline headings actually distinguishable.

Broad face coverage. Built-in Emacs faces plus magit, vertico, corfu, marginalia, embark, orderless, consult, transient, flycheck, cider, company, doom-modeline, treemacs, web-mode, and more. No placeholder colors.

Clean architecture. Shared infrastructure in batppuccin-themes.el, thin wrapper files for each flavor, color override mechanism, configurable heading scaling. The same pattern I use in zenburn-emacs and emacs-tokyo-night-theme.

I didn’t really re-invent anything here - I just created a theme in a way I’m comfortable with.

I’m not going to bother with screenshots here – it looks like Catppuccin, because it is Catppuccin. There are small visual differences if you know where to look (headings, variables, a few face tweaks), but most people wouldn’t notice them side by side. If you’ve seen Catppuccin, you know what to expect.

Installation

The easiest way to install it right now:

1
2
3
4
(use-package batppuccin-mocha-theme
  :vc (:url "https://github.com/bbatsov/batppuccin-emacs" :rev :newest)
  :config
  (load-theme 'batppuccin-mocha t))

Replace mocha with macchiato, frappe, or latte for the other flavors. You can also switch interactively with M-x batppuccin-select.

There Can Never Be Enough Theme Ports

I remember when Solarized was the hot new thing and there were something like five competing Emacs ports of it. People had strong opinions about which one got the colors right, which one had better org-mode support, which one worked with their favorite completion framework. And that was fine! Different ports serve different needs and different tastes.

The same applies here. The official Catppuccin port is perfectly usable for a lot of people. Batppuccin is for people who want something more idiomatic to Emacs, with broader face coverage and stricter adherence to the upstream style guide. Both can coexist happily.

I’ve said many times that for me the best aspect of Emacs is that you can tweak it infinitely to make it your own, so as far as I’m concerned having a theme that you’re the only user of is perfectly fine. That being said, I hope a few of you will appreciate my take on Catppuccin as well.

Wrapping Up

This is an early release and there’s plenty of room for improvement. I’m sure there are faces I’ve missed, colors that could be tweaked, and packages that deserve better support. If you try it out and something looks off, please open an issue or send a PR.

I’m also curious – what are your favorite Emacs themes these days? Still rocking Zenburn? Converted to modus-themes? Something else entirely? I’d love to hear about it.

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

One of Lisp’s features that seem like magic to those of us brought up with C-like languages is the ability to change the code of a running process, reload it, and continue running with the new code. The amazing thing is that the process is not restarted. It simply continues running but with the new code.

Emacers do this all the time, often without realizing what they’re doing. They make a change, to their init.el, say, evaluate it, and continue executing their current Emacs instance. Sometimes, this is simply changing a parameter value but you can also change a function definition in the same way.

If you’re new to Emacs you may wonder how this magical spell is invoked even though you’ve done it several times. It’s simply a matter of evaluating the new code and continuing. Except when it isn’t. There are some edge cases that can trip you up. In Lisp it’s devar values. Emacs adds defface and defcustom. The values defined by these commands are not changed by a code update. This is on purpose. The idea is that you don’t want to mess with a user’s, say, custom values when you change the code.

Bozhidar Batsov has a nice post that discusses all this with particular attention on how to deal with devar and the other edge cases. For example, I always thought the the way to change devar variables was to evaluate a setq of the variable with the new value but you can also simple invoke eval-defun (Ctrl+Meta+x) to the devar to update the value. This also works for defcustom and defface.

The other nice thing I didn’t know about is the restart-emacs command that restarts Emacs and—with desktop-save-mode​—reloads everything, including the new defvar etc. values. Take a look at Batsov’s post for more details.

Emacs Asia-Pacific (APAC) virtual meetup will not be happening this month. See you in the next meetup! Stay updated: https://emacs-apac.gitlab.io/#stay-updated.

I’m pretty much done with the focused development push on neocaml – it’s reached a point where I’m genuinely happy using it daily and the remaining work is mostly incremental polish. So naturally, instead of taking a break I decided it was time to start another project that’s been living in the back of my head for a while: a proper Tree-sitter-based F# mode for Emacs.

Meet fsharp-ts-mode.

Why F#?

I’ve written before about my fondness for the ML family of languages, and while OCaml gets most of my attention, last year I developed a soft spot for F#. In some ways I like it even a bit more than OCaml – the tooling is excellent, the .NET ecosystem is massive, and computation expressions are one of the most elegant abstractions I’ve seen in any language. F# manages to feel both practical and beautiful, which is a rare combination.

The problem is that Emacs has never been particularly popular with F# programmers – or .NET programmers in general. The existing fsharp-mode works, but it’s showing its age: regex-based highlighting, SMIE indentation with quirks, and some legacy code dating back to the caml-mode days. I needed a good F# mode for Emacs, and that’s enough of a reason to build one in my book.

The Name

I’ll be honest – I spent quite a bit of time trying to come up with a clever name.¹ Some candidates that didn’t make the cut:

• fsharpe-mode (fsharp(evolved/enhanced)-mode)
• Fa Dièse (French for F sharp – because after spending time with OCaml you start thinking in French, apparently)
• fluoride (a play on Ionide, the popular F# IDE extension)

In the end none of my fun ideas stuck, so I went with the boring-but-obvious fsharp-ts-mode. Sometimes the straightforward choice is the right one. At least nobody will have trouble finding it.²

Built on neocaml’s Foundation

I modeled fsharp-ts-mode directly after neocaml, and the two packages share a lot of structural similarities – which shouldn’t be surprising given how much OCaml and F# have in common. The same architecture (base mode + language-specific derived modes), the same approach to font-locking (shared + grammar-specific rules), the same REPL integration pattern (comint with tree-sitter input highlighting), the same build system interaction pattern (minor mode wrapping CLI commands).

This also meant I could get the basics in place really quickly. Having already solved problems like trailing comment indentation, forward-sexp hybrid navigation, and imenu with qualified names in neocaml, porting those solutions to F# was mostly mechanical.

What’s in 0.1.0

The initial release covers all the essentials:

• Syntax highlighting via Tree-sitter with 4 customizable levels, supporting .fs, .fsx, and .fsi files
• Indentation via Tree-sitter indent rules
• Imenu with fully-qualified names (e.g., MyModule.myFunc)
• Navigation – beginning-of-defun, end-of-defun, forward-sexp
• F# Interactive (REPL) integration with tree-sitter highlighting for input
• dotnet CLI integration – build, test, run, clean, format, restore, with watch mode support
• .NET API documentation lookup at point (C-c C-d)
• Eglot integration for FsAutoComplete
• Compilation error parsing for dotnet build output
• Shift region left/right, auto-detect indent offset, prettify symbols, outline mode, and more