James Cherti has an interesting and useful post about the relative efficiency of setq, setq-default, setopt, and customize-set-variable. Cherti justifies this concern on their effect on Emacs startup time but according to well established Irreal dicta this doesn’t matter because we seldom restart Emacs so a few seconds more or less simply don’t matter.

Oddly, there are some people who pay no attention to Irreal dicta and who obsess about every millisecond—Cherti’s term—of Emacs startup time. For those people and those who worry about execution times in general, Cherti’s post is very useful and explains why some of those commands are faster than others.

The crux of the matter is that defcustom can include a setter method that can be arbitrarily complex. Cherti has a nice example of this that will help you understand what’s going on. Cherti says that very often there’s no reason to invoke that setter method during startup and that setq or setq-default is faster and just as useful. Commands like setopt and customize-set-variable always call the setter method so they may be slower. Cherti’s examples show how to avoid unnecessary bottlenecks.

Cherti also shows how even the :custom keyword in use-package can trigger the setter methods of those variables and gives some workarounds. The main problem is that it’s hard to know when you can avoid the setter method and when you can’t. Sometimes, you just have to read the source code to figure it out.

Obsessing about startup times aside, it’s nice to have an explanation of what these commands do and how their use might affect run time. Cherti’s post is relatively short and well worth a minute or two to read.

Nous allons parler en direct avec Abdallah Maouche (heiwiper) (heiwiper/emacs.d, Gitlab, Github) d'Emacs, de ses flux de travail, de sa configuration, et d'autres sujets en français. Je suis un peu intimidée, mais si vous posez vos questions dans le chat, je pense que nous pouvons survivre à mon faible niveau de français. =)

J'ai essayé de corriger la transcription, mais je crois qu'il y a encore beaucoup d'erreurs, donc n'hésitez pas à m'envoyer un message.

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

The ispell package serves as the underlying interface in Emacs for communicating with external spell checking programs. Building upon this, the flyspell package is a built-in minor mode that provides on-the-fly spell checking. It highlights misspelled words as you type and offers interactive corrections. This article presents a practical configuration for Emacs that sets up ispell to use Aspell for both programming and standard text editing.

Additionally, it addresses a common issue for developers. While writing code, variables such as filepath or buffername in comments or docstrings are often flagged as errors, generating visual noise in your programming buffers. This article contains a specific configuration to reduce these false positives.

Setting the backend and dictionary

The first step is to configure Emacs to use Aspell as the spell-checking engine, set the default dictionary, and reduce unnecessary messages when checking individual words:

;; Set the ispell program name to aspell
;; (switching to aspell will generally offer better performance than ispell.)
(setq ispell-program-name "aspell")

;; Set the global default dictionary for the Ispell process.
(setq ispell-dictionary "en_US")

;; Reduce unnecessary messages when checking individual words.
(setq ispell-quietly t)

Note that this configuration explicitly targets the US English dictionary "en_US". If you write in a different language or require a different regional dialect, such as "en_GB" or "fr_FR", replace "en_US" with your preferred language code.

Configuring aspell flags

The following configures Aspell's suggestion mode to "ultra", which favors very close spelling and phonetic matches when generating suggestions:

;; Configure Aspell's suggestion mode to "ultra", which favors very close
;; spelling and phonetic matches when generating suggestions.
(setq ispell-extra-args '("--sug-mode=ultra"))

Handling compound words in source code

Comments and string literals in source code are heavily populated with compound variable names and technical terms, such as filepath, buffername, or checkbox. Aspell may flag these as errors, generating visual noise in programming buffers.

To resolve this, we pass the --run-together flag to Aspell. This flag allows Aspell to recognize words formed by combining valid dictionary words without spaces. (It only affects words in the comments and strings that Flyspell checks; it does not cause Flyspell to check arbitrary identifiers elsewhere in the source buffer.)

To apply this cleanly, we can define a custom wrapper function that we will later attach to our programming modes using add-hook. This function activates flyspell-prog-mode and then safely appends the required flags buffer-locally using add-to-list, which inherently prevents duplicate arguments if the mode is toggled off and on:

(defun my-flyspell-prog-mode (&rest _args)
  "Enable `flyspell-prog-mode' with buffer-local Aspell arguments."
  ;; The --run-together flag instructs Aspell to accept words formed by
  ;; combining two or more valid dictionary words without spaces, treating the
  ;; resulting string as valid.
  ;;
  ;; This is excellent for source code. Code is heavily populated with
  ;; compound variable names and technical terms (e.g., filepath, buffername,
  ;; checkbox).
  ;; URL: https://www.jamescherti.com/emacs-spell-checker-flyspell-ispell-aspell/
  (make-local-variable 'ispell-extra-args)
  (dolist (item '("--run-together"
                  ;; "--ignore=2"
                  ;; "--run-together-min=3"
                  ;; "--run-together-limit=4"
                  ;; "--camel-case"
                  ))
    (add-to-list 'ispell-extra-args item))
  (flyspell-prog-mode))

Here are four additional flags worth uncommenting in the my-flyspell-prog-mode function above. Each provides specific advantages for programming workflows, along with some tradeoffs to consider:

• --run-together-limit=4: Increases the maximum number of combined words allowed in a single string from the default limit of two up to 4. (A higher limit increases the probability that a genuine typo will be silently ignored because Aspell manages to break the misspelling down into a sequence of several shorter valid words. It also adds a slight processing overhead.)
• --run-together-min=3 sets the minimum length of the individual words that Aspell is allowed to use when recognizing a run-together compound. For example, with a value of 3, Aspell can recognize filepath as file + path, but it is less likely to accept a compound that depends on very short components such as a or in. Increasing this value can therefore reduce false positives in source code by preventing Aspell from accepting suspicious compounds made up of short, common words.
• --ignore=2: Configures Aspell to completely skip words containing two characters or fewer. Tradeoff: You lose spell checking for actual two-letter English words (such as "is", "an", "to", "of").
• --camel-case: Enables Aspell's camel-case word handling, allowing camelCase identifiers to be checked more appropriately. It can reduce false positives for identifiers such as myHttpRequest that appear in docstrings and comments. Tradeoff: It can occasionally mask a typo if its components are individually recognized as valid words.

Initializing the Packages

Finally, we use add-hook to bind the spell checking functions to the appropriate Emacs hooks:

;; The flyspell package is a built-in Emacs minor mode that provides on-the-fly
;; spell checking. It highlights misspelled words as you type, offering
;; interactive corrections.
;; URL: https://www.jamescherti.com/emacs-spell-checker-flyspell-ispell-aspell/
(defun my-flyspell-enable-appropriate-mode ()
  "Enable the appropriate Flyspell mode based on the current major mode."
  (if (or (derived-mode-p 'conf-mode)
          (derived-mode-p 'yaml-mode)
          (derived-mode-p 'yaml-ts-mode)
          (derived-mode-p 'ansible-mode)
          (derived-mode-p 'nxml-mode)
          (derived-mode-p 'sgml-mode))
      (my-flyspell-prog-mode)
    (flyspell-mode 1)))

(add-hook 'prog-mode-hook #'my-flyspell-prog-mode)
(add-hook 'conf-mode-hook #'my-flyspell-enable-appropriate-mode)
(add-hook 'text-mode-hook #'my-flyspell-enable-appropriate-mode)

Note: Configuration files such as YAML and Ansible playbooks can present an edge case because some source-like modes are based on text-mode rather than prog-mode. Without an explicit override, such modes may receive ordinary Flyspell behavior rather than programming-mode behavior. Since these files behave more like source code, we use a custom dispatcher function to apply my-flyspell-prog-mode to them instead.

A few additional interesting options

Several lesser-known variables can be adjusted to change Flyspell's behavior and, in some cases, reduce the amount of work it performs. These options involve tradeoffs: reducing spell-checking activity can improve responsiveness, but may also reduce the amount of text that is checked or the feedback that Flyspell provides.

• Setting flyspell-issue-message-flag and flyspell-issue-welcome-flag to nil suppresses Flyspell's checking messages and its startup welcome message. This removes minibuffer messages generated by Flyspell without changing the actual spell-checking operation.
• Setting flyspell-check-changes to a non-nil value causes Flyspell to check only words that have been typed or edited, instead of also checking words that point moves across. This can reduce spell-checking activity when navigating through existing text. The tradeoff is that existing misspellings are not checked because point moves across them, so they may remain undetected until the text is edited or checked explicitly.
• Setting flyspell-delay-use-timer to a non-nil value makes Flyspell use a timer instead of sit-for when waiting after delayed commands. This allows idle timers and other Emacs code to run during the delay. The option therefore changes how Flyspell waits before performing a check rather than disabling the delay itself.
• Setting flyspell-mark-duplications-flag to nil prevents Flyspell from reporting repeated words as errors. This eliminates duplicate-word detection, so accidental repetitions such as "the the" are no longer reported.
• Setting ispell-silently-savep to a non-nil value causes new words added to the personal dictionary to be saved without an interactive confirmation prompt. This avoids the prompt when saving personal-dictionary additions, but also removes that opportunity to review each addition before it is saved.
• Setting flyspell-highlight-properties to nil prevents Flyspell from highlighting incorrect words when the relevant text already has text properties. The spelling check can still identify the word as incorrect, but Flyspell will not add its normal misspelling highlight when an applicable text property is present. This can be useful when existing text properties should take precedence over Flyspell's visual indication.
• Lowering flyspell-large-region tells Flyspell to use its faster bulk-checking method for smaller sections of text. Instead of checking each word individually, Flyspell sends the larger section to the external Ispell/Aspell program to check it in one operation. For example, changing the value from 1000 to 200 makes Flyspell use this method for regions containing 200 or more characters. This can improve performance when checking larger sections, but repeated words such as "the the" are not detected when this bulk-checking method is used.
• Increasing flyspell-delay increases the number of seconds Flyspell waits before checking after a command classified as delayed. This can reduce how frequently spell checking is triggered during rapid editing, at the cost of delaying the appearance of misspelling highlights.

In my last article on AI agents I talked about using Claude Code AI agent. This is an easy-to-set-up commercial solution that gives excellent results. The risk is that the pricing may not remain as affordable as it is today, and as a result I wanted to find an alternative solution that insulates me from changing commercials.

There are a number of open-weight models that one may download and run locally on your home computer. Some of the benefits are:

The canvas patch has been finally merged to upstream GNU Emacs. If you have been following my Mastodon, this was a journey that took us ~8 months. But finally we have, in core Emacs, a feature that I desperately desired in early 2025 when I was starting the Emacs Reader project: a way to update and manipulate images in Emacs without choking Emacs by putting the image data in strings. I went through a series of different hacks to overcome these limitations, some more successful than others, but thanks to the magnificent Daniel (aka minad) who suggested the idea of exposing a pixel buffer from within Emacs via the dynamic module API. That idea is now a feature in Emacs, and will be part of Emacs 32 release cycle. A more detailed history about this will be written later, for now this article is an introduction to the new feature, its API and what you can do using it. I will try to keep it as self-contained as I can, so that beginners are able to understand it. But first, we need to clarify certain misconceptions that people might have about this feature.

(setq test-canvas `(image :type canvas
                          :id test
                          :data-width 10
                          :data-height 10
                          :data nil))

(image :type canvas :data nil :scale default :id g138)

;; A red square of 10x0 size
(setq rect-vec (make-vector (* 10 10) #xFFFF0000))

(setq rect-canvas `(image :type canvas
                          :id rect
                          :data-width 10
                          :data-height 10
                          :data ,rect-vec))

(insert (propertize "#" 'display rect-canvas))

static emacs_value
Fcanvas_update(emacs_env* env, ptrdiff_t nargs, emacs_value args[], void* data) {
  emacs_value canvas = env->args[0];
  uint32_t *canvas_pixel = env->canvas_data(env, canvas); // accessing canvas' pixel buffer
  if (canvas_pixel)
    {
      // do some pixel manipulation to the canvas pixel
    }
}

env->funcall(env, env->intern(env, "canvas-refresh"), (emacs_value[])[rect_canvas, Qnil]);

(setq W 250
      H 250
      BG #xFF8B00FF)
(setq ball-canvas-vec (make-vector (* W H) BG))
(setq ball-canvas `(image :type canvas
                          :id rect
                          :data-width ,W
                          :data-height ,H
                          :data ,ball-canvas-vec))
(insert (propertize "#" 'display ball-canvas))

(setq ball-radius 10)
(setq bx (/ W 2)
      by (/ H 2)) ; start from the center
(setq dx 4
      dy 3) ; initial velocity
(setq ball-color #xFFFFFF00) ; yellow

(defun draw-ball (cx cy color)
  (let ((r2 (* ball-radius ball-radius))) ; Radius squared
    ;; the nested loop checks for the circle within the square
    (dotimes (y-off (1+ (* 2 ball-radius)))
      (dotimes (x-off (1+ (* 2 ball-radius)))
        (let* ((px (+ cx (- x-off ball-radius)))
               (py (+ cy (- y-off ball-radius)))
               (dx-local (- px cx)) ; Horizontal distance from center
               (dy-local (- py cy)) ; Vertical distance from center
               (dist2 (+ (* dx-local dx-local) (* dy-local dy-local)))) ; squared distance using pythagorean theorem
          ;; check if pixel is inside the circle AND inside the canvas bounds
          (when (and (>= px 0) (< px W) (>= py 0) (< py H) (<= dist2 r2))
            (aset ball-canvas-vec (+ (* py W) px) color)))))))

(defun ball-bounce ()
  (setq bx (+ bx dx) by (+ by dy))
  ;; compare with ball-radius so the *edge* of the circle bounces, not the center.
  (when (<= bx ball-radius) (setq dx (abs dx)) (setq bx ball-radius))
  (when (>= bx (- W ball-radius)) (setq dx (- (abs dx))) (setq bx (- W ball-radius)))
  (when (<= by ball-radius) (setq dy (abs dy)) (setq by ball-radius))
  (when (>= by (- H ball-radius)) (setq dy (- (abs dy))) (setq by (- H ball-radius))))

(setq ball-frame 0)
(setq max-ball-frames 2000)
(defun ball-loop ()
  (if (>= ball-frame max-ball-frames)
      (cancel-timer ball-timer)
    (setq ball-frame (1+ ball-frame))
    (draw-ball bx by BG) ; make old ball invisible (turn it into background color)
    (ball-bounce)
    (draw-ball bx by ball-color)
    (canvas-refresh ball-canvas t)))
(setq ball-timer (run-with-timer 0 0.02 'ball-loop))

(setq W 250
      H 250
      BG #xFF101010)
(setq canvas-vec (make-vector (* W H) BG))
(setq canvas `(image :type canvas :id dp :data-width ,W :data-height ,H :data ,canvas-vec))
(insert (propertize "#" 'display canvas))

(setq g 9.8
      L 60.0
      dt 0.05)

(setq th1 2.5
      th2 2.5
      w1 0.0
      w2 0.0)
(setq pivot-x 125
      pivot-y 80)

(defun set-px (x y color)
  (when (and (>= x 0) (< x W) (>= y 0) (< y H))
    (aset canvas-vec (+ (* (truncate y) W) (truncate x)) color)))

(defun draw-line (x0 y0 x1 y1 color)
  (let* ((x0 (truncate x0)) (y0 (truncate y0))
         (x1 (truncate x1)) (y1 (truncate y1))
         (dx (abs (- x1 x0))) (dy (abs (- y1 y0)))
         (sx (if (< x0 x1) 1 -1)) (sy (if (< y0 y1) 1 -1))
         (err (- dx dy)) e2)
    (while (not (and (= x0 x1) (= y0 y1)))
      (set-px x0 y0 color)
      (setq e2 (* 2 err))
      (when (> e2 (- dy))
        (setq err (- err dy))
        (setq x0 (+ x0 sx)))
      (when (< e2 dx)
        (setq err (+ err dx))
        (setq y0 (+ y0 sy))))
    (set-px x0 y0 color)))

(defun draw-circ (cx cy r color)
  (let ((r2 (* r r)))
    (dotimes (y (* 2 r)) (dotimes (x (* 2 r))
                           (let* ((px (+ (- cx r) x)) (py (+ (- cy r) y))
                                  (dx (- px cx)) (dy (- py cy)))
                             (when (<= (+ (* dx dx) (* dy dy)) r2)
                               (set-px px py color)))))))

(defun pendulum-physics ()
  (let* ((dth (- th1 th2))
         (den (- 3.0 (cos (* 2.0 dth))))
         (num1 (+ (* (- g) 3.0 (sin th1))
                  (* (- g) (sin (- th1 (* 2.0 th2))))
                  (* (- 2.0) (sin dth) (+ (* w2 w2 L) (* w1 w1 L (cos dth))))))
         (a1 (/ num1 (* L den)))
         (num2 (* 2.0 (sin dth)
                  (+ (* 2.0 w1 w1 L)
                     (* 2.0 g (cos th1))
                     (* w2 w2 L (cos dth)))))
         (a2 (/ num2 (* L den))))
    (setq w1 (+ w1 (* a1 dt)) w2 (+ w2 (* a2 dt)))
    (setq th1 (+ th1 (* w1 dt)) th2 (+ th2 (* w2 dt)))))

(defun pendulum-loop ()
  (dotimes (i 12) (pendulum-physics))
  (fillarray canvas-vec BG)
  (let* ((x1 (+ pivot-x (* L (sin th1))))
         (y1 (+ pivot-y (* L (cos th1))))
         (x2 (+ x1 (* L (sin th2))))
         (y2 (+ y1 (* L (cos th2)))))
    (draw-line pivot-x pivot-y x1 y1 #xFF888888)
    (draw-line x1 y1 x2 y2 #xFF888888)
    (draw-circ x1 y1 8 #xFF00FF00)
    (draw-circ x2 y2 8 #xFFFF0000)
    (set-px pivot-x pivot-y #xFFFFFFFF))
  (canvas-refresh canvas t))
(setq my-timer (run-with-timer 0 0.05 'pendulum-loop))

#define WIDTH 960
#define HEIGHT 720
#define BACKGROUND_COLOR 0xFF181818
#define GRID_COUNT 10
#define GRID_PAD (0.5f/GRID_COUNT)
#define GRID_SIZE ((GRID_COUNT - 1)*GRID_PAD)
#define CIRCLE_RADIUS 5
#define Z_START 0.25f

void draw_circle(uint32_t *pixels, int cx, int cy, int r, uint32_t color) {
  int r2 = r * r;
  for (int y = -r; y <= r; ++y) {
    for (int x = -r; x <= r; ++x) {
      if (x*x + y*y <= r2) {
        int px = cx + x; int py = cy + y;
        if (px >= 0 && px < WIDTH && py >= 0 && py < HEIGHT)
          pixels[py * WIDTH + px] = color;
      }
    }
  }
}

static emacs_value render(emacs_env* env, ptrdiff_t nargs, emacs_value args[], void* data)

static emacs_value render(emacs_env* env, ptrdiff_t nargs, emacs_value args[], void* data) {
    emacs_value canvas = args[0];
    float angle_x = env->extract_float(env, args[1]);
    float angle_y = env->extract_float(env, args[2]);

    uint32_t* pixels = env->canvas_data(env, canvas);
    if (!pixels) return Qnil;
}

static emacs_value render(emacs_env* env, ptrdiff_t nargs, emacs_value args[], void* data) {
    emacs_value canvas = args[0];
    float angle_x = env->extract_float(env, args[1]);
    float angle_y = env->extract_float(env, args[2]);

    uint32_t* pixels = env->canvas_data(env, canvas);
    if (!pixels) return Qnil;

    for(int i = 0; i < WIDTH * HEIGHT; ++i) pixels[i] = BACKGROUND_COLOR;

    float cos_x = cosf(angle_x), sin_x = sinf(angle_x);
    float cos_y = cosf(angle_y), sin_y = sinf(angle_y);

    float camera_distance = 0.8f;  // How far the camera is from the center (Lower = closer)
    float focal_length = 800.0f;   // The "zoom" multiplier (Higher = more zoomed in)

    for (int ix = 0; ix < GRID_COUNT; ++ix) {
        for (int iy = 0; iy < GRID_COUNT; ++iy) {
            for (int iz = 0; iz < GRID_COUNT; ++iz) {
                float x = ix*GRID_PAD - GRID_SIZE/2.0f;
                float y = iy*GRID_PAD - GRID_SIZE/2.0f;
                float z = Z_START + iz*GRID_PAD;

                float px = x;
                float py = y;
                float pz = z - (Z_START + GRID_SIZE/2.0f);

                // 1. Rotate around Y axis (Yaw)
                float x1 = px * cos_y + pz * sin_y;
                float z1 = -px * sin_y + pz * cos_y;
                float y1 = py;

                // 2. Rotate around X axis (Pitch)
                float y2 = y1 * cos_x - z1 * sin_x;
                float z2 = y1 * sin_x + z1 * cos_x;
                float x2 = x1;

                // 3. Apply camera distance
                float z_cam = z2 + camera_distance;

                // 4. Perspective projection using focal length
                float screen_x = (x2 / z_cam) * focal_length + WIDTH / 2.0f;
                float screen_y = (y2 / z_cam) * focal_length + HEIGHT / 2.0f;

                uint32_t r = ix*255/GRID_COUNT;
                uint32_t g = iy*255/GRID_COUNT;
                uint32_t b = iz*255/GRID_COUNT;
                uint32_t color = 0xFF000000 | (r << 16) | (g << 8) | b;

                draw_circle(pixels, (int)screen_x, (int)screen_y, CIRCLE_RADIUS, color);
            }
        }
    }

    return Qnil;
}

int emacs_module_init(struct emacs_runtime *rt) {
    if ((size_t)rt->size < sizeof (*rt)) return 1;
    emacs_env* env = rt->get_environment(rt);
    if ((size_t)env->size < sizeof (*env)) return 2;
    Qnil = env->make_global_ref(env, env->intern(env, "nil"));

    env->funcall(env, env->intern(env, "defalias"), 2,
                 (emacs_value[]){
                     env->intern(env, "dots3d-render"),
                     env->make_function(env, 3, 3, render, "Render dots3d", 0)
                 });
    return 0;
}

gcc -O2 -I%ssrc dots3d.c -o /tmp/dots3d.so -fPIC -shared -lm

(module-load "/tmp/dots3d.so")
(declare-function dots3d-render "ext:dots3d.c")

(switch-to-buffer (get-buffer-create "*dots3d*"))

(defvar dots3d-canvas)
(defvar dots3d-frame 0)
(defvar dots3d-time 0.0)
(defvar dots3d-last-time 0.0)

(defvar dots3d-angle-x 0.0)
(defvar dots3d-angle-y 0.0)
(defvar dots3d-auto-rotate t)

(setq dots3d-time (float-time))
(setq dots3d-last-time (float-time))

(setq dots3d-canvas '(image :type canvas
                            :data-width 960
                            :data-height 720
                            :margin (20 . 20)
                            :scale 1
                            :id dots3d))

(setq-local cursor-type nil
            mode-line-position nil
            mode-line-modified nil
            mode-line-mule-info nil
            mode-line-remote nil)

(insert (propertize "#" 'display dots3d-canvas))

(defun dots3d-start-drag (event)
  (interactive "e")
  (setq dots3d-auto-rotate nil)
  (let* ((start-pos (posn-object-x-y (event-start event)))
         (last-x (car start-pos))
         (last-y (cdr start-pos)))
    (when (and last-x last-y)
      (track-mouse
        (let (evt pos mx my)
          (while (progn
                   (setq evt (read-event))
                   (mouse-movement-p evt))
            (setq pos (posn-object-x-y (event-start evt)))
            (when (and (car pos) (cdr pos))
              (setq mx (car pos) my (cdr pos))
              (setq dots3d-angle-y (+ dots3d-angle-y (* (- mx last-x) 0.01)))
              (setq dots3d-angle-x (+ dots3d-angle-x (* (- my last-y) 0.01)))
              (setq last-x mx last-y my)
              (dots3d-render dots3d-canvas dots3d-angle-x dots3d-angle-y)
              (canvas-refresh dots3d-canvas))))))
    (setq dots3d-auto-rotate t)))
(local-set-key [down-mouse-1] 'dots3d-start-drag)

(defun dots3d-update ()
    (let* ((time (float-time))
           (dt (- time dots3d-last-time)))
      (switch-to-buffer (get-buffer-create "*dots3d*"))
      (setq dots3d-last-time time)
      (when dots3d-auto-rotate
        (setq dots3d-angle-y (+ dots3d-angle-y (* dt 0.5))))
      (dots3d-render dots3d-canvas dots3d-angle-x dots3d-angle-y)
      (canvas-refresh dots3d-canvas)))
(run-with-timer nil (/ 1 60.0) 'dots3d-update)

Every millisecond counts during Emacs initialization. A potential performance cost in modern Emacs configurations is defaulting to setopt, customize-set-variable, or the use-package :custom keyword when a direct assignment with setq is sufficient.

Disclaimer: This article assumes you have a solid understanding of Emacs Lisp and know what you are doing when switching to setq. For users who prefer a hands-off experience, defaulting to setopt or the built-in customization interface is often better for convenience, even though these options are not the fastest. Using setq is mainly intended for users who want to optimize startup performance. Always check the Elisp definition of each defcustom to ensure that switching to setq does not introduce unintended side effects.

What is the difference between setq and other ways to assign values to variables?

setq (and setq-default)

The setq and setq-default functions directly assigns a value to a variable, making it the fastest way to set a variable. (FYI: The following projects prioritize using setq and setq-default: minimal-emacs.d, Doom Emacs, Protesilaos Emacs config, and Spacemacs.)

(The setq function updates a variable's value within the current scope; if the target variable is buffer-local, the assignment only affects the current active buffer while the global state remains unchanged. Conversely, setq-default explicitly modifies the global default value of a variable. Although both functions produce the same result for purely global variables, setq-default must be used to apply system-wide changes to buffer-local variables like tab-width or indent-tabs-mode.)

setopt, customize-set-variable, and use-package :custom

The setopt, customize-set-variable, and use-package :custom functions can be slower than setq. Depending on the variable, they can:

• Call the variable's defcustom :set function.
• Validate the value against the variable's declared type.
• In some cases, load the library defining an autoloaded customizable variable, potentially causing a package to load earlier during startup.

Example of an expansive defcustom :set property

To understand the latency penalty, look at how a package author might write a defcustom with an expensive :set property:

(defcustom my-global-visual-indicator t
  "Toggle a heavy visual indicator across all open buffers."
  :type 'boolean
  :group 'my-ui-package
  :set (lambda (symbol value)
         ;; Update the variable's value
         (set-default symbol value)
         
         ;; The slow part: Iterate through every open buffer
         ;; and trigger a costly visual update or cache rebuild.
         (dolist (buffer (buffer-list))
           (with-current-buffer buffer
             ;; This simulated function might parse the buffer,
             ;; apply text properties, or query a language server.
             (my-heavy-visual-update-function value)))
             
         ;; Force Emacs to immediately redraw all frames
         (redraw-display)))

Using setopt, customize-set-variable, or the use-package :custom to configure my-global-visual-indicator uses executes the associated defcustom :set function during startup:

;; Example 1: SLOW: This triggers the expensive :set function during startup
(setopt my-global-visual-indicator nil)

;; Example 2: This triggers the expensive :set function
(use-package my-ui-package
  :commands (my-ai-package-cmd1 my-ai-package-cmd2) ; defer
  :custom
  (my-global-visual-indicator nil))

In many cases, the Emacs startup phase is simply not the appropriate time to execute those :set functions.

On the other hand, if the variable does not require its Custom setter to establish associated state, using setq inside a use-package :init block bypasses the Emacs Customization setter entirely:

;; Example 1: FAST: This bypasses the :set function for a faster startup
(setq my-global-visual-indicator nil)

;; Example 2: FAST: This bypasses the :set function
(use-package my-ui-package
  :commands (my-ai-package-cmd1 my-ai-package-cmd2) ; defer
  :init
  (setq my-global-visual-indicator nil))

Note: Code placed in the :init block executes before the package loads into memory. Setting variables here ensures your customized values are already established in the global environment before the package evaluates its internal definitions, bypassing the need for a defcustom setter to update its internal state.

Trade-offs when using setq

Here are the trade-offs to consider when using setq:

• During startup, a direct assignment can avoid UI updates or other side effects performed by a Custom setter. However, setq should only be used when the package does not require that setter to establish associated state.
• setq does not validate types. If you pass a string where a boolean is expected, Emacs will not warn you at evaluation time.

Rule of thumb

Use setopt, customize-set-variable, or use-package :custom when a variable's Custom :set setter or type validation is required, or if you notice that the option is not being applied as intended. Otherwise, use setq by default.

(To determine whether a specific variable requires a custom :set setter for correct state initialization, inspect its properties directly within Emacs. Execute M-x describe-variable or C-h v and provide the variable's name to view its documentation. In the resulting help buffer, look for a :set attribute. While the presence of a :set function indicates that the package defines initialization logic for when the variable is modified, it does not necessarily mean that using setopt or use-package :custom is required. The necessity depends on the specific implementation, as the majority of major and minor modes automatically execute these initialization functions by default when the mode is activated.)

Randy Ridenour has an interesting post about previewing an Org file in your browser. If you’re like me your first thought is probably, “That’s easy. Just export the Org file to HTML and display it right from the Org export dispatcher.” I do exactly that to preview my blog posts. I simply type Ctrl+c Ctrl+e h o and my post appears in my browser. Of course, it doesn’t look exactly like the final product because it uses the default Org CSS instead of the WordPress theme that you see on the Irreal site.

And that’s exactly the point. Ridenour has his own opinion on how his markup should be formatted. Five years ago, I wrote about how to to add your own CSS formatting to an Org file when you export it to HTML but those methods all required adding some text to the Org file. Ridenour’s method does all that in a function that he can call to export his Org file to the browser. The process is pretty much the same as using the export dispatcher except that he gets to have his preferred CSS applied to the output.

The other advantage of his method is the he arranges for the automatic removal of the generated HTML file. The export dispatcher method requires that you delete the files manually. I do that periodically using Embark, which makes it easy but I still have to remember to do it. If you’re looking for a fast and easy way to preview an Org file in your browser, take a look at Ridenour’s post.

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

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

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

It has been a while since I have written about how I use Emacs/LaTeX to generate lesson notes for my students. Quite a lot has happened during that time. One of the main game changers has been the advancements in “AI” technology. Over the next few articles I intend to describe my journey as I navigate this technology and apply it to my teaching practice.

Chat Bots

Having decided to dip my toe in the water, I signed up to two of the prevalent players in this space, being Google Gemini and Anthropic Claude. My early experiments with ChatGPT had led to some disappointing results, where it emphatically tried to convince me that the value of Euler’s constant is 1.5. Since then, the technology has advanced significantly, and I thought it worthwhile to try again.

Last week, Deepseek released DSH, an agent harness with very interesting approach.
The same pitch used by VS Code and Eclipse RPC (2024): “everything is a plugin” but this time it’s a bit different. Even the agent loop itself is a plugin.

In practice, you extend the tool by just prompting. (Reminds me of an old post of mine where I said that Emacs is like a modern “Magic Lamp”)
It allows maximum customizability and also opens many possibilities.
In the official article, they showcased adding snake game to the main interface. Pretty cool!

Around the same time, I spent a little time playing with the pi-coding-agent on Emacs and was thinking that now if I want, I probably could extend Emacs indefinitely by just prompting.

Weird synchronicity.

Anyway, here are some useful links if you want to know more:

• DSH announcement
• deepseek-harness repo
• Cordis paper — A Programming Paradigm for Spatiotemporal Composability
• pi-coding-agent.el — the Emacs frontend I was playing with

Charles Choi has announced the release of Casual 3.0. There are now 26 modules in the Casual suite but this release is about providing an easier setup for the suite. Prior to this release, each module had to be set up separately. As Choi says, that made sense when there were just a few modules but it has become increasingly burdensome as the number of modules grew.

The new procedure is simply to call casual-init and all the module’s you want to use are initialized. The modules you’re using is determined by a set of hook functions that can configured with the Emacs Customize utility. You simple check off which modules you want to use and call casual-init. That’s all there is to it. You can learn more about this in the Casual User Manual.

If you’ve been following along on Choi’s blog—or to a lessor extent on Irreal—you know that there are a lot of different types of modules, not all of which you might want installed. The Customize interface is an easy way to specify which ones you want.

The latest version is available on MELPA and NonGNU ELPA. The nice thing about the modules is that they are all invoked with the same key sequence, Ctrl+o by default, so you don’t have to remember a bunch of different bindings. Once you invoke it, Casual brings up a Transient menu appropriate for the current major mode

Casual is a nice suite that make it easier to navigate Emacs applications that you don’t use often and for which you haven’t internalized all the bindings. Take a look at the user manual if you want to know more.

Two years ago I was a skeptic about GenAI. Now Emacs has become my agent cockpit.

Harness

My favorite harness right now is hermes-agent, which is probably the “emacs of agent harnesses” with how easy it is to configure and extend, while not being “just an agent harness.” Hermes supports messaging gateways, so you have first-class support for mobile as well. All you have to do is /handoff <platform> to continue your session via a mobile messaging app.

To interact with hermes via emacs, I’m using emacs-hermes, which is available via NonGNU ELPA.

Sometimes I also use codex via emacs-codex-ide. But it’s not as token-efficient as my hermes setup, and it’s not where I am most productive. Unlike most harnesses, hermes supports codex native compaction, which is the “killer” feature of codex.

Models

I currently use gpt-5.6-sol for most tasks through my codex subscription. It is exceptionally good at long-running goals. It can easily keep going for 20h+ trying to complete its task, and I have found the quality of its work more than adequate.

TIP: to save tokens with hermes, adjust the auxiliary.approval model to a cheap open-weight one, such as deepseek-v4-flash, which is practically free on nous portal. This has cut my usage by more than 35%.

I’m also surprised by the recent leap x.ai made with Grok, which is currently the best value-for-money model by far. The benchmarks place it close to gpt-5.6-sol and fable.

It’s currently my fallback model when I reach my usage limit on codex. It’s the fastest “frontier” model I’ve tried.

I avoid using models from Anthropic. Models like opus-5 and fable are good for coding tasks, but I found them subpar for my studies even compared to grok-4.6, plus overpriced. The API prices are insane, and their subscription only supports their proprietary harness.

What about open models?

A friend and I tried to self-host our “AI Homelab”, repurposing an old ethereum mining rig plus a couple of new Nvidia GPUs. The performance was not ideal with models like GLM-5.2 compared to subscriptions by a long shot. Forget subagent workflows if you ever attempt it. Not to mention that my electricity bill was the same as I’d pay for a subscription plan.

A lot of people in the “GNU/Linux” sphere are looking for “free” models. Even if there were a 6T+ “free” model that outperforms frontiers, there is no “free hardware” that could run it, and even if there were a FOSS Nvidia alternative, would it be financially worth it for most people as an investment? Would your average hobbyist rather pay $20/month or buy the next gen “free” DGX Spark for $5,000?

Extra goodies & Skills

Memory

No matter your setup, the biggest upgrade for me has been hindsight. It’s an agent memory system that you can share across harnesses, and it helps your agents remember your preferences and workflow details.

It’s free and easy to self-host.

Skills

Skills are where my setup stops being generic. Instead of explaining the same preferences and workflow every session, I put them in SKILL.md files that Hermes loads depending on the task. I have skills for how I want elisp written and reviewed, and even for drafts like this post.

Everyone takes a different approach, from GSD/BMAD/Spec-driven workflows that automate most of the work to “real engineering” skills that want you to babysit the agent. I prefer smaller skills I can mix together instead of one framework owning my whole workflow.

If you are just starting out, browse skills.sh for anything that “looks cool”, experiment with it, then start writing your own. The two I recommend to most people are unslop and grill-me.

Other tools and environments

As of now, the only other tools I’d recommend are web tools like firecrawl and searxng.

Current state of my “AI Psychosis”

The past year the value I have gained from GenAI tools is insane. I had not dreamed, even in my wildest dreams, that I would have such tools in my lifetime.

Tasks that used to bottleneck my workflow, such as adjusting a software tool to help me study, are now cheap to solve. Software is more of a commodity now, no longer a moat. Anything you like can be built easily. You can see that even in projects like hermes, which copied the “Grok Bot” “killer-feature” in less than 24h and made it open source in their harness.

Grunt work like notes for my syllabus based on my university lecture slides used to take me weeks. Now it’s just a /goal prompt, go for a walk for 2h, and come back and they are ready in the same exact format the rest of my notes already have. All that is left is for me to study them.

We live in exciting times.

Álvaro Ramírez, author of Journelly and many other useful applications—a lot of them Emacs based—has a new post about a basic Emacs operation: changing focus to another window. Ramírez and I basically agree about things like this although he stubbornly refuses to admit the superiority of my method of indicating the window that has focus.

Now he has a slightly different problem. For technical reasons that you can read about in his post, he wants to be able to switch to a window in another frame. The other-window command, bound to Ctrl+x o by default, doesn’t consider windows in other frames but, of course, there’s a command for that: next-window-any-frame. That turned out to be exactly what Ramírez needed and he simply bound it to Meta+o, which is where he had other-window bound.

Like Ramírez, I seldom use more than one frame so I didn’t know about this command. If you often have more than one frame going, you may find it useful if you’re not already using it. If you’re an ace-window user, it will consider all frames by default but you can adjust this with aw-scope.

Since its inception, Casual required individual setup for each module it supported. This seemed fine at the start when the module count was low. Now weighing in at 26 modules, there is admittedly a lot of setup.

Not anymore. Starting with the latest Casual v3.0 update, there is now a convenience command to setup all Casual modules: casual-init.

Use the following Elisp to replace all the previous setup code:

1
2

(require 'casual)
(casual-init)

You can configure which modules to setup via the customizable hook variable casual-init-hook, a list of hook functions each associated with a module. Having a module hook function present in casual-init-hook tells casual-init to setup that module.

Editing casual-init-hook is straightforward using the customize checkbox interface shown below.

More information about installation and setup of Casual can be found in the Casual User Guide.

Bumping to 3.0

Because the recommended setup has significantly changed, I’ve decided to bump the major version to 3.0.

That said, there are no functional changes to Casual and all the prior individual setup still should work without change. For existing users of Casual, I highly recommend migrating to casual-init as it allows for removing individual setup code.

A significant amount of manual testing was required to verify lazy-loading behavior in casual-init. While best effort was made to avoid unpleasant surprise, if something shows up, please file an issue to let me know.

Casual v3.0 update is now available on MELPA and NonGNU ELPA.

It costs money to make, enhance, and maintain Casual as ideologically free software. If you enjoy using Casual, please consider buying me a coffee to help support its development and maintenance. Thank you!

Great news! Sean Whitton writes to announce the release of Emacs 31.1 RC1. This is the final step before the formal release of the Emacs 31 series. Whitton remarks that the developers are hoping that RC1 will be the only release candidate. I take that as a measure of their confidence in this trial release. Unless any breaking problems pop up, we can expect the official release of 31.1 imminently.

As always, we should offer up a word of thanks for the hard work of the maintainers and all the developers who have toiled so hard to bring us this latest release. If we find ourselves in the same bar as one of them, the drinks are on us.

I’ve long been a fan of Brett Terpstra’s Marked for easily reading Markdown files. Over the years, he’s added more and more features. He’s recently released Marked 3 which, if you need those features, is well worth the purchase price of $2.99/month subscription or a one-time purchase of $69.99. There are only two small things keeping me from upgrading:

1. I don’t need any of those features — in fact, since everything I write begins as an Org mode file, I don’t really need a Markdown previewer.
2. I teach philosophy at a small liberal arts college in a rapidly collapsing market.

So, I don’t need a Markdown previewer, but an Org mode previewer would be nice. I guess I could have Claude code a Mac app like Marked for Org files, but since Org exports to HTML, it shouldn’t be that difficult to export the HTML to a temporary file, style it with some CSS, open it in a browser, then have it automatically deleted when no longer needed.

Here is the export function and the CSS for styling the output.

(defun rlr/org-export-html-to-browser ()
  "Export the current Org buffer to a temporary HTML file in the system temp directory, open it, and then delete it when Emacs is killed."
  (interactive)
  (unless (derived-mode-p 'org-mode)
    (user-error "Not in an Org buffer"))
  (let* ((tmp (make-temp-file "org-preview-" nil ".html"))
         (org-export-in-background nil)
         (org-html-head-include-default-style nil)
         (org-html-head-include-scripts nil)
         (org-html-head rlr/org-preview-css)
         (org-html-validation-link nil))
    (org-export-to-file 'html tmp)
    (add-hook 'kill-emacs-hook
              (lambda () (ignore-errors (delete-file tmp))))
    (browse-url-of-file tmp)))

(defvar rlr/org-preview-css "
<style>
  :root { color-scheme: light dark; }
  body {
    max-width: 40rem;
    margin: 3rem auto;
    padding: 0 1.25rem;
    font-family: -apple-system, BlinkMacSystemFont, 'Iowan Old Style','Palatino Linotype', Georgia, serif;
    font-size: 1.125rem;
    line-height: 1.65;
    color: #24292f;
    background: #fdfdfc;
    text-rendering: optimizeLegibility;
    hyphens: auto;
  }
  h1, h2, h3, h4 {
    font-family: -apple-system, BlinkMacSystemFont, 'Helvetica Neue', sans-serif;
    line-height: 1.25;
    margin-top: 2.25em;
    color: #14181c;
  }
  h1 { font-size: 1.9rem; margin-bottom: 0.2em; }
  h2 { font-size: 1.45rem; }
  h3 { font-size: 1.2rem; }
  .title { text-align: left; margin-bottom: 2rem; }
  #table-of-contents { font-size: 0.95rem; }
  a { color: #0b5cad; text-underline-offset: 2px; }
  blockquote {
    margin: 1.5em 0; padding: 0.25em 0 0.25em 1.25em;
    border-left: 3px solid #d0d7de; color: #4a5058; font-style: italic;
  }
  pre, code { font-family: 'SF Mono', Menlo, Consolas, monospace; font-size: 0.9rem; }
  pre {
    background: #f4f4f2; padding: 0.9em 1.1em;
    border-radius: 6px; overflow-x: auto; line-height: 1.45;
  }
  code { background: #f0f0ee; padding: 0.1em 0.3em; border-radius: 3px; }
  pre code { background: none; padding: 0; }
  table { border-collapse: collapse; margin: 1.5em 0; font-size: 0.95rem; }
  th, td { border: 1px solid #d0d7de; padding: 0.4em 0.7em; text-align: left; }
  th { background: #f4f4f2; }
  hr { border: none; border-top: 1px solid #d8d8d4; margin: 2.5em 0; }
  .footpara { display: inline; }
  #postamble { margin-top: 3rem; font-size: 0.85rem; color: #6a707a; }
  @media (prefers-color-scheme: dark) {
    body { color: #d6d3cd; background: #16181a; }
    h1, h2, h3, h4 { color: #f0ede8; }
    a { color: #6cb3f5; }
    blockquote { border-left-color: #3a3f45; color: #a8a49d; }
    pre { background: #1e2124; }
    code { background: #24282c; }
    th, td { border-color: #3a3f45; }
    th { background: #1e2124; }
    hr { border-top-color: #2e3236; }
  }
</style>"
  "Stylesheet injected into throwaway HTML previews of Org buffers.")

The canvas patch has been merged upstream, very cool! I'm looking forward to seeing the kinds of experiments and tools this enables. Also, there's a release candidate for the next version of Emacs, please go try it out!

• Emacs 31:
  • Emacs 31.1 RC1 is available (HN)
• Upcoming events (iCal file, Org):
  • M-x Research: TBA https://m-x-research.github.io/ Wed Aug 19 0800 America/Vancouver - 1000 America/Chicago - 1100 America/Toronto - 1500 Etc/UTC - 1700 Europe/Berlin - 2030 Asia/Kolkata - 2300 Asia/Singapore
  • Emacs APAC: Emacs APAC meetup (virtual) https://emacs-apac.gitlab.io/announcements/ Sat Aug 22 0130 America/Vancouver - 0330 America/Chicago - 0430 America/Toronto - 0830 Etc/UTC - 1030 Europe/Berlin - 1400 Asia/Kolkata - 1630 Asia/Singapore
  • Emacs Berlin: Emacs-Berlin Hybrid Meetup https://emacs-berlin.org/ Wed Aug 26 1000 America/Vancouver - 1200 America/Chicago - 1300 America/Toronto - 1700 Etc/UTC - 1900 Europe/Berlin - 2230 Asia/Kolkata – Thu Aug 27 0100 Asia/Singapore
  • EmacsSF (in person): coffee.el in SF https://www.meetup.com/emacs-sf/events/316144053/ Sat Aug 29 1100 America/Los_Angeles
  • Sacha Chua: 27 août: Emacs Chat: Fabrice Niessen (en français, partie 2)
• Beginner:
  • My Advice for Users Wanting to Switch to Emacs | bardman's website
• Emacs configuration:
  • Raymond Zeitler: Emacs Numbered Backup Strategy (Irreal)
• Emacs Lisp:
  • What I learned about widget.el while building TextUI 0.2–0.5
  • Run Elisp code currently in reused sub-processes using futur (@monnier@oldbytes.space)
• Appearance:
  • TAONAW: Back to Solarized
  • Protesilaos: About Emacs themes, Solarized, and wallpapers
• Navigation:
  • Alvaro Ramirez: Focus windows across Emacs frames
• Writing:
  • emado: manage 100k+ markdown entries from Emacs at native speed (Reddit)
• Denote:
  • De-bloat Your Notes With Denote.el (17:42)
• Org Mode:
  • Org Mode requests: [RFC] org-colview: Determine column view scope once
  • Org Mode requests: [FR] Add org-delete-subtree without modifying the kill ring
  • Introduction to Org Mode (26:57)
  • Utilize texto puro para gerenciar seus hábitos (11:42)
  • Raymond Zeitler: How Much Management Does Knowledge Need?
  • Marcin Borkowski: Emphasizing a region in Org mode (Irreal)
  • Pretty titles for Org Mode buffers in Emacs - @joarvarndt.se on Bluesky
  • Using noweb syntax and elisp to manage host-specific dotfiles (Reddit)
  • Capture dotfiles using org-capture
  • Org-draw: Drawing inside org-mode using tl;draw (Reddit, YouTube 03:35)
  • [Notes] #3 OrgDevMeetup on Sat, August 15, 19:00 UTC+3 (recording, @yantar92@fosstodon.org)
  • Org development:
    • Suport for sentences for thing-at-point
    • lisp/ox-html.el: Add missing keywords and `#+OPTIONS:' in backend options-alist
• Coding:
  • A Tour of Magit's Status Interface (Reddit, @heiwiper)
  • Revisiting Flymake and Flycheck in GNU Emacs (as of Flycheck v39) (@chris_siebenmann@robot.villas)
  • Magit – Brief demo of "Instant Fixup" (01:22)
  • blog.fidelramos.net – Custom git trailers with Magit (HN)
    • Añadir nuevos git trailers a Magit
  • A Magit-inspired diff mode for Jujutsu (jj) (Reddit)
  • Magnus: Emacs salmagundi, 2026-08-13 - limiting treesit, using editable xref
  • omidmnz/quint-ts-mode: A Tree-sitter-based Emacs major mode for Quint · GitHub (@omidmnz@functional.cafe)
  • ediprolog — Emacs Does Interactive Prolog (27:24)
  • justjoheinz/wit-ts-mode: Emacs tree-sitter major mode for WIT (WebAssembly Interface Types) files · GitHub, also WAC (WebAssembly Composition) mode (Reddit)
  • Meta Redux: Projectile 3.4
• Shells:
  • emacs-run-command/run-command-runner-ghostel.el at ghostel · bricka/emacs-run-command · GitHub (@cabhan@social.tchncs.de)
• Web:
  • Andros Fenollosa: Web Design for Terminal Browsers (@andros@activity.andros.dev)
  • Andros Fenollosa: Elpher: my tweaks for better Gemini browsing in Emacs (@andros@activity.andros.dev)
• Mail, news, and chat:
  • Update Reddigg is now a fullblown reddit client (Reddit)
  • Elfeed performance improvements (@minad@mastodon.world)
• Multimedia:
  • Uniline goes 2.5 Dimensions
• Fun:
  • Corwin Brust: Emacs Card Games on MELPA
• LLMs:
  • New package: reviewer.el (Reddit) - temporarily annotating files or diffs without modifying the contents
  • Demo: Browse the web in the Emacs Web Browser by using LLMs to live-rewrite the page's source. (Reddit)
  • Alvaro Ramirez: agent-shell 0.73 updates (Reddit, HN)
• Community:
  • Fortnightly Tips, Tricks, and Questions — 2026-08-11 / week 32
  • Chris Maiorana: The Emacs pastoral tradition (YouTube 11:22, Reddit, Irreal)
  • Prot Asks: Oliver about minimalist life, distractions, independence, and more (03:53:38)
  • Sacha Chua: Emacs Chat 28: Fabrice Niessen (en français) (YouTube 59:40)
  • TAONAW - Emacs and Org Mode: RSI and Emacs: When Your Pinky Says Enough is Enough
• Other:
  • [eaf]「ebook-viewer」 Super Fast & Support Native Calibre's ebook-viewer on emacs. (Reddit)
  • Irreal: Emacs Development: Ongoing And Good
  • The Emacs Cat: Emacs, Dired, and Ubuntu 26.04 (Irreal)
  • compiling emacs from source (for max performance) (13:51)
  • Emacs Window Manager EWM.el (23:21)
• Emacs development:
  • emacs-devel:
    • Continuation of long discussion about difficulties compiling older versions
  • New value 'with-completions-popup' of 'icomplete-in-buffer' (bug#81537)
  • New image type canvas (Reddit, HN, @divyaranjan@mathstodon.xyz)
  • cperl-mode.el: Support Perl 5.44: named parameters in signatures
  • Flymake: rework inline diagnostic text annotations
  • Preview the replacement text while it is typed (bug#81583)
  • Reimplement `outline-occur' using Xref and match Outline headings
• New packages:
  • annotated-completing-read: Ergonomic completing-read wrapper/helper (MELPA)
  • auto-side-windows: Simplified buffer management for side windows (MELPA)
  • card-games: Play card games (console UNICODE and graphical SVG) (MELPA)
  • codex-ide: Run Codex CLI in a terminal (NonGNU ELPA)
  • hermes: Emacs frontend for Hermes Agent (NonGNU ELPA)
  • ob-janet: Org-Babel support for the Janet language (MELPA)
  • pgsql: Native PostgreSQL protocol client (MELPA)
  • project-store: Project backend for Nix store (NonGNU ELPA)
  • vice-mode: VIm-like Commands Extension (MELPA)

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

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

I’ve been doing so much Emacs writing lately, so I guess it’s time I get my Emacs pinky (which is a form of RSI). I made a quick reference to it three days ago and got a lot of responses.

What happened?

I started to feel a strain last week, but at first I didn’t think much about it. Sometimes my pinky rests awkwardly on the keyboard because I’m used to using the Caps Lock key, but it’s usually a hand-position issue. After I readjust and let my pinky rest, it goes away.

This time the strain didn’t go away, and my pinky kept rebelling.

My keyboard, Kinesis Freestyle Edge (the one here is the RGB+, the original RGB is discontinued), has a prominent Caps Lock key that just screams “use me as control!” For years, that’s what I did. As you can see in the picture, with my pinky resting on it.

The last week has been busy. I didn’t leave my small Manhattan apartment for two days, working straight from morning to evening, then gaming and sleeping. This isn’t normal for me and has taken a toll on my hands, and the RSI got worse.

I think my new screen also exacerbated the problem somehow. It’s much bigger and has higher resolution, which I’m still adjusting to by how I sit and how I move my head and neck. I also have a standing desk I usually use in its standing position in the morning, when I write these posts or work on projects — these are easily my longest writing sessions, sometimes going for two hours straight without a break, especially in the last couple of weeks, and that’s all Emacs and pinky work.

When I thought about Emacs pinky in the past, I mostly thought of it with a smirk. I mean, it’s your pinky. How can you not read a comment about someone having their little finger hurt and not chuckle a bit? But folks, let me tell you, once you have it, you realize how much you depend on that one small finger, especially as an Emacs user.

My work, my organization, even my gaming in the evening (as it turns out), it’s all going through that little finger. Sure, it’s my “fault” for using Emacs, but if you’ve been reading this blog for a while you’d know that I owe many things to Emacs (including, among other things, my current job).

What am I doing about it?

For now, I’ve started using the keyboard’s dedicated control key again and changed how I use my hands. I try to use my right thumb, all the way to the side from the home row (my keyboard is huge, I will get to that in a minute) for when I need to use the left side of the keyboard, and then fold my pinky and use my knuckle to press it when I need the left control, for when I use the right side of the keyboard, as you can see in this picture:

This adjustment is the easiest, since I know where these Control keys are by muscle memory. I turned off my Caps as control on my Mac to make sure I don’t get tempted to go back to my old habit. It’s been working OK, and that’s what I’m doing right now for writing this post.

Other Emacs users have suggested several things, and I’ve been considering and trying a few of them.

god-mode came up a couple of times. It creates a chord (two keys pressed at once) key binding that triggers a control press. For example, sd, and then xs (separately) to save a file in Emacs — same as C-xC-s. This can be useful, but it has two problems.

The obvious one is that this shortcut works only in Emacs. When I don’t use Emacs, which happens more often than I’d like for work, I have to use the OS shortcuts. Caps is so ingrained in my fingers’ memory that I just use it all the time, but now I need to start thinking of other options. I could probably program the keyboard’s firmware to do something similar, but that’s a topic in itself — and if I do that, I don’t need god-mode anyway. Another odd issue is that it doesn’t work on my Mac. It throws a GCC error, which from what I gather has to do with Emacs internals and how it works (or doesn’t work in this case) with its internal compiling mechanisms. Yes, I tried the fix, which doesn’t seem to work well with Homebrew, and I gave up on it.

There are other packages like god-mode, but I think the next one I’m going to try is Xah Fly Keys, because what he’s after seems to make sense to me. Which brings me to the next point: a new keyboard.

New Keyboards

I’ve been considering a new keyboard for a while, and the RSI has sped up the process. I’ve looked at a couple reviews and YouTube videos in the last couple of days. Kinesis, my current keyboard brand, is a known name in the ergonomic keyboard world, but after checking out their Advantage 360 I’m not sure I’m sold. It’s an excellent premium-looking keyboard, but it’s having a huge and heavy keyboard again. My hands are small, and I’m not sure I want to commit to another expensive giant, especially when I already struggle with room for the mouse, especially when the two halves are spread apart for the shoulders. I already compromise on this, and my chest is closer than it should be. I also think that for the price of these keyboards (over $400), I might want to take them with me when I go to the office, and with a Kinesis keyboard, this is not going to happen. Another thing I’m considering is going wireless, because of my USB switch setup. It can take my Linux Desktop or the Mac up to 30 seconds to detect the keyboard when I switch, which is small, but still annoying. The mouse, connected by a Bluetooth dongle, takes a second to switch over.

The above reasons, and Xah’s reviews, landed me on Glove80, which is even a weirder-looking keyboard. This keyboard takes ergonomics further (or just looks crazier, if you’re not into those). It’s wireless and lighter, which means taking it with me makes more sense, and will hopefully fix the USB lag issue. It has keywells for the fingers, which is basically a “dip” or a bowl (hence the name) that curves downwards so your fingers, which are naturally curled on a keyboard, are resting downwards. It has its own super-light switches, which, while I don’t think I need them, are another example of thinking of RSI and finger pain.

Going further with light keyboards, there’s the Voyager, which is tiny, lighter, and minimal. It’s not wireless, but it’s meant to be mobile, and it’s probably the best one for small hands. However, the Voyager only has 52 keys. It’s meant to be used with layers — meaning, there’s a modifier key that creates another “layer” of keys, which makes your Alt act as Ctrl, for example. I’m not sure I’m sold on this idea, especially when we’re talking Emacs. If I’m already challenged by my lack of Caps Lock, I can only imagine how much time I will have to sink into this keyboard with its layers and grid layout (which the Glove80 has too, by the way) to become efficient with it. I also think the Keywell is something I could use, so I have a rough idea of what I want to try next.

The problem with the Glove80 is that you can’t really try it out. They have a 30-day return policy, shipping not included, and they’re in New Zealand. A keyboard like that takes time to get used to, and 30 days for a $ 400-plus keyboard requires a level of confidence in the product I don’t have yet.

My conclusion so far

All in all, I think what I’m looking at is a combination of adjustments rather than one solution. I need to get used to the idea of different key bindings, be it something like god-mode or Xah Fly Keys, which will make it easier to use with a new keyboard and would also be beneficial now, until I get it. The idea of layering is a bit daunting, but I can see the wisdom in it, especially after I got an email back from BSAG, who was kind enough to share her experience with me (she’s the one who told me about the Voyager keyboard).

It will be a while before I buy a new keyboard, then it will take some time to get here, and then it will take me even longer to get used to one. I’m not looking forward to having my typing hindered even further, especially because I’m so dependent on writing notes all the time, but it’s also because of it that I have to do it. This is one thing I know I need to do.

First melpa release evah \o/

Thanks to many for patience and coaching, and card-games.el 1.0.92 (pre-release #2, MELPA) is available from package-install for users of MELPA. Release announcement after the cut..

Grown from experimentation within Dungeon, thank you to contribs there, and for review comments from ricsy putting toward MELPA got rid of some advices forcing very interesting better ways. The hooks approach makes the registered card-games-bid-submit a generic semaphore, for example to interlink with a process, CRDT via an adaptor, or … in present v1.0.92 (unstable): https://melpa.org/#/card-games

In the part 2 I described how, for a particular project with certain naming conventions, I wanted to use emacs tree-sitter font-locking to highlight variables that might be used in the wrong context:

I found a way to make it work for simple expressions but it was relying on regular expression matching rather than tree-sitter parse trees. I set a goal of handling these types of expressions:

elevation_t[t]           // good
elevation_t[r]           // bug
elevation_t[t_from_r[r]] // good
elevation_t[r_from_t[t]] // bug
elevation_t[obj.t]       // good
elevation_t[obj.r]       // bug
elevation_t[t_from_r(r)] // good
elevation_t[r_from_t(t)] // bug
elevation_t[x.t_fn(x)]   // good
elevation_t[x.r_fn(x)]   // bug
elevation_t[x.t_arr[i]]  // good
elevation_t[x.r_arr[i]]  // bug
elevation_t[(t)]         // good
elevation_t[(r)]         // bug

What are my options for using tree-sitter to handle more cases? I decided to try the :pred feature of tree-sitter font lock. Using M-x treesit-explore-mode, I learned that the subscript expression looks like:

(subscript_expression 
   object: (_) 
   [
   index: (_)
   ]
)

That means I can match it with a rule that captures both the array and index as separate nodes:

(defun amitp-check-subscript (array index)
  (message "debug: %S %S" array index))

(defvar amitp/treesit-font-lock-typescript-indexing
  (treesit-font-lock-rules
   :language 'typescript
   :feature 'semantic-identifier
   :override t
   `(((subscript_expression
       object: (identifier) @array 
       index: (expression_statement) @index 
       (:pred amitp-check-subscript @array @index))))))

Those two arguments are treesit parse nodes. What can I do with them? The emacs manual has a page about how to navigate the parse tree and another page about querying the parse tree. In the docs found a function treesit-query-capture that can pattern match on a node and extract the parts.

I used that function to look for the identifier that most likely tells me what geometry type is being returned (r for region, s for side, t for triangle). Examples:

• in t_foo_r(r), the identifier t_foo_r tells me this is likely a t (triangle)
• in t_obj[i].r_elevation, the identifier r_elevation tells me this is likely an r (region)
• in map[i].s_inner_t(t_queue[0]), the identifier s_inner_t tells me this is likely an s (side)

I think this is where tree-sitter can do better than regular expression based matching. I wrote a function to find the key identifier:

(defun amitp/treesit-top-typescript-node (node)
  "Try to find the identifier that represents a node's return value"
  (let ((results
         (treesit-query-capture
          node
          '(((identifier) @identifier)
            ((member_expression property: (property_identifier) @property))
            ((subscript_expression object: (_) @expr))
            ((call_expression function: (_) @expr))
            ((parenthesized_expression (_) @expr))))))
    (if (assoc 'expr results)
        (amitp/treesit-top-typescript-node (cdr (assoc 'expr results)))
      ;; prefer the property if tree-sitter matches both
      (or (cdr (assoc 'property results)) (cdr (assoc 'identifier results))))))

I wrote a function detect a mismatch:

(defun amitp-check-subscript-mismatch (array index)
  ;; note: my usual naming convention is amitp/foo but tree-sitter won't accept that
  (let* ((array-name (buffer-substring (treesit-node-start array) (treesit-node-end array)))
         (top (amitp/treesit-top-typescript-node index))
         (index-name (buffer-substring (treesit-node-start top) (treesit-node-end top))))
    (and
     (or (= (length array-name) 1) (equal "_" (substring array-name -2 -1)))
     (or (= (length index-name) 1) (equal "_" (substring index-name 1 2)))
     (not (equal (substring array-name -1) (substring index-name 0 1))))))

Then I used the tree-sitter :pred feature to only highlight if there's a mismatch:

(defface array-error)
(defface index-error)

(defvar amitp/treesit-font-lock-typescript-indexing
  (treesit-font-lock-rules
   :language 'typescript
   :feature 'semantic-identifier
   :override t
   '(((subscript_expression
       object: (_) @array-error
       index: (_) @index-error
       (:pred amitp-check-subscript-mismatch @array-error @index-error))))))
     ;; todo: add call_expression

Does it work? Yes!

But there's something a little weird here. Why do r+1 and 1+r get flagged even though I never actually handle binary operators in my amitp/treesit-top-typescript-node function? Something to investigate later.

The next feature I wanted was to highlight only the "type" character instead of the entire identifier. I couldn't figure out how, so I asked on Reddit, where /u/eleven_cupfuls gave me a solution: the @face-name can be a @function-name instead. Thank you!

Instead of using :pred to tell font-lock whether to highlight something, I need to highlight it myself. I changed the treesit font lock rules to call my function instead of applying a face:

(defvar amitp/treesit-font-lock-typescript-indexing
  (treesit-font-lock-rules
   :language 'typescript
   :feature 'semantic-identifier
   :override t
   '(((subscript_expression) @amitp-highlight-subscript-mismatch)
     ((call_expression) @amitp-highlight-subscript-mismatch))))

My function now receives the entire expression instead of receiving the array and index parts separately like the :pred version. So I need to find a way to extract the right information. I can use treesit-query-capture like before, right?

It was at this point that I learned treesit-query-capture pattern matches against the entire tree and not only the top node. That explains why it was finding r+1 and 1+r. It was looking for any identifier anywhere in the subtree. Oops.

I rewrote amitp/treesit-top-typescript-node to use treesit-node-type instead of treesit-query-capture:

(defun amitp/treesit-top-typescript-node (node)
  "Try to find the identifier that represents a node's return value"
  (pcase (treesit-node-type node)
    ("identifier" node)
    ("member_expression" (treesit-node-child-by-field-name node "property"))
    ("subscript_expression" (amitp/treesit-top-typescript-node (treesit-node-child-by-field-name node "object")))
    ("call_expression" (amitp/treesit-top-typescript-node (treesit-node-child-by-field-name node "function")))
    ("parenthesized_expression" (amitp/treesit-top-typescript-node (treesit-node-child node 1)))
    (_ nil)))

It would've been cleaner if pcase could pattern match against these nodes, but it's not too bad.

And then I wrote a new amitp-highlight-subscript-mismatch function to analyze subscript nodes (and function calls too) to make sure the names match:

(defun amitp-highlight-subscript-mismatch (node override start end &rest _)
  "Highlight mismatching variable names in amitp's geometry mesh code"
  (let* ((parts (pcase (treesit-node-type node)
                  ("subscript_expression" (list (treesit-node-child-by-field-name node "object")
                                               (treesit-node-child-by-field-name node "index")))
                  ("call_expression" (list (treesit-node-child-by-field-name node "function")
                                           (treesit-node-child
                                            (treesit-node-child-by-field-name node "arguments")
                                            1))))))
    (when parts
      (let* ((array (nth 0 parts))
             (index (nth 1 parts))
             (array-name (treesit-node-text array))
             (top (amitp/treesit-top-typescript-node index))
             (index-name (or (treesit-node-text array) ""))
             (face (if (and ;; todo also check (>= (length index-name) 1)
                        (or (= (length array-name) 1) (equal "_" (substring array-name -2 -1)))
                        (or (= (length index-name) 1) (s-match "[_0-9]" (substring index-name 1 2))))
                       (if (equal (substring array-name -1) (substring index-name 0 1))
                           'index-good
                         'index-bad)
                     nil)))
        (when face
          (treesit-fontify-with-override (- (treesit-node-end array) 2) (treesit-node-end array) face override)
          (treesit-fontify-with-override (treesit-node-start top) (min (treesit-node-end top) (+ 2 (treesit-node-start top))) face override))))))

It's a little bit long but it seems to work:

However, there are things I haven't figured out, like why certain expressions don't trigger the (subscript_expression) font lock rule:

r => mesh.foo_r[r]);     // matches
(r => mesh.foo_r[r]);    // matches
foo(mesh.foo_r[r]);      // matches
foo(r => mesh.foo_r[r]); // doesn't match

That's a problem for another day. I also want to:

1. apply these rules only to files in which I use that naming convention
2. tighten the matching to apply only to the letters r, s, t
3. remove the green "it's ok" color and only leave the red "warning" color

This was a fun adventure. I'm not sure this is the best approach but it was a nice excuse to play with emacs tree-sitter.

In the part 1 I described my initial attempt at customizing font-lock using Emacs 29 tree-sitter. Regular font locking uses regular expression matching. Tree sitter allows combining regular expression matching with parse tree matching, like "variable declaration" or "function call". The ideas I came up with were mostly things that I could have implemented with regular expressions alone, but I wanted to experiment with the tree sitter approach. Here's the effect of conventional highlighting, using color for keywords and other syntax:

I wanted to instead mark variable names. In some projects I'm working with geometry, and I sometimes make mistakes putting the wrong variables together. I decided to mark horizontal and vertical variables differently. First, I defined a regular expression to guess that a variable represents something "horizontal":

(defvar amitp/regexp-horizontal-identifiers
  (rx
   (seq
    string-start
    (or "x" "dx" "width" "left" "right" "q" "col" "cols" "columns")
    (zero-or-more digit)
    string-end)))

(defvar amitp/regexp-vertical-identifiers
  (rx
   (seq
    string-start
    (or "y" "dy" "height" "top" "bottom" "up" "down" "r" "row" "rows")
    (zero-or-more digit)
    string-end)))

I had started out with a string regexp but switched to the rx syntax. Over time I added more patterns to this, including all caps and camelcase patterns.

Unlike regular expression font locking, I can limit these regular expressions to match within certain types of parse tree nodes:

(defvar amitp/treesit-font-lock-typescript-axis-variables
  (treesit-font-lock-rules
   :language 'typescript
   :feature 'semantic-identifier
   :override t
   `(
     ([(identifier) (property_identifier) (shorthand_property_identifier_pattern)]
      @variable-horizontal-face
      (:match ,amitp/regexp-horizontal-identifiers @variable-horizontal-face))
     ([(identifier) (property_identifier) (shorthand_property_identifier_pattern)]
      @variable-vertical-face
      (:match ,amitp/regexp-vertical-identifiers @variable-vertical-face))
     )))

(add-hook
 'typescript-ts-mode-hook
 (lambda ()
   (setq-local treesit-font-lock-settings
               (append treesit-font-lock-settings
                       amitp/treesit-font-lock-typescript-axis-variables))))

I think the restriction doesn't help much in this case, but it was fun learning how to use treesit-font-lock-rules for this. Here's the result:

Do you notice the bug?

This was a fun experiment. But it's a bit too noisy, especially if I have both variable and syntax highlighting. I think it'd be better if I could highlight only the problematic subexpression (the y2-dx). I decided to try it with a simpler problem.

In some of my projects, I use geometry meshes that have integer IDs for regions (r), sides (s), and triangles (t). I want to avoid bug where an array is indexed by a triangle ID, but I accidentally index it by a triangle ID. Some languages have a feature called "newtype" to make these separate types, but I don't have them in Javascript. Instead, I use a naming convention to help me catch these:

• x_foo is a value storing type x
• x_foo_y is a function or array indexed by type y and stores values of type x

I was hoping to use tree-sitter to find subscript expressions, and then check if the array name ends with the same type _x as the index expression x_ starts with. I implemented it for simple cases:

(defvar amitp/treesit-font-lock-typescript-indexing
  (treesit-font-lock-rules
   :language 'typescript
   :feature 'semantic-identifier
   :override t
   `(((subscript_expression) @error
      (:match "_r\\[_?[st]\\|_s\\[_?[rt]\\|_t\\[_?[sr]" @error)))
   ))

And it does work:

However, tree-sitter plays almost no role in this. The real work is done by the regular expression. It doesn't catch these cases:

elevation_t[obj.t]       // good
elevation_t[obj.r]       // bug
elevation_t[t_from_r(r)] // good
elevation_t[r_from_t(t)] // bug
elevation_t[x.t_fn(x)]   // good
elevation_t[x.r_fn(x)]   // bug
elevation_t[x.t_arr[i]]  // good
elevation_t[x.r_arr[i]]  // bug

How would I also handle these cases? I attempted it, but it took more time than I had originally planned for, so that'll be in part 3.

A few years ago I blogged about custom tree-sitter-based syntax highlighting in emacs. I started out with highlighting certain keywords in red. I wanted to show the keywords that interrupt control flow:

I highlight regular keywords (while, if) in bold. I highlight control flow interrupting keywords (return, continue) in red.

That's syntax highlighting.

But I also wanted to highlight names based on their meaning.

In some projects I'm working with horizontal and vertical measurements, and I thought it would be nice to highlight those variable names differently. In some projects I'm working with Delaunay+Voronoi meshes, and I wanted to highlight the triangles, edges, and polygons differently. In some projects I'm working with hexagonal grids, and I wanted to highlight the three axes differently, like I do in my guide to hexagonal grids. In some projects I am working with html+js mixed code, and I wanted to highlight the html vs js differently, like I do in my tutorial on how I write interactive tutorials.

In that blog post from a few years ago, I had used emacs tree-sitter mode to implement this type of highlighting. Since then, emacs has incorporated its own tree-sitter mode, which works differently from the third party package. I decided to update my code to work with the new tree-sitter functions.

Let's start with highlighting keywords. This doesn't really need tree sitter mode, but I'm using it because I want to highlight more in part 2 of this post. The treesit-font-lock-rules function compiles tree sitter patterns into some internal format. Since the set of keywords is different per language, I'm going to make one variable per language. Here's the one for Python:

(defface amitp-control-keyword-face)
(defvar amitp/python-treesit-settings
  (treesit-font-lock-rules
   :language 'python
   :feature 'keyword
   :override t
   '(
     (["assert" "await" "break" "continue" "finally" "raise" "return" "yield"]
      @amitp-control-keyword-face)
     )
   ))

This will highlight those keywords in my amitp-control-keyword-face instead of the default font-lock-keyword-face.

A minor note — I had tried reusing my previous tree-sitter face names, which were named with periods (variable.horizontal) and colons (amitp:keyword), but I ran into some errors, so I switched to only using dashes (variable-horizontal) for the new tree sitter modes.

I then have to install these highlighting rules into treesit-font-lock-settings, which is a buffer-local variable. So I install it from a hook:

(add-hook 'python-ts-mode-hook
          (lambda ()
            (setq-local treesit-font-lock-settings
                        (append treesit-font-lock-settings
                                amitp/python-treesit-settings))))

That's all it took to get my keywords highlighting the way I wanted. But wait, there's more!

I had noticed that type aliases didn't highlight the way I wanted. Here's the screenshot:

The keyword type isn't being highlighted here. I could add it as a keyword like the others:

(defvar amitp/python-treesit-settings
  (treesit-font-lock-rules
   :language 'python
   :feature 'keyword
   :override t
   '(
     (["assert" "await" "break" "continue" "finally" "raise" "return" "yield"]
      @amitp-control-keyword-face)
     (["type"] @font-lock-keyword-face) ;; <-- added
     )
   ))

Alternatively, I could modify python.el's python--treesit-keywords to include "type".

However, unlike other keywords, type is a soft keyword in Python, not a full keyword. That means it can be used in other contexts such a function call:

I don't want to highlight those uses. I used M-x treesit-inspect-mode to learn the tree-sitter parse tree context. And then I made the rules highlight the word type only when it occurred in the context of defining a type alias:

(defvar amitp/python-treesit-settings
  (treesit-font-lock-rules
   :language 'python
   :feature 'keyword
   :override t
   '(
     (["assert" "await" "break" "continue" "finally" "raise" "return" "yield"]
      @amitp-control-keyword-face)
     ((type_alias_statement "type" @font-lock-keyword-face)) ;; <-- added
     )
   ))

Here's the result:

This is one of the nice things I get by using tree-sitter highlighting instead of regex highlighting.

I also changed import statements to be highlighted the way I want, by marking import NAME and from name import NAME in a different face:

  (treesit-font-lock-rules
   :language 'python
   :feature 'definition
   :override t
   '(
     ((import_statement name: (dotted_name (identifier) @font-lock-variable-name-face)))
     ((import_from_statement module_name: (dotted_name (identifier))
                             name: (dotted_name (identifier) @font-lock-variable-name-face)))
     )

I'm still experimenting to figure out what rules I want to have. I try things and then delete some of them. I've found M-x treesit-inspect-mode to be quite useful.

In part 2 I'll explore heuristics to highlight based on variable names I commonly use.

Raymond Zeitler over at Ray on Emacs doesn’t use version control for his “non-public” files so when he had a problem with his .emacs file, he didn’t have any backups except for the single last version of a file that Emacs will make automatically if you have backups enabled. That, apparently, was enough to recover but Zeitler resolved to do better.

What he did was to replace .emacs~ with .emacs.~1~, which causes Emacs to create a numbered sequence of backups rather than simply overwriting the last one. Reading his post reminded me of my backup scheme, which I haven’t thought about in years because all my files—except autogenerated ones—go into Git.

My backup scheme is a little different from Zeitler’s because I’ve set mine to keep only the last two backups. That way, my file system doesn’t fill up with long forgotten and unneeded backups. Even so, there were a lot of backups—some for files that don’t even exist anymore—taking up a lot of space. I deleted them all and started over.

I don’t claim that 2 is the right number for everyone or even for me. It just seemed like a safe number in case something happened with Git. Happily, I’ve never had to use the backups, which is why I’d mostly forgotten about them.

One thing for sure, you need to be religious about either saving your files to a version control system or configuring the Emacs backup system to automatically save some number of backups for you.

Historically, I've only ever known two great ways of focusing Emacs windows: the built-in other-window command, which cycles through all the available windows, and the ace-window package, offering random window access. It's not that there aren't more or better ways, I just didn't look any further as these were enough for my needs.

While I really wanted to make ace-window my default choice, for whatever reason, it never stuck. other-window with a custom M-o binding always felt like the smoother fit for my limited needs. You see, I hardly ever have more than two visible windows, so whenever ace-window kicked into action (for 3 or more windows), it often took me by surprise. The one area other-window didn't fit my needs revolved around focus requiring visual feedback, but I eventually solved that with winpulse (a little package I wrote).

As you can see, I'm a simple man using few Emacs windows, and when it comes to frames, I almost never use more than one. That is until somewhat recently, when I built ytr, a tiny YouTube radio player that sits in the corner of your frame. While it all feels fairly integrated into your frame, under the hood, ytr renders in a separate frame. This broke my trusty other-window flow. I couldn't just focus my radio window using my well-internalized M-o binding.

Turns out, other-window actually caters for focusing windows across frames, but only when invoked programmatically. Sure, I can wrap it with my own custom command, but Emacs already had me covered. I found the built-in next-window-any-frame command. All I had to do was bind it to M-o and Bob's your uncle.

I can now switch between my current window and my YouTube radio, with my dear M-o binding. Balance restored.

Chris Maiorana has a lovely blog post in which he makes the case that Emacs users are a different breed. He starts with the quotidian observation that you can be pretty sure that a Vim or VSCode user is either a software developer or in a closely related such field such as System Administration or DevOps. Emacs users, on the other hand, could come from almost anywhere.

This is a point that Irreal is fond of making. I’m fascinated by people from outside the software field who use Emacs as an essential part of their workflow. Their stories always illustrate the power and flexibility of Emacs to solve problems even if they aren’t about software and engineering.

What distinguishes Emacs users, Maiorana claims, is their love of tinkering and the blurring of work and play when they’re using Emacs. As he puts it

Emacs could be more than a text editor. It could be an organizer, a scratchpad, a dictionary, a canvas, a database, a calendar, an email client, and much more. What should have been work started to feel like fun.

Maiorana says that Emacs users don’t care primarily about the usefulness or user friendliness of Emacs; it’s the opportunity for tinkering that attracts them. I think he has this part backwards. Emacs users surely do love to tinker but the attractive thing about Emacs is that your tinkering can turn it into the exact tool that you need. That’s true even if the tool you need has nothing to do with software or its siblings.

Emacs is, in fact, the perfect piece of software. Not only does it indulge our urge to tinker and have fun but also allows us to turn that tinkering into the precise tool we need. Not just once but as often as we desire as our needs change. With Emacs, the fun never ends.

Elpher is the Gemini browser for Emacs. It works wonderfully and its integration with GNU's editor is sublime. You don't just move between capsules: you can also write your own scripts or build automated flows. It's Emacs, after all. Everything bends to your will.

If you still don't know what Gemini is, it's a minimalist protocol, halfway between the web and Gopher, with no JavaScript and no trackers. I cover it in depth in Introduction to the Gemini protocol.

Today I want to share a minimal configuration I use to browse more comfortably. Nothing exotic, just a few shortcuts and a couple of tweaks that make a difference day to day.

Elpher is on MELPA. I declare it with use-package, so everything stays in a single block: :ensure t installs it the first time, :config defines the function and sets the protocol, and :bind keeps the shortcuts encapsulated. Paste this into your init.el.

;; ===
;; elpher - Gemini and Gopher client
;; https://thelambdalab.xyz/elpher/
;; ===
(use-package elpher
  :ensure t
  :config
  ;; Smart link following that handles emojis
  (defun elpher-smart-follow ()
    "Smart link following that handles emojis."
    (interactive)
    (let ((current-pos (point)))
      (beginning-of-line)
      (if (re-search-forward "=>" (line-end-position) t)
          (elpher-follow-current-link)
        (goto-char current-pos)
        (elpher-follow-current-link))))

  ;; Gemini as the default protocol instead of Gopher
  (setq elpher-default-url-type "gemini")

  :bind
  (:map elpher-mode-map
        ("RET" . elpher-smart-follow)      ; follow link, emoji-aware
        ("l" . elpher-back)                ; back, same as eww
        ("n" . elpher-next-link)           ; next link
        ("p" . elpher-prev-link)           ; previous link
        ("b" . elpher-bookmark-current)))  ; bookmark, same as eww

What does all this give you? A few improvements you notice right away:

• n to jump to the next link.
• p to go back to the previous one.
• l to return to the previous page, just like in eww.
• b to save the current page as a bookmark, just like in eww.
• It widens the clickable area of each link, so you can click on the emojis and not only on the text.
• It sets Gemini as the default protocol instead of Gopher.

Watch out with elpher-smart-follow: it reassigns RET. If you already had that key mapped to something else inside elpher-mode, this overrides it.

That last note about emojis seems trivial, but it changes the experience a lot. Many capsules decorate their links with an emoji in front, and if you try to follow them from there, Elpher just sits still. With elpher-smart-follow it no longer matters where the cursor is on the line: if there is a =>, it takes you there.

And this is only the beginning. Elpher is Lisp, and Lisp bends to whatever you need: today it is four shortcuts, tomorrow a flow that opens your favorite capsules when Emacs starts. Tinker with it, break it, make it yours.

Help me keep writing Every coffee gives me a push toward the next article. Sure, it's on me!

Send an email to comment+article-b18ae804@andros.dev to leave a comment. The subject will be ignored.

This month's Emacs Carnival theme is The Search For Knowledge, which is kinda something near and dear to my heart. I wrote an Obsidian to Emacs post from a little over a year ago and one of the things that I mentioned is that Obsidian has a Knowledge Graph that I didn't use. denote-explore does have one and I set graphing up once but I don't use it at all. I work just fine without a Knowledge Graph. Using Denote, ripgrep, and consult, things work great for me. It's smooth and not a lot of fuss.

I literally do all my knowledge management now within Emacs in a Denote system. I dump all of my notes into one folder in org format. Denote puts a time stamp on the file name as well as the title and the tags. Searching by tag is really just a filename search. See examples from my own denote folder:

20260714T130657--org-agenda-views__orgmode.org
20260714T100032--filtering-org-ql-results__orgmode_productivity.org
20250605T091129--escape-character-in-orgmode__orgmode.org

For me the file name is the index. It's simple. I don't need a SQLite database or anything else on the backend. As soon as I create a file I know that I can search by the file name or search its contents. This keeps things simple and, for me, simple is good. When I want to search for all of my notes about orgmode, I just run my mh/consult-denote-find-files , type orgmode and all of those files appear. If I want to add something else to that search, I just type that in. Here is my simple function that does that, using consult-find

(defun mh/consult-denote-find-files ()
  "Find files in the Denote notes directory by name via `consult-find'."
  (interactive)
  (consult-find (car (denote-directories))))

So that brings up the files using the wonderful consult-find format. I just keep typing to narrow down my search. Easy and effective.

And inside the files, the denote tags are the same as org mode tags when the document is open since it uses the TAGS property on the top of the file. I generally use just ripgrep for that – see the function I use below:

  (defun mh/rg-org-wiki ()
  "Search ~/org-wiki with ripgrep via `consult-ripgrep'.
Follows symlinks and ignores JSON files."
  (interactive)
  (let ((wiki-dir (expand-file-name "~/org-wiki")))
    (if (file-directory-p wiki-dir)
        (let ((consult-ripgrep-args
               (concat consult-ripgrep-args " --follow --glob=!*.json")))
          (consult-ripgrep wiki-dir))
      (message "Directory ~/org-wiki does not exist!"))))

(yes, my denote files are in a folder called org-wiki. That actually dates back to a pre-Obsidian setup I had once. This function actually dates back to that but it's easy to reuse here. Again, another win for Emacs and simplicity)

I do have denote-explore installed and I do use denote-explore-random-note to, well, explore my notes. I find things that I forgot, and find things to update. I use that generally when I just want to work in my notes for a while.

But that is the exception and not the rule. I set up links to explore my notes. Using the example files above, I use denote-link to link to a top-level OrgMode note (since they're all about OrgMode). That note is kind of a Map Of Content about OrgMode. That is how I want to discover notes… the individual notes link to top-level notes and that note is linked to all else about OrgMode. Well that is the theory anyway… I set it up but I don't do it near as much as I thought I would. This goes back to how I used Obsidian. I tried really hard to use a very rigid and disciplined link structure and at the end I find I didn't use it. It took more time than writing a lot of my notes. So really my flow is – I find and read notes that my past self used and update them to what I currently think but I don't necessarily follow a web of links. While a graph is useful for a lot of people, it just doesn't seem as useful for me. The filename is a good enough index for me.

Another month, another agent-shell update. If you missed the last one, have a look at the 0.63 update. While this post showcases the latest highlights, the full list of changes is far chunkier than what we'll cover.

What's agent-shell?

agent-shell is a native Emacs mode to interact with AI agents powered by ACP (Agent Client Protocol).

agent-shell enters the chat

Since inception in September last year (yikes nearly a year), agent-shell has featured a shell-like experience, powered by comint mode. There's also viewport mode (via agent-shell-prefer-viewport-interaction), if you prefer a more focused experience, and now we have chat mode.

Chat mode fuses comint mode with a more traditional chat-like labelling experience.

We're living on the edge here, so chat mode is now enabled by default. Ok not really that edgy, it's fairly safe (powered overlays) and can be disabled entirely via (setq agent-shell-chat-mode-enabled nil). Chat mode itself is a minor mode, so you can always toggle it on and off via M-x agent-shell-chat-mode.

A little more chatter

In the last post, we talked about making agent-shell less chatty with more grouping for the likes of tool calls and agent thinking, all collapsed by default. If that's far too quiet, you can expand by default via (setq agent-shell-activity-group-expand-by-default t). If you found these two settings either too quiet or too chatty, we now have a third alternative via (setq agent-shell-activity-group-expand-by-default 'latest). When set, only the latest grouped activity is expanded by default, and automatically collapsed when the agent moves on to something else.

I've become quite fond of this feature (thank you @nhojb for the PR), so yes. It's also enabled by default.

Prompt queueing

Queuing received some improvements. The related commands have been consolidated under agent-shell-prompt-queue.el. You can queue prompts while the agent is busy, then view, resume, or drop pending prompts via M-x agent-shell-prompt-queue, M-x agent-shell-prompt-queue-resume, and M-x agent-shell-prompt-queue-remove. The pending queue is now shown after each new submission.

Compose from anywhere

M-x agent-shell-prompt-compose opens a dedicated buffer for crafting a prompt, and it's now more independent of the shell. You can invoke it from any buffer (it resolves to the right shell), C-c C-c sends and returns you to whatever you were doing (fire and forget), and C-u C-c C-c submits the prompt and immediately lets you craft another queued prompt.

Start typing sooner

Shell initialization may take a second or two, depending on what agent you're using, which meant you had to wait for initialization before you could start typing into your new shell. Unnecessary, so that's no longer the case. Shell prompts are now offered as soon as possible, so one can get typing.

Markdown lists

While Markdown lists are easily digestible without special rendering, we can do better than that, so we now give them a better treatment with normalized padding, indentation, and of course, civilized bullets.

TAB navigation improvements + hints

TAB navigation made it into agent-shell fairly early on. I love being able to TAB my way into any section in the buffer and press RET to toggle folding. That's great and all, but we can make the navigation experience richer by welcoming the likes of Markdown source blocks, links, and images to the navigation party. Why these in particular? They are all actionable by RET too, of course.

While you'd rightly assume RET opens links to local text files in Emacs and delegates to browsers when needed, Markdown source blocks and images get a similar treatment. While their respective RET actions may not be as obvious, we can certainly make them much more discoverable, so we now add hints. Landing point on an actionable item now echoes a hint of what you can do and which key does it (say, "Press RET to copy" on a source block, "Press + to enlarge" on an image, and so on). Hints are also shown on mouse over events.

Image size hints

While agent-shell offers agent-shell-markdown-image-max-width for customizing image sizes, it's fairly restrictive. Not all images are the same, so why force them all to fit within the same constraint? agent-shell-markdown-image-max-width continues to offer a preferred default, but you can now scale images differently by getting the agent to annotate Markdown images with Pandoc-style link attributes.

The attribute block goes right after the image, taking a width and/or height in pixels or percentages:

![alt](image.png){width=300}
![alt](image.png){width=50% height=200}

Auto resize

I may be sweating the small stuff here, but this was really grinding my gears. We have lovely Markdown table rendering, which I'm glad we do as LLMs aren't always great at producing perfectly aligned tables. In the best of cases, the LLMs align the table perfectly, but it's just too wide for our Emacs window. Luckily, our lovely rendering also wraps cells to make them fit into our window. The thing is, all that lovely rendering goes out the door the moment you either resize your Emacs frame or merely split your window, resulting in a monstrosity like this:

I know. I'm sweating the small stuff here, but hey we don't have to live like this. Emacs has all the hooks in the world, so let's track window changes and rejoin the civilized world.

On a much smaller scale, I also wanted auto resize for images, so here you have it…

Manual resize

While we can influence image size at render time, this can still generate undesirable image dimensions, so we can now rescale all images in buffer on demand.

Sometimes a hammer really isn't the right tool, so we can now also rescale an image at point.

Open file links as you please

Opening a local file (from a link, image, or @file mention) now routes through agent-shell-file-display-action, a standard display-buffer action you can customize. The default reuses a window already showing the file, or takes over the current one.

If you'd like a different window arrangement, you could do something like:

(setq agent-shell-file-display-action
      '(display-buffer-pop-up-window))

Xref support

Following a local file link now pushes your origin onto xref's marker stack, so xref-go-back (M-,) brings you right back to where you were in your agent-shell, just like other Emacs jumps.

Use your favorite folding key binding

Foldable fragments now use agent-shell-ui-fragment-map and bind agent-shell-ui-toggle-fragment. If you're not a fan of the RET binding to toggle folding, you can now use your preferred binding.

If TAB is your jam, you can do something like:

(with-eval-after-load 'agent-shell-ui
  (define-key agent-shell-ui-fragment-map
              (kbd "TAB") #'agent-shell-ui-toggle-fragment))

Styling thoughts

If you prefer styling agent thoughts differently, a new agent-shell-thought-body face lets you do just that.

Streaming performance

Streaming performance also received some love. Thanks to @suhail-singh for the profiling and improvements, and to @Scott-Guest and @claytharrison for the trace analysis and benchmarking in #757.

Richer display of options

The "Available config options" section now displays possible values.

Public functions

Dynamic agent configs

agent-shell-agent-configs can now be set to a function, letting you compute the available agent configurations dynamically rather than hard-coding a static list. The function is called on every access, so it stays current across code reloads.

Maybe you'd like to list only available agents. Here's a rough snippet.

(setq agent-shell-agent-configs
      (lambda ()
        (seq-filter
         (lambda (maker)
           (when-let* ((client (ignore-errors
                                 (funcall (map-elt (funcall maker) :client-maker)
                                          (current-buffer))))
                       (command (map-elt client :command)))
             (executable-find command)))
         (agent-shell-default-agent-config-makers))))

Subscribe to agent message chunks

agent-shell-subscribe-to now broadcasts an agent-message-chunk event, handy for external integrations that want to observe streamed output.

Remote agents

executable-find now works correctly on remote hosts (#742 by @CeleritasCelery), smoothing out TRAMP-driven remote agents.

New third-party packages

agent-shell-hq joins the family, offering an interface for managing multiple agent-shell sessions.

Maintenance and housekeeping

If you peeked at the commit logs, you'll notice I've been working daily on agent-shell, keeping up with project inflow. Since last month, 27 issues have been closed and 13 pull requests merged. As of today, the backlog sits at 11 open issues and 5 open PRs (versus 13 and 4 last time around). If there's something you'd like me to prioritize, feel free to ping.

agent-shell needs your support

Vendor-neutral tooling matters more than ever, and there are a couple of ways to help keep agent-shell going. Some cost money, others just a click. All are appreciated ;)

Sponsorships for agent-shell longevity

agent-shell is just me, an indie dev, while the tools it competes with have well-funded teams behind them. Time spent on agent-shell is time away from work that pays the bills, so if it's useful to you, please consider sponsoring the project. And if your employer benefits from your agent-shell use, nudge them to chip in too, they can typically contribute at a scale individuals can't.

GitHub stars for exposure

GitHub stars help with exposure, attracting new users and potential sponsors. Starring agent-shell costs nothing and can potentially help bring in more funding, so if you don't mind a couple of clicks, the project can really use another GitHub star.

Pull requests

Thank you to all contributors for these improvements!

• #730: Queue requests sent during session/push and submit them when it ends (@catern)
• #737: Add a workaround for goose (@bergmannf)
• #740: Add a when-active option to agent-shell-activity-group-expand-by-default (@nhojb)
• #742: Fix executable-find on remote host (@CeleritasCelery)
• #743: Preserve "claimed" regions when rendering bold / italic / strikethrough (@alberti42)
• #746: Avoid repeated system-sleep load attempts (@liaowang11)
• #748: Preserve properties on escaped Markdown punctuation (@Scott-Guest)
• #752: Guard group member walk against non-advancing block range (@hamza-m-masood)
• #756: Preserve point during table rendering (@Lenbok)
• #762: Document viewport workflow (@KarimAziev)
• #763: Render raw tool output (@mrychlik)
• #765: Prevent syntax highlighting from delaying other buffers' mode hooks (@Scott-Guest)
• #766: Refresh viewport header even with nil agent-shell-prefer-viewport-interaction (@catern)

Make it sustainable, sponsor the agent-shell

Liking agent-shell? Would like to see it evolve? Consider sponsoring the effort.

The Emacs Cat, of whom I’ve written many times, has a post on a broken change in Ubuntu that affected Emacs. The TL;DR is that the Cat upgraded to Ubuntu 26.4 but when he tried to use Emacs he discovered a problem with Dired. At first he thought the problem was with Emacs 30.2, which is the default Emacs with that version of Ubuntu. But the actual problem turned out to be with Ubuntu’s implementation of ls. The Cat solved his problem by using the “old” version of ls from GNU coreutils. Ubuntu had decided that it was a good idea to rewrite the core Unix utilities—such as ls​—in Rust.

Maybe I’m just old and grumpy but this seems to me to be a terrible idea. Utilities like ls have been around and working more or less flawlessly for close to 50 years. What, really, was the reasoning behind the decision to rewrite ls? Twenty six years ago, Joe Spolsky answered that question and explained why the rewriting is almost always a bad idea.

It may have been written a quarter of century ago but Spolsky’s explanation remains true. There really is no reason—other than fashion—to rewrite core utilities that have been working perfectly well for longer than many of us have been alive. When you do, you can expect exactly the sort of problem that the Cat stumbled on.

The problem with the new ls was very specific involving an obscure parameter but it reached out to disable a major Emacs functionality and probably affected other applications as well. The annoying thing is that there really wasn’t any reason for this to happen: just someone who decided it would be a good idea to rewrite an application that was working fine.

You’ve probably noticed, Emacs users tend to be a different breed than other computer users. While you can be reasonably sure that anyone who uses vim or VSCode is probably a developer, or someone who works in software engineering, devops, or systems administration, Emacs users can be from virtually anywhere else on the map.

While conventional software has the basics—like users, functions, documentation, and best practices—Emacs has a tradition.

In this article, we’ll look at:

Let’s get nutty.

The post The Emacs pastoral tradition appeared first on Chris Maiorana.

Nous avons parlé en direct avec Fabrice Niessen (Formation Emacs Boost) d'Emacs, de ses flux de travail, de sa configuration, et d'autres sujets en français.

J'ai essayé de corriger la transcription, mais je crois qu'il y a encore beaucoup d'erreurs, donc n'hésitez pas à m'envoyer un message.

• 0:00 Introduction
• 1:46 Le parcours
• 4:15 Emacs sur Windows : Cygwin et WSL
• 8:26 Les automatisations
• 12:15 Emacs Boost
• 21:15 Emacsclient
• 28:49 org-html-themes
• 35:02 Review
• 37:25 PDF
• 40:03 Key-chord
• 45:41 Copier sans sélectionner
• 48:29 fill-paragraph
• 50:02 Les macros
• 51:02 Volatile highlight
• 52:47 Les tableaux Org
• 55:43 Les formations et les cours particuliers

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

Here's a few minor tweaks I've made to my Emacs setup recently.

(treesit-enabled-modes t)

(treesit-enabled-modes '(bash-ts-mode
                         c++-ts-mode
                         c-or-c++-ts-mode
                         c-ts-mode
                         dockerfile-ts-mode
                         go-mod-ts-mode
                         go-ts-mode
                         go-work-ts-mode
                         json-ts-mode
                         python-ts-mode
                         rust-ts-mode
                         typescript-ts-mode))

Nous allons à nouveau parler en direct avec Fabrice Niessen d'Emacs, de ses flux de travail, de sa configuration et d'autres sujets en français. Voici ses notes.

[2026-08-27 Thu 07:30]–[2026-08-27 Thu 08:30] dans le fuseau horaire America/Toronto, soit 0730H EDT / 0630H CDT / 0530H MDT / 0430H PDT / 1130H UTC / 1330H CEST / 1430H EEST / 1700H IST / 1930H +08 / 2030H JST.

Voici notre conversation précédente :

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

In the previous post,¹ I was disappointed to learn that valid priority characters are limited to 0–9 and A–Z. I thought it would be neat if the exclamation mark ("!") could represent the ultimate priority, a sort of "drop everything and do this immediately" kind of priority.

It turns out that you can use "!" for this purpose, regardless of which priority characters you've configured. The trick is to write a function and assign it to org-priority-get-priority-function.

The function (which I named org-get-cust-priority) simply looks for "!" in the priority cookie and returns one hundred times the value that would be returned by the highest valid priority. If it doesn't find "!" it simply calls a modified version of the usual org-get-property function,² which I named org-get-std-priority. The two functions are shown below.³

(defun org-get-cust-priority (s)
  "Return 100 times the highest priority when S contains
a priority cookie with `!'.  Otherwise call the usual
`org-get-property' function. Intended to be the function
`org-priority-get-priority-function' is set to."
  (interactive)
  (if (not (functionp org-priority-get-priority-function))
      (org-get-std-priority s)
    (string-match ".*?\\(\\[#\\(!\\)\\] ?\\)" s)
    (if (and (string-match ".*?\\(\\[#\\(!\\)\\] ?\\)" s) (string-equal (match-string 2 s) "!"))
        (* 100000 (abs (- org-priority-lowest org-priority-highest)))
      (org-get-std-priority s))))

(defun org-get-std-priority (s)
  "Find priority cookie and return priority.
S is a string against which you can match `org-priority-regexp'.
Same function as `org-get-priority' sans test for a custom
function in `org-priority-get-priority-function'."
  (save-match-data
    (if (not (string-match org-priority-regexp s))
        (* 1000 (- org-priority-lowest org-priority-default))
      (* 1000 (- org-priority-lowest
                 (org-priority-to-value (match-string 2 s)))))))

The number that Org uses to sort on priority depends on the values of org-priority-lowest and org-priority-highest,⁴ which are "C" and "A" by default. In the default configuration, the highest priority has a numeric value of 2000, while the lowest has a value of 0. If the highest and lowest priority characters are 1 and 9, respectively, the highest priority has a value of 8000.

You know you need this if you have about a dozen items on your agenda and half of them are prioritized A.

2026-08-13 Update org-get-cust-priority. Previous version breaks org-tags-list.

¹ https://ray-on-emacs.blogspot.com/2026/07/numeric-priorities-in-org-mode.html
² Modified just to prevent recursion.
³ I know this code isn't particuarly elegant. I could have made custom variables for "!" and the priority multiplier, for example. I'd like to use it for a while before deciding whether it's worth investing any more effort. I do welcome suggestions on how to improve.
⁴ Or rather, the difference between the highest and lowest priorities.

I don’t see anything in my feed worth writing about so I offer this bit of humor to help you get through the day. If you’ve ever wondered why an S-expressions is called an sexp, here’s your answer.

Like all humor, there’s a bit of truth here. Not the part about sexp, of course, but the notion that many of us come to Emacs for some particular feature, venture too close to the init.el event horizon, and never escape.

Just recently I upgraded one of my Dell laptops to the latest Ubuntu 26.04 LTS with a clean install. The installation process was smooth and enjoyable.

Ubuntu 26.04 ships with Emacs 30.2, which made me happy, so I installed it immediately—more precisely, the emacs-pgtk Wayland-optimized package, since Wayland is the default windowing system on Ubuntu 26.04.

The Problem

I started Emacs and, after a short time, ran into a problem: Dired (C-x d) did not work properly. It displayed a strange mess of unsorted, chaotic entries, as shown below. It was a big surprise.

I’ve been using the same .emacs multi-platform config file for Linux, macOS, and Windows for years and have never had any problems with Dired on different platforms, let alone across versions of the same OS.

My Dired configuration is quite simple:

;;; `DIRED'
(require 'dired)

;; Dired options for Windows and non-Windows (Linux, macOS) systems.
;; http://oremacs.com/2015/01/13/dired-options/
(if (string-equal system-type "windows-nt")
    (setq dired-listing-switches "/A:H /O:NG")
  (setq dired-listing-switches "-laGgh1v --group-directories-first --time-style=long-iso"))

;; `dired-subtree' (since 2022-10-18)
;; https://xenodium.com/drill-down-emacs-dired-with-dired-subtree/
(use-package dired-subtree
  :ensure t
  :after dired
  :config
  (bind-key "<tab>" #'dired-subtree-toggle dired-mode-map)
  (bind-key "<backtab>" #'dired-subtree-cycle dired-mode-map))

;; By default, Dired buffers will not update themselves
;; unless you explicitly tell them to.
(setq dired-auto-revert-buffer t)

The dired-listing-switches variable defines the switches passed to dir or ls for Dired on Windows and Linux/macOS systems, respectively. I’ve been using this configuration for years.

On Ubuntu 24.04 everything looks fine. So, what’s wrong with Emacs 30.2?

I decided to test the ls switches in the console. Oops—the same result as in Dired under Emacs 30.2!

This means the problem is not with the new version of Emacs. After a short search, the answer was found.

The Bug in Ubuntu 26.04

It turns out the bug in Ubuntu 26.04 is real, documented, and already tracked in Ubuntu’s Rust-based coreutils for Ubuntu 26.04. The issue specifically affects ls when using --group-directories-first and is tied to missing locale collation support in the Rust rewrite.

Launchpad Bug 2154042 — Incorrect alphabetical sorting with --group-directories-first

This is the main bug report affecting Ubuntu 26.04 users after the Rust coreutils transition. It explicitly states that:

1. ls from the Rust-based coreutils does not sort alphabetically when using --group-directories-first.
2. The bug appears both when LC_ALL is set and when it is unset.
3. GNU ls (gnuls) sorts correctly; Rust ls does not.

Conclusion

Since Dired—and possibly other Emacs packages—uses ls to list directories and files, Dired will not work properly on Ubuntu 26.04 regardless of the Emacs version.

Solution

Luckily, the Ubuntu team has kept the old version of coreutils (GNU coreutils), written in good old C. The GNU version of ls is gnuls and is installed by default on Ubuntu 26.04. This means we can use gnuls—which works properly—for Dired instead of ls when running Ubuntu 26.04.

To do this, we will use the insert-directory-program variable, which holds the absolute or relative name of the ls-like program. This variable is used by insert-directory and dired-insert-directory (and therefore by Dired). Its default value on Linux and macOS is ls.

First we need to determine the name and version of the OS. The custom ubuntu-version function helps with that:

(defun ubuntu-version ()
  "Return (MAJOR MINOR) as integers if running on Ubuntu, else nil."
  (when (and (eq system-type 'gnu/linux)
             (file-readable-p "/etc/os-release"))
    (with-temp-buffer
      (insert-file-contents "/etc/os-release")
      (let* ((os-release (buffer-string))
             (is-ubuntu (string-match-p "^ID=ubuntu" os-release))
             (version-id (and is-ubuntu
                              (when (string-match "VERSION_ID=\"\\([0-9]+\\)\\.\\([0-9]+\\)\"" os-release)
                                (list (string-to-number (match-string 1 os-release))
                                      (string-to-number (match-string 2 os-release)))))))
        version-id))))

On my machine ubuntu-version returns (26 4).

Now we can replace ls with gnuls if we are on Ubuntu 26.x:

(when (eq (car (ubuntu-version)) 26)
  (setq insert-directory-program "gnuls")
  (message "`ls' is replaced with `gnuls' on Ubuntu 26.x."))

After that, Dired works as before.

Happy Emacsing on Ubuntu 26.04!

– The Emacs Cat.

Projectile 3.4 is out! After the four releases that preceded it this summer, this one is polish rather than ambition.

Most of it came out of an annoyance I’d been living with for years without ever quite naming it: a lot of what I work on isn’t one directory. CIDER is really CIDER plus cider-nrepl plus orchard plus clj-refactor plus a handful of others. RuboCop is RuboCop plus rubocop-ast plus rubocop-rails and the other extension gems plus the style guide. I’ve been maintaining families of repositories for the better part of a decade.

Lately I’ve also been reaching for git worktrees far more than I used to, so the same repository is now checked out two or three times on my disk at any given moment.

Projectile saw all of that as a pile of unrelated projects, which is exactly what it looks like from the outside.

Somewhere else in the same project

projectile-switch-worktree (s-p W) offers the other checkouts of the repository you’re in, each labelled with whatever tells it apart - the branch for git, the workspace name for Jujutsu:

Switch to worktree:
~/src/myapp-main/     (main)
~/src/myapp-hotfix/   (hotfix/crash-on-open)

Git worktrees are the obvious case. Projectile asks git about those, so a worktree you’ve never opened in Emacs shows up anyway. Jujutsu workspaces work the same way.

The case I care about more is the one without any plumbing: a second git clone of the same upstream. Same workflow, done by hand. I looked at my own ~/projects while writing this and found four separate clones of CIDER sitting in it. Nothing records those anywhere, so Projectile can’t ask git to list them - it matches them among your known projects by their remote instead.

Somewhere else in the same effort

The other half is projectile-switch-sibling-project (s-p n), which offers the projects related to the one you’re in rather than every project on the machine.

The interesting question was what “related” should mean. My first instinct was to compare directory names and look for a shared prefix. Before writing anything I tried the candidates out on my actual project directory, all ninety-odd repositories of it.

Comparing names does find rubocop, rubocop-ast and rubocop-rails. But grouping by the owner of the upstream remote finds this:

Half of those names have nothing in common with cider, and no amount of staring at directory names would ever have related them. haystack parses stack traces, port is a printer registry, sayid is a tracing debugger. Nothing in those names says “CIDER”.

What they do have in common is an org: they all live under clojure-emacs on GitHub. That’s not incidental, it’s how the project is actually organised - the org is the boundary of the effort, and the individual repositories are just where the pieces ended up when they got big enough to split out. Same story for the rubocop org, and for nrepl. Once I saw that, keying on the owner of the remote was obviously right, because it’s the same fact GitHub is already recording for me.

It needs a bound, though, and the same experiment showed why: about 40% of my checkouts are under my own GitHub account, and “we’re both under bbatsov” doesn’t relate anything. So an inferred group covering more than a quarter of your known projects gets dropped and the next signal takes over.¹ If you’d rather just say what belongs together, projectile-project-groups is there and is never second-guessed.

Switching is only the obvious thing to do with this. Now that Projectile can tell which projects belong together, the same grouping could back a find-file or a search across the whole family - one prompt that reaches every repository in the org rather than just the one you happen to be sitting in. I go looking for “which of these fifteen repos defines this var” often enough that I suspect it’s the more useful half. Nothing built yet, but that’s where I expect this to go.

The commands come with you

Once Projectile knows two directories are the same repository, the command history can follow you between them.

Press M-p at the compile or test prompt in a worktree you made this morning and you get the commands the project is actually built with, instead of an empty history. That’s an issue from 2022 that a stale bot had helpfully closed for me at some point.

What doesn’t follow you is anything that runs without asking - what a prompt is pre-filled with, and what projectile-repeat-last-command replays. I had those shared too in the first draft, and then watched a repeat in one worktree rebuild the tree next door. A remembered command can carry absolute paths back to where it was typed.

More languages, fewer surprises

projectile-run-test-at-point (s-p c .) arrived in 3.1 knowing Python, Go and JS/TS. It now also knows Ruby (both RSpec and Minitest), Rust, Elixir, Java, Erlang and F#.

Ruby is written the same way whichever framework you use, so there the project type picks the runner rather than the syntax; Java’s picks between Maven and Gradle. Elixir tests get addressed as FILE:LINE, because ExUnit can’t select a test by name from the command line. OCaml deliberately gets nothing - its tests are ordinary values you register with Alcotest or OUnit, so there’s no syntax to recognize.

projectile-find-file-of-kind (s-p j) and projectile-toggle-related-file (s-p J) learned Phoenix, Laravel and Next.js. Rails and Django had been the only frameworks with file-kinds tables out of the box, which felt like a strange place to have stopped.

The reports answer back

The dashboard and the doctor from 3.3 both got a pass. They’re no longer plain text - section headers, field labels and findings are faced by meaning, with findings colored by severity and sorted so anything wanting your attention comes first. The faces only inherit from standard ones, so your theme styles them without knowing Projectile exists.

The doctor’s findings now come with a button that acts on them:

[enable] for a projectile-mode you forgot to turn on, [enable caching] on a big uncached project, [open dirconfig], [edit .dir-locals.el]. Pressing one regenerates the report. Findings Projectile can’t act on stay plain advice.

And since a doctor report usually ends up pasted into an issue, w copies the buffer as plain text, without the faces and buttons.

Odds and ends

• projectile-find-changed-file (s-p C) completes over what git reports as staged, unstaged or untracked - or, with a prefix argument, everything that differs from a revision you pick.
• projectile-run-task discovers rake tasks now, read out of your Rakefile and .rake files rather than by running rake -T, which would load the whole application.
• projectile-ignored-project-patterns is the regexp-matching sibling of projectile-ignored-projects, so keeping a whole area of your machine out of the known projects no longer needs a lambda.
• Messages Projectile emits on its own initiative are prefixed with [Projectile] now, and the ones answering a command you just invoked aren’t. There were five different conventions in there before, which I’d somehow never noticed.
• The known projects file, the frecency store and the session directory are resolved with locate-user-emacs-file, so they land in the right place if your configuration lives in ~/.config/emacs. Nothing moves if it doesn’t.
• Elixir’s implementation/test toggle offers foo_test.exs rather than foo_test.ex, a script ExUnit will actually run. Project types can declare their test file extension now.

Upgrade notes

Nothing here should break a working setup, but two things are worth knowing.

A batch of options were renamed or folded together. The six projectile-<cmd>-use-comint-mode options became one projectile-use-comint-mode; projectile-per-project-compilation-buffer and projectile-per-command-compilation-buffer became projectile-compilation-buffer-scope; and a handful of options that had broken their own naming schemes were renamed to match their siblings.² Every one of them is still honored under its old name, so your config keeps working - you’ll just see an obsolescence notice.

Two options are gone: projectile-tags-file-name and projectile-go-project-test-function were only ever read as Projectile loaded, which means setting them from your init file afterwards did precisely nothing.

And the command history is now the repository’s rather than the directory’s. Set projectile-command-history-scope to project if you’d rather have it per directory. Histories you already have are adopted, not dropped.

The full changelog is here, and the manual is at docs.projectile.mx. The cross-repository features have a page of their own, limitations included.

Five releases in six weeks is not a pace I intend to keep up, and this is the natural place for the burst to land. The big pieces from 3.0 through 3.3 have had their corners sanded down, and what’s left on my list is smaller and less interesting to write about. Which is roughly where a fifteen-year-old package ought to be.

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

JTR from the blog The Art Of Not Asking Why sent me a few questions regarding Emacs themes, my opinion on the Solarized colour scheme, and even my choice of wallpaper.

JTR asks about Solarized because I consider Ethan Schoonover’s Solarized an excellent project, given what Ethan was trying to achieve. I asked JTR if I could publish my thoughts and they agreed. JTR has also written the article Back to Solarized.

Note that throughout this article I am only commenting on Ethan Schoonover’s Solarized (the original Solarized). There are many Solarized-like themes out there with lots of additions on top, including higher colour contrast, which are separate themes as far as I am concerned.

I should also point out something I always mention: themes are a personal choice and there are many factors that go into what a person wants. Keep in mind that readability is also a matter of font size, ambient light, and the screen brightness you are using.

To give a simple example, modus-operandi in a very dark room with maximum screen brightness at a fairly large font size will most probably harm you and is thus a terrible choice. But the same setup on a sunny Cyprus day in my well-light house is how you can read the screen without distractions.

Generally though, people forget to adjust their screen brightness, so always do that and rely on environmental light to not tire out your eyes.

Be mindful of the context

Have your thoughts changed about Solarized since the creation of Modus themes? Later, did they change after you created the ef-themes?

In short, no as the technological realities for my case and for the original Solarized remain the same. Ethan Schoonover wanted to have a colour scheme that would work reasonably well with terminal emulators and, by extension, Vim. Most terminal emulators let you define 16 colour values. Then applications running inside the terminal can map those to the objects they display.

Applications running inside the terminal cannot change the 16 colour values of the terminal. This means that Ethan’s Vim configuration necessarily had to have a light and a dark theme that worked with the same 16 colours. Ethan could have developed two distinct colour schemes for the terminal, which would then underpin two separate Vim themes, but I understand how this is a more complex arrangement.

My older Tempus themes project, from my pre-Emacs days, is for terminals, Vim, and friends. Same idea for its predecessor, Prot16.

I think both of those older projects are fundamentally flawed because the technological constraints they are designed to work in result in all sorts of little compromises. To give an example that many Linux users may have noticed: if you use a light theme in a terminal and do apt update && apt upgrade you will get the progress bar with a green background and a black foreground. Colour schemes cannot change that combination, so they make that text virtually unreadable (in a terminal, colour combinations should always be ACCENT + BACKGROUND, not ACCENT + BLACK/WHITE, as the accents are always designed to be visible against the background).

There cannot be one Solarized

Even though the original Solarized was designed to be a single theme, in practice it is not and cannot become as much. There is Solarized Light and Solarized Dark, sharing those same 16 colours. Solarized light has a background that is closer to yellow, while its dark counterpart’s background is closer to blue. This means that accent values which are picked to work with both eventually do not work equally well as they do not evoke the same feeling.

Without even considering the specific values of the Solarized palette, a combination of blue/cyan, magenta, and purple as foreground colours will be on the opposite side of the spectrum to the yellow background and on the same side as the blue background. This means that if we pick blue/cyan, magenta, and purple as our main colours we have a light theme (yellow) with a completely different feel than the dark theme (blue) even though they are supposed to be the “same Solarized”.

Let me outline this for you:

So if we force the same mapping of foreground colours, then we have two themes with contrasting harmonies and necessarily distinct characters. In this context we begin to appreciate the importance of judgement: sometimes you achieve likeness through difference. For the table above, inter-theme likeness exists on the diagonals, so either have both themes with “same side” combinations or both themes with “other side” combinations.

This concerns the predominant colours. A theme that uses all accents in equal proportion will look very busy and thus run into other problems.

The designer can, of course, pick a colour that does not follow the overall pattern to produce an emphasis of some sort. Though they cannot start with emphasis as their baseline.

One set of values leads to compromises

Because Solarized Light and Solarized Dark are designed to share the same palette, individual values are picked as a matter of compromise, even though they are “equally good” on paper in terms of distance as measured by various luminance metrics. The blue used for the light theme, for example, must also be good enough with the dark theme. But “good enough” for both may not be optimal for either.

Concretely, the Solarized blue stands out more in the light version than in the dark version (because of the complementarity between yellow and blue). If the light effect is supposed to evoke sunlight on a surface, and if that is the reason green and yellow are desaturated, then the blue should not be as saturated for the light theme. It would have to be a considerably more washed out colour. Though the blue has to be fairly saturated to be readable on the Solarized Dark background and still look like a blue, hence the compromise.

Same idea for the green and yellow colours which are consistent with the light background but would require tweaks to be harmonious with the dark background.

The magenta does not fit any background: it stands out as an exaggeration. To be consistent with the light background, it has to be less saturated. To fit the dark background, it needs to have greater contribution from the blue channel of light (i.e. move closer to purple) or become more pink. But moving in either direction compromises the opposite theme…

There is no “bright green” (terminal colour 10), “bright yellow” (terminal colour 11), “bright blue” (terminal colour 12), and “bright cyan” (terminal colour 14). I believe this is because they would not fit both Solarized Light and Solarized Dark.

My themes are designed for Emacs

As noted, Ethan’s Solarized was developed with a specific technology in mind. The same is true for my case: I develop all my themes to work with Emacs. This typically means that I can rely on more than 16 colours and each theme can have its own colour values.

For example, if I choose to apply a green background colour to the “current match” in a search, its value is not the same green I would use for, say, a “DONE” keyword in Org. Whereas in a terminal with 16 colours what you normally do is invert background and foreground colour combinations, which results in things standing out more than they need to (and becomes overwhelming when you want to use many such elements).

Each of my themes relies on its own palette. If I tweak one theme’s colour values, I am only affecting that one theme. Because each theme is its own design, I can make things similar by making them different. For example, modus-operandi-tinted is a “yellow-red theme” (simplifying greatly now) but its counterpart modus-vivendi-tinted is a “blue-purple” theme. On paper, this description alone makes them very different. But in terms of character, they both communicate a similar feel, owning to considerations that follow from what I mentioned above.

Additionally, each theme has its own colour mappings. This means that I do not have to make every theme use, for example, blue for links. In Emacs, I have greater control over what each “application” does, by configuring the relevant faces. There still are constraints, as I cannot for example decide which faces are applied to what portion of text, but this is generally not a problem.

Differences between my theme projects

What’s the difference between prot16 and your ef-themes? They seem to cover similar ideas, but it doesn’t look like prot16 has been updated.

My older projects are for terminal emulators. It is why they were inspired by Solarized. Terminals only have colour schemes though, not themes. The designer cannot control how colours are mapped to objects, so they have no means of enforcing thematic consistency.

A colour scheme sets the 16 values, but otherwise has no mappings for things such as “here is an error message” or “this is a progress bar and things are going well”, or even to specify “I only want green and blue here, but never magenta”.

If a colour-coded message gets a style, it will typically be hardcoded to red, green, or yellow. And if the colour scheme wants to support users with blue-yellow colour deficiency, for example, it will have to add a yellow value where the nominal red is (terminal colour 1 and terminal colour 9). But doing so leads to weird issues because, fundamentally, we are conflating colour names with colour mappings (there may be an application that wants to use yellow text on a red background, but now that actually becomes yellow on yellow, so you get the idea).

In Emacs, a theme designer has more control. They can specify colour values and write exactly how they are used by the relevant faces. For example, we do not only define “blue” but also say “I want keywords in programming modes to be blue”.

The constraint in Emacs is which faces do packages define and how exactly they apply them to elements of the display. A theme cannot, for instance, dictate how many separate faces a programming mode will add to its text. Furthermore, a theme cannot govern how generic faces, like font-lock-variable-use-face are set by modes to do things they are not supposed to do (for example, a mode specifies that face because they like its green colour in the one theme the author is using, but the thing being styled is not a variable and that specific face does not produce an optimal result in its context).

Additionally, themes cannot determine the surrounding text. For example, the Org export dispatcher has keys wrapped in square brackets (and I sent a patch that was merged a long time ago to have decent colours there by default when no theme is used). The bracketing is something the theme cannot change, so it has to do strange things to produce readable text because in an [i] indicator it is hard to discern the i due to how the square brackets limit the perceived boundaries—and you need to apply a highlight so that the user knows which exporter they are picking. An [ i ] is somewhat easier in this regard and a variation of it without the square brackets is even more flexible as then the theme can apply all the colour and typography attributes it needs.

Another constraint with Emacs is that we do not have real padding and margins, the way those are understood in CSS. I think this is fine for the majority of cases, but can be a problem sometimes such as when we need to use a coloured background that spans a small portion of text (e.g. with the Org dispatcher or with the style of rendered keys like <home>).

The gist is that Emacs gives the theme designer more control and in a more integrated way than a terminal+TUIs arrangement. This results in a coherent experience. Terminal-centric environments cannot have that to the same level because of disparate applications trying to form one computing environment, each doing its own thing in the process. I tried inter-application consistency in the terminal, discovered its limitations, and is the single most important reason why I switched to Emacs.

Contrast and readability

My understanding is that the contrast for Solarized wasn’t good enough for you. I don’t know if you have my issue specifically (https://taonaw.com/2023/07/05/halatoion-and-accessiblity.html), but I’m curious: don’t you get halation as well? Doesn’t it bother you, especially if you switch from a dark theme to something lighter? (For example, you read something with a dark background and light text, then switch to a page that has a light background and dark text)?

We measure contrast between colours to have an imperfect approximation of what might work in the average scenario. Though readability is influenced by many more factors beyond the applicable colours. Consider the environmental light and the brightness of the monitor. In addition, check the font size and even the font family you are using. Many font families can produce a halo effect at different sizes, regardless of colour combinations.

Have an extra source of light beside the monitor’s. If you do not, the eye focuses on one spot, which is more tiresome. And always adjust the screen brightness to not be too bright or too dim relative to the environment.

As for fonts, you may benefit from a design that has more open shapes. The exact size is also a factor.

For example, I have a font called Aporetic that is derived from Iosevka. What motivated me to do my own thing is the original monospaced m of Iosevka (maybe it is changed now), which blurred into a box at small point sizes and was thus not nice to read.

The Hack font I used to use (and which I had also modified), had similar issues. The Ubuntu Mono font that Ubuntu and derivative Linux distributions rely on, can have a g with a very short descender at certain point sizes, as well as a dotted zero where the dot is off centre.

I can go on to great details but you get the idea: you have to check all the variables and find what works for you. I am confident in stating that this is never a theme-specific issue.

As for switching between applications, these days most desktop environments have a concept of a light/dark preference, which many websites also follow. For example, GNOME has a menu from where you can toggle the “Dark Style” on/off.

The specific problem you will encounter with Solarized is that practically no other application or website uses it or similar colours. So either you will have to set Solarized everywhere you can, or you will be switching from the yellowish/blueish background to white/black, with whatever context-switching friction that may have.

Thoughts on wallpapers

This is an extra one I’m curious about: what are your thoughts about wallpapers? I noticed, the few times I worked with you and on video, that usually you have a natural scene. Have you ever switched to something else (like a drawing, perhaps an artwork, or maybe even a technical scheme)?

I have used wallpapers of all sorts and find that pictures I take of landscapes or flowers are the best for me. The reason is that they avoid exaggerations. Many pictures that are used for wallpapers are designed to show something in a more pronounced way and are thus calling for your attention. That is fine when the object of attention is the art piece. But when I am doing work on the computer, I do not want other elements to be competing for attention with whatever it is I am working on.

“Avoiding exaggerations” is a principle that informs my lifestyle. It also is why I prefer to live in the mountains and to spend plenty of time outdoors. The mountains do not have the intense stimuli a city has. In a city there are bright lights everywhere, a faster pace to motions, and sharper noises all around. Whereas the mountains are subtle, even though they are full of life.

People who go on a retreat say “I went to this holy place and found peace”, when in reality what likely happened is that they reduced their exposure to exaggerated stimuli and were thus able to lower their baseline intensity for a little while.

Because we are also conditioned by our habits, we do not realise just how much we have gotten used to things in our milieu, even when those are not benign to us.

People want magical solutions when the basics will suffice. We are heavily influenced by our environment and the elements we are exposed to. A stressful place will increase our stress levels. A harmonious place will make us more harmonious. Inconsiderate food choices will disturb us long-term, a poor work-life balance will harm us, and so on.

People think they can brute force their way into calmness or focus by means of “truly believing” in their project. This is a fool’s errand. Changing the scenery and relevant lifestyle will be far more effective than whatever willpower one thinks they can muster on demand.

Emacs produces a backup of each file by default. It does this by appending a tilde to the file's name. For example, Myfile.txt is backed up to Myfile.txt~. It's a reasonable strategy, assuming that a Version Control system is in place.

But in the absence of version control, you're limited to restoring just the previous version; older versions need to be restored from backup.

I use git for coding projects that I share to the public. But I didn't create a repository for my home directory. So when C-c a m TAG¹ generated an error instead of a list of TAGged items, I hoped fervently that the latest init file change was to blame.

After finding and fixing the problem quickly, (and realizing I was lucky this time), I resolved to be more diligent about disaster recovery. I looked into what backup schemes Emacs already provides.

Emacs can create unique backups for a file rather than overwriting the previous backup. When Emacs sees a numbered backup for a given file, it will make a new, sequentially-named file for each backup of that file, while continuing to use the "append tilde" method for other files.

Once I renamed (or copied) .emacs~ to .emacs.~1~, Emacs created backups named .emacs.~2~, .emacs.~3~ (and so on). I didn't even need to change a variable -- when Emacs detected .emacs.~1~, it knew that backups of .emacs needed to be numeric, so it acted accordingly. Emacs continues to use bills.org~ as the backup for bills.org. Until I tell it otherwise.

Read the Emacs Manual to learn more about numbered backups.

¹ C-c a m invokes org-tags-view

The default values for the pertinent backup variables are:

• make-backup-files is t
• backup-by-copying is nil
• version-control is nil

One of the things that we Emacers hear with tiring frequency is that Emacs is moribund, old technology loved only by graybeards stuck in the last century. In fact, as actual users know, Emacs is undergoing constant development and is often the first to offer new features that the other editors copy. The most salient examples are Org mode and Magit but there are plenty of more recent examples.

But don’t take my word for it. Over at the Emacs subreddit, gonstrider has a short post relating his experience with all of this. He’s been using an unnamed editor—you’ll have no problem figuring out which one—that keeps having weekly updates that seem to make things worse each time. So he jumped in the deep end and downloaded and built Master (Emacs 32) fully expecting to find lots of broken things.

It didn’t turn out that way. He was, in fact, surprised to discover that almost everything worked well. The only problem he had was evil on Windows and he solved that by simply upgrading evil. As for the rest, he found that Emacs was super-responsive and all the functionality that seemed laggy in that other editor was snappy in Emacs.

There are two lessons here. The first is that Emacs, far from being moribund, is undergoing continuing development and introducing new features. The second point is that Emacs is, unlike some of its competitors, continuing to produce upgrades that simply work and don’t make their users crazy.

Very shortly, we should see the release of Emacs 31 but work on Emacs 32 is already ongoing and amazingly stable for what is, after all, alpha software. The next time someone tells you that Emacs is old and moribund, refer them to gonstrider’s post.

Years ago, when I started the old blog¹, I discovered Solarized.

I liked it. The colors were beautiful and worked for me, but eventually I switched to the Gotham theme in Emacs, which, if you take a look, is not much different — just a bit darker. I stayed with this theme for a long time, tweaking it a bit after a trip to New Mexico.

When I received my Mac and started working on it at home, I enjoyed its automatic switching between dark and light themes. At the same time, Prot started coming out with more of his excellent Ef Themes, and I adopted ef-reverie for my light theme and ef-night for my dark one (once again, if you look at the images, you’d see they’re not far off from Solarized, especially my choice of a light theme).

This has been the state of affairs until the beginning of this week, when I “found” Solarized again. I discovered Prot himself was heavily influenced by Solarized, and he discussed it several times on his blog. Here’s part of his background story for his project Prot16:

My starting point for developing a colour scheme was Ethan Schoonover’s Solarized. A true masterpiece. I thus settled on a method of using a 16-colour palette that consists of 8 base values and 8 accents. As with Solarized, the themes would have to be able to transition from ’light’ to ‘dark’ environments with minor alteration to the mapping of colours (though not the values themselves).

Prot’s quest is an interesting one. Like me, he enjoyed Solarized, but eventually decided the colors were not contrasting enough for his taste. His reaction was to create his well-known Modus themes, which, along with his Ef-themes and Prot16, set new theming standards for Emacs.

Meanwhile, I have had the other issue since childhood:

I’ve never liked harsh contrast for this reason. As a matter of fact, a more “gentle” contrasting theme is one of the reasons I like working in Emacs. My website and my wiki are a result of these preferences. The black text on the beige background is comfortable on my eyes. Enough contrast to read, but not enough to burn text into my vision, as many dark modes out there do.

While Prot’s ef-themes offer softer contrast (I didn’t check, but it does seem so visually) which I find excellent, I decided to try out bbatsov’s Solarized for Emacs, which I didn’t know about in the past when I first picked up this theme for Emacs — the official Emacs port is not as good in my opinion.

I’ve learned a couple of things I wasn’t aware of. For starters, you can have many variations of this theme, even though the main 16 colors are still preserved. It makes sense when you think about it: one person can choose Solarized’s red (#dc322f in hex) as an emphasis, while another can select its yellow (#b58900) or orange (#cb4b16), for example. Webpages and Emacs take it a step further, as certain texts can be bold or italicized, with solid underlines or dashed ones, etc. All of those changes take place without touching the colors themselves.

Solarized also helps me with a certain itch I’ve had for a couple of months: a dark theme for my blog. I know most of you read my posts in your RSS reader, hopefully with a theme you enjoy, so this won’t matter much. For me, how my site looks and is styled is important, and getting there is fun.

Being a PhD student within a research group entails some structure to tracking your progress as you proceed with research. Within the current team that I'm in, we have weekly group meetings where each member presents the tasks that they've completed during the previous week and discusses any issues they might've faced (if any), to our supervisor.

Usually before the meeting, I jot down things that I've finished with pen and paper. But since I'm in the spirit of integrating my workflow with emacs and orgmode, I thought why don't I try implementing this part of my routine also into orgmode.

Enter org-agenda

All my todo items are tracked with org-agenda where I capture every task I need to finish with org-capture¹.

I have a custom org-agenda view just for viewing my daily and weekly TODO items, events/meetings scheduled at a certain time and tasks that have a deadline associated with them. Suffice to say, this workflow has replaced all my needs for having a calendar over the cloud, be it Google, Outlook, what have you². The only downside that I haven't figured out (yet) is to incorporate calendar invites that I receive via email, into my org-agenda automatically instead of manually capturing an event into the agenda view.

With this custom agenda view, as I finish tasks and mark them DONE, they disappear from the current view. This is by design. I figured I could just review my completed tasks by visiting the relevant files (tasks.org, meetings.org, etc. in my case). But who wants to sift through all the completed tasks and filter them manually to only note down the tasks completed during the previous week? Why not automate this with the power of emacs?

Elisp snippet that implements this weekly review

The idea is fairly simple. I'd like to look at the tasks that I've completed since the last group meeting. This assumes I review these tasks on the day of the group meeting (which I do currently³).

We simply then instruct orgmode to filter out the DONE items from the last 7 days. The org-agenda-custom-commands variable is what we'll use to define this custom org-agenda view.

(setq org-agenda-custom-commands
      '(("w" "Finished tasks from last week" tags "CLOSED>=\"<-7d>\""
         ((org-agenda-overriding-header "Finished tasks from last week")
         (org-agenda-archives-mode t)
         (org-agenda-tag-filter-preset '("-emacs" "-personal" "-email"))
         (org-agenda-prefix-format '((tags . " ")))
         (org-agenda-remove-tags nil)))))

Let's go over the various config options one by one:

• The first line defines the keybinding in the primary org-agenda dashboard and the associated title for the keybinding.
• tags "CLOSED>=\"<-7d>\"" is pretty self-explanatory. We filter for items that were completed in the last 7 days.
• org-agenda-overriding-header: Simply defines the title of the agenda view.
• org-agenda-archives-mode: This is set to t (True) meaning to also look at the archived entries from last week. I typically archive my entries frequently so this is helpful.
• org-agenda-tag-filter-preset: I don't want personal tasks appearing in this view, so I remove any items that have the relevant tags.
• org-agenda-prefix-format: By default, the agenda view contains information about which file the entries belong to (in my case, it's tasks.org). This appears as tasks: per entry in the agenda which unnecessarily clutters the view.
• org-agenda-remove-tags: I don't want to remove the tags of the various entries (they are useful to me) that appear in the right margin. Hence this variable is set to nil (False).

To invoke the view, we can simply run M-x org-agenda and hit w to get into the view. My org-agenda dashboard looks like this:

All the above keys are present in the default view, except my custom views (depicted by j and w keys).

Invoking custom org-agenda views (slightly) faster

For my workflow, I mostly deal with just the two org-agenda views (represented by j and w). It's a good idea to have a global keybinding to quickly invoke these views. Let's define the function and keybinding for it.

(defun pani/done-items-prev-week-org-agenda ()
  "Custom function to immediately jump to my custom org-agenda view."
  (interactive)
  (org-agenda nil "w"))

To invoke the function, we define the keybinding like via a use-package macro:

(use-package org-agenda
  :ensure nil
  ;; Don't need to go through org-agenda template for custom agenda
  :bind (:map global-map
	      ("C-c w" . pani/done-items-prev-week-org-agenda)))

I can then just hit CTRL c w to bring up this new agenda view.

That's it! This should make things easier for me during our group's weekly meetings.

The topic of this month's Emacs Carnival interests me, even though I "dump ... notes into a directory and simply grep for information ...."⁰ Org does not work the way my brain works,¹ or rather, my brain doesn't work the way Org works.

I do use Org. At first I created a few Org files (work.org and home.org, and maybe todo.org) thinking I could rigidly dedicate all my topics to them.

Over time I had about dozen files, one for nearly every major facet of my life until I gave up. Why? Because it really doesn't matter where I put Org TODOs and their notes. When I need to locate something, Org provides a way to search entries for a regular expression, which is what grep does, sans all that Unixy CLI stuff.

So faced with the task of paying one of my wife's medical bills, I could agonize over whether to put the task into wife.org or bills.org or medical.org.² Or I could just:

• establish the task somewhere,
• act on it
• link to a receipt
• mark it done³

I created a special template for org-capture, which places these one-off tasks into todo.org. And it clocks into the task, too.

A topic with even greater complexity is "education." I'm a lifelong learner; my edu.org file has (only) 29 headings, all of which have at least a few subheadings. If I learn about an Emacs feature, I might want to write about it, so I'll put a task into blog.org that links to it.

Occasionally a post will span multiple topics in edu.org, topics such as Emacs, Vivaldi, LibreOffice, HTML or LaTeX. In a year from now, which file should I look for it in? The keystroke C-c a s comes to the rescue.⁴ I might search for "Sacha" because all I remember is that I discovered an Emacs feature on Sacha's website.⁵ Incidentally, I get 13 hits when I search for "Sacha," one of which was the one I had in mind.

The question I think all Emacs users face is, "At what point does tweaking Emacs (and self-quantifying tools in general) tip the scales from aiding our progress to impeding it?" I dread going down a Knowledge Management rabbit hole,⁶ but I'm sure I'll enjoy the leap.

⁰ Charlie Holland's Search for Knowledge

¹ A tree works like your brain.

² Don't even get me started on insurance.

³ All of this occurs while clocked in to the task.

⁴ In this case, C-c a is bound to org-agenda.

⁵ Sacha Chua's blog

⁶ Can one gain knowledge of Knowledge Management Systems without having a Knowledge Management System in which to record that knowledge? That may be a Zen koan for someone.

The Navigation category has a couple of interesting window configuration tips this week in case you prefer to work with just one window or have multiple windows with some of them dedicated to specific buffers.

• Upcoming events (iCal file, Org):
  • London Emacs (in person): Emacs London meetup https://www.meetup.com/london-emacs-hacking/events/315859503/ Tue Aug 11 1800 Europe/London
  • Emacs Berlin: In-Person-Only Emacs-Berlin Stammtisch https://emacs-berlin.org/ Tue Aug 11 1900 Europe/Berlin
  • OrgMeetup (virtual) https://orgmode.org/worg/orgmeetup.html Wed Aug 12 0900 America/Vancouver - 1100 America/Chicago - 1200 America/Toronto - 1600 Etc/UTC - 1800 Europe/Berlin - 2130 Asia/Kolkata – Thu Aug 13 0000 Asia/Singapore
  • Atelier Emacs Montpellier (in person) https://lebib.org/date/atelier-emacs Fri Aug 14 1800 Europe/Paris
  • OrgDevMeetup https://bbb.emacsverse.org/rooms/orgdevmeetup Sat Aug 15 0900 America/Vancouver - 1100 America/Chicago - 1200 America/Toronto - 1600 Etc/UTC - 1800 Europe/Berlin - 2130 Asia/Kolkata – Sun Aug 16 0000 Asia/Singapore
  • M-x Research: TBA https://m-x-research.github.io/ Wed Aug 19 0800 America/Vancouver - 1000 America/Chicago - 1100 America/Toronto - 1500 Etc/UTC - 1700 Europe/Berlin - 2030 Asia/Kolkata - 2300 Asia/Singapore
  • Emacs APAC: Emacs APAC meetup (virtual) https://emacs-apac.gitlab.io/announcements/ Sat Aug 22 0130 America/Vancouver - 0330 America/Chicago - 0430 America/Toronto - 0830 Etc/UTC - 1030 Europe/Berlin - 1400 Asia/Kolkata - 1630 Asia/Singapore
• Beginner:
  • How to learn Emacs, like, for real
  • Emacs for NvChads
  • Emacs for Life [Leanpub PDF/iPad/Kindle]​ ($20+)
• Emacs configuration:
  • Emacs Package Management with package-quickstart - DEV Community (JP, @gemmaro)
  • Tip about setting file-precious-flag by location with my-maybe-mark-file-precious (@tennoseremel@gts.skobk.in)
  • Emacs Config Gems - Part 3 - Melpa, UI, help, and many more
  • Emacs Config Gems - Part 4 - recycle bin, frame size, backups, autosave, autorevert, recentf
  • User Interface to Computer Applications Demonstrated in GNU Emacs (02:09:31) also available as separate videos, see video description
  • Dotfiles Season 1 Episode 4: Emacs Configuration (14:31)
  • Rate my Emacs config! (Reddit)
  • myn-macs (MY miNimal eMACS IDE setup for the lazy terminal wizard) (Reddit)
• Emacs Lisp:
  • Charlie Holland: Gödel, Escher, Elisp: The Beauty of Macros (Reddit)
  • [ANN] TextUI is now public: responsive Flex/Grid layout for widget.el interfaces (Reddit)
• Appearance:
  • Raymond Zeitler: Display Active Clock in Emacs Frame Title (Irreal)
  • paniash/modus-vague: The vague theme for emacs, built on top of modus themes. · GitHub (@paniash@mas.to)
• Navigation:
  • Protesilaos: Emacs: the ‘speedbar’ built-in file explorer (Emacs 31) (YouTube 15:40, Reddit, Reddit, Irreal)
  • Chris Maiorana: Using ffap to jump to file includes in Emacs (YouTube 07:04)
  • Raymond Zeitler: Dedicate an Emacs Window to Its Buffer
  • James Cherti: single-window.el – Always Open Emacs Buffers in the Current Active Window (GitHub, Reddit)
  • Srijan Choudhary: Emacs: desktop-save-mode without the automatic restore (Irreal)
  • My Emacs workflow with project.el and tab-bar.el project-x.el (30:39)
• TRAMP:
  • Runbox.el - for shell/compile/eglot over TRAMP in local buffers (emacs-tangents, Reddit, @cidra@mastodon.uno)
• Dired:
  • Dave's blog: Run the file in Emacs’ dired - path
  • dired-z: zoxide-style directory jumping inside Dired (Reddit)
• Writing:
  • Efficient Note-taking in Emacs with Howm (@qnnnp)
  • Reversible transpose-chars and transpose-words, and a dwim that transposes around "and" or "or" (@jameshowell@fediscience.org)
  • Protesilaos: Emacs: conditionally expand abbrev-mode definitions (YouTube 14:34, Reddit)
  • Using remark to strip words in backtick quotes before write-good analysis (@howard@pdx.social)
  • How Prot Organizes Knowledge, Projects, and Tasks in Emacs (37:53)
  • benleis1/wikimode · GitHub (YouTube, Reddit, @benleis@mathstodon.xyz) - navigate Markdown and Org files like a wiki
• Org Mode:
  • Reviewing finished tasks from last week in org-agenda and emacs (Irreal)
  • Read a .docx in Emacs with its tracked changes and comments intact, as org-mode (Reddit)
  • How to Generate PDFs from Org Mode using ox-odt (26:03)
  • rlridenour/ox-rlr-slipshow: Emacs Org mode exporter to create Slipshow Markdown files. · GitHub (@randyridenour@zirk.us)
  • Org development:
    • ox: New hook that runs after include keywords, but before macros/babel
    • org: Rename statistics scope options
• Coding:
  • Managing Changes with ediff — Alex Carney (@alcarney)
  • Tip about using diff-hl-set-reference-rev (@glyph)
  • [[https://utcc.utoronto.ca/~cks/space/blog/programming/EmacsGitBlameOverTime][Chris's Wiki :: blog/programming/EmacsGitBlameOverTime]] (lobste.rs)
  • The Emacs Cat: Debugging in Emacs
  • Xah Talk Show Ep811. Emacs: CSS toggle px rem (30:21)
• Math:
  • r-ts-mode now on Melpa
• Shells:
  • Eshell shared history (Reddit)
  • Zoxide in eshell (Reddit)
• Web:
  • Andros Fenollosa: EWW, the Emacs browser you underestimate (HN)
• Mail, news, and chat:
  • martianh/mastodon.el 2.1.0: collections (@mousebot@todon.nl)
• Evil mode:
  • Disable mouse drag selection in evil mode (@aud@fire.asta.lgbt)
• Multimedia:
  • Charles Choi: Announcing now-playing.el, an Emacs interface for the macOS Music app (Reddit)
  • Sacha Chua: Replace YouTube captions from Emacs Lisp
• LLMs:
  • kriyative / elisp-agent · GitLab (@kriyative@functional.cafe)
  • blog.fidelramos.net – Supply-chain hygiene for Emacs: LLM review of package upgrades (ES)
  • AGENTS.md - discussion about whether to include AGENTS.md in Emacs source code (HN)
• Community:
  • Sacha Chua: Emacs Chat avec Richard Bonichon en français (YouTube, 01:57:39)
• Other:
  • How to Count Words In Emacs (01:09)
  • Emacs Arbitrary Code Execution Returns (Reddit)
  • bible-gateway package update: touch-typing verse memorisation, reading plans, transient menu, and more (Reddit)
  • graph-fa2 0.2.3 now available on MELPA - graph visualization
• Emacs development:
  • emacs-devel:
    • Re: [PATCH] emoji on TUI emacs - Stefan Monnier via Emacs development discussions. Possible workaround for different composition widths?
    • Re: Discussion about why GNU/Linux system upgrades cause old programs to break - Eli Zaretskii Issues with compiling older versions
  • Show-all values for speedbar user options for hiding
  • Add `outline-occur' command and `display-buffer-default-alist' variable
• New packages:
  • bitbucket-devops: Bitbucket Cloud DevOps workflows (MELPA)
  • denote-smart-sluggify-title: Denoise denote titles to save filename length (MELPA)
  • graph-fa2: ForceAtlas2 pure-elisp background-cached engine (MELPA)
  • pimacs: Emacs Client for Pi (MELPA)
  • ronny-theme: A dark colorscheme inspired by Monokai (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 a purely-for-fun exercise: a guide to web design for terminal browsers. Starting from the text browsers people actually use, I am going to pull out a set of rules in case you ever decide to build a site meant to read and look its best in a terminal. It is not an alternative to Gemini, Gopher or a smallweb attempt, but a set of best practices so your site reads well in a terminal browser, and even so you can build Web Apps for the terminal.

Five engines, one test

The first step is to install the five text engines people actually use and feed them the same test pages, isolating one feature at a time.

• w3m (0.5.6): the most capable with tables, and it even draws images in terminals that allow it.
• lynx (2.9.3): the patriarch, the lowest common denominator since 1992.
• links (2.30): fast, with a little bit of CSS.
• elinks (0.20.0): the cousin with bigger ambitions, it even has an optional CSS engine.
• EWW: the Emacs one.

Now we look for the compatibility crossovers. You test HTML and CSS features and see how each engine interprets them.

The results:

From this we draw some general conclusions:

• JavaScript does not exist. In any of them. It is not slow or partial. There simply is no interpreter.
• CSS is almost a mirage. Stylesheets, whether <style> or <link>, are ignored in all of them except elinks, which applies a few things like text-align. Four out of five engines do not read your CSS. Design as if it were not there.
• display:none is a trap. If you hide something with a class (class="hidden" and .hidden{display:none} in your sheet), all five engines show it. Every one. Because they do not read the sheet: do not hide anything important with CSS. If it should not be seen, do not put it in the HTML.
• Images are text. Only EWW (and w3m in some terminals) actually draws the image. In the rest, the image is its alt attribute. All five fall back to alt when the image is broken, and an image with no alt leaves you a [hero] with the file name, or nothing at all. alt is not accessibility for others, it is your content.
• <details> does not fold. None of the five make it interactive. The summary and the body always show, one after the other.
• HTML5 semantic tags are invisible. article, section, nav, header, footer, main, aside: they are transparent containers. They do not add a single line break. Their value is semantic, not visual.

With that, we can lay down a few design lines and best practices.

8 rules for publishing to the terminal

1. DOM order rules

There is no float, no flex, no grid, no order. Whatever you put first in the HTML comes first on screen. So place the content right after opening the <body> and send the long navigation and the footer to the end. A reader who opens your article does not want to tab through thirty menu links before reaching the first sentence.

2. Mark structure with tags, not styles

Real headings <h1>..<h6> for the hierarchy, never a <div class="big-title">. Lists with <ul>/<ol>, definitions with <dl>. Quotes with <blockquote>, which all of them indent. Code with <pre> and <code>. Each engine gives them its own treatment: use them for what they mean.

3. Your page must read with CSS turned off

This is the touchstone. If you disable CSS and your page becomes unreadable, it is not the terminal browser's problem, it is your HTML's problem. Spacing (margin, padding, line-height) does not exist: the separation comes from paragraphs. Structure with real <p>, not with loose <br>.

4. Do not convey information with color alone

A "required field in red" or a "green = correct" evaporate. Inline color is the most fragile thing in the table: it depends on the terminal and its configuration, and in many cases it does not even show. Always pair color with text or a symbol. An "Error:" in front, an asterisk, anything.

5. Tables for data only, never for layout

EWW and w3m draw a surprisingly good ASCII grid, colspan and rowspan included. But a layout table produces an absurd, unreadable grid. Watch the width: if the columns add up to more than the terminal's, the experience degrades. Fewer columns and short cells win.

6. Images with a descriptive alt and srcset

alt is what you see in four out of five engines. Make it a sentence, not an image1.png. And if the image is pure decoration, give it an explicit alt="": that way the reader ignores it instead of reading you the file name. A missing alt and an empty one are not the same thing. Offer srcset with several resolutions, and the engine that can show images will pick the right one. And do not rely on an image to communicate anything critical, because in most engines they do not load at all.

7. Real forms

No JavaScript submissions. A <form> with its action and its method (GET or POST), and an <input type="submit"> or a <button>. Put a name on every field: the engines collect by name, and a field without one is lost. Associate a <label> with each one.

8. Headers that do count

<title> always, descriptive: lynx and links center it at the top, and all of them use it to identify the page. <meta charset> in UTF-8 as an encoding fallback. <base> if you use relative links, which all of them respect. And serve over HTTPS, since several engines flag the certificate status.

TerminalSpeed Insights

A guide you cannot run is a list of good intentions. So I wrote a prototype. It is a Python script that reads an HTML file, or a URL, and gives you back a readability score with the specific warnings. The number is a heuristic, not a science. I hand out the points by eye, an error weighs more than a warning and that is that. What really matters is the list of warnings, not the scoreboard.

You can download it from its repository, TerminalSpeed Insights, and run it against any page:

python3 terminalspeed.py https://your-site.dev/

Running it over a few popular sites, the ones leaning more on content than design, I get some numbers:

At the top are the wikis, the docs, the text sites and the ones that fly the minimalism flag. At the bottom, curiously, two of the sites most loved by people who read in the terminal. It is no coincidence: the ones that score high serve the content first and lean on the tags, not on CSS. EmacsWiki, for instance, is almost plain HTML, and that is why it reads on anything that can show text.

Still, these are numbers not every browser shares. Open Hacker News in w3m and you will see the front page perfectly readable, with its numbered list of headlines, despite that 55. w3m draws tables so well that it survives. The validator is not wrong to penalize it, it flags real friction, but friction is not always a death sentence. Take the score as a guide, not a verdict: a 100 almost guarantees it reads well, a low number tells you where to look.

Not just documents: a Terminal Web App

So far I have talked about documents: articles, cards, docs pages. We still have to squeeze the forms: GET and POST work in all five engines. And a form that works is, no more and no less, an application.

Let me show you with a coffee shop:

<form action="/order" method="post">
  <p><label>Your name <input type="text" name="name"></label></p>
  <p><label>Quantity <input type="number" name="qty" value="1"></label></p>
  <p><label><input type="checkbox" name="no_milk" value="yes"> No milk</label></p>
  <p><button type="submit">Order coffee</button></p>
</form>

And this is how it looks in EWW, the Emacs browser. The fields are edited with the keyboard; here I have already filled in the name, the quantity and checked "No milk":

You hit submit and the <form> does a POST. The server responds with a redirect (the good old Post/Redirect/Get pattern) and the browser paints the confirmation, all without leaving the keyboard or touching the mouse:

Look at the detail: heading in bold, the link colored, the quantity and the no-milk option collected correctly. It is a stateful app, interactive, with no JavaScript and without a single kilobyte of framework. And yes, it scores 100 with the validator.

It is a real application: it lives in the text browser, but it looks just as good in Chrome or Firefox, because underneath there is only HTML. You get a terminal interface without touching ncurses or any TUI library. Your toolkit is HTML, your renderer is the browser and your logic lives on the server. The same app, a language you already know, and it works everywhere.

Conclusion

It has been a fun investigation. Almost nobody designs their sites for the terminal, it is a minority and, even so, it is an audience that exists. And there is no shortage of reasons: these are visitors who want accessibility or speed, who are on low resolutions or who work with pipes. More than once I have found myself doing quick searches in EWW, or reading an article there for the visual comfort.

You can take it as a curious article or as another approach to web design. I, at least, will start looking at my pages with different eyes.

I hope you enjoyed this other point of view on web design.

Help me keep writing Every coffee gives me a push toward the next article. Sure, it's on me!

Send an email to comment+article-70d817e8@andros.dev to leave a comment. The subject will be ignored.

The single-window package forces Emacs to open buffers in the current active window.

It keeps your carefully arranged layouts intact, reduces visual clutter, and provides a much more predictable workflow.

To ensure it does not break standard Emacs functionality, the package is built to handle the following edge cases and integrations out of the box:

• Transient and Magit: Excludes Transient buffers by default, which ensures that Magit popup menus render correctly and manage their own window placement.
• Ediff control panel: Excludes the Ediff control interface so it can maintain its specific layout requirements without breaking.
• Temporary and utility buffers: Ignores the minibuffer, asynchronous Emacs warnings, Org capture popups, and built-in *Completions* buffers so they do not hijack your active workspace.
• Dedicated windows: Safely handles dedicated windows in the background (e.g., grep-mode or embark-export), temporarily un-dedicating them to load the buffer without throwing errors or breaking the layout.
• Org-mode integrations: Configures Org-mode to open source blocks, the agenda, and indirect buffers directly in the active window
• Manual overrides: Allows you to temporarily bypass the single-window enforcement by passing a prefix argument (e.g., C-u) before running a command.

The package also provides the following customization options:

• Custom window rules: Provides a setting (single-window-respect-display-buffer-alist) that lets you prioritize your own custom display rules for specific buffers, while falling back to the single-window behavior for everything else.
• Customizable exclusions: Allows you to define additional exclusions via the single-window-exclude-regexps variable, which accepts a list of regular expressions to match ignored buffer names.
• Popper integration: Provides single-window-exclude-popper (disabled by default) to allow popper to bypass the single-window package enforcement for its popups.

If this project helps your workflow, please consider supporting it by ⭐ starring single-window on GitHub and sharing it on your website, blog, Mastodon, Reddit, X, LinkedIn, or other social media platforms so other Emacs users can discover its benefits.

Installation and Usage

Emacs: use-package and straight (Emacs version < 30)

To install single-window with straight.el:

Step 1: It if hasn't already been done, add the straight.el bootstrap code to your init file.

Step 2: Add the following code to the Emacs init file:

(use-package single-window
  :straight (single-window
             :type git
             :host github
             :repo "jamescherti/single-window.el")
  :config
  (single-window-mode 1))

Alternative installation: use-package and :vc (Built-in feature in Emacs version >= 30)

To install single-window with use-package and :vc (Emacs >= 30):

(use-package single-window
  :vc (:url "https://github.com/jamescherti/single-window.el"
       :rev :newest)
  :config
  (single-window-mode 1))

Alternative installation: Doom Emacs

Here is how to install single-window on Doom Emacs:

Step 1: Add to the ~/.doom.d/packages.el file:

(package! single-window
  :recipe
  (:host github :repo "jamescherti/single-window.el"))

Step 2: Add to ~/.doom.d/config.el:

(after! single-window
  (single-window-mode 1))

Step 3: Run the doom sync command:

doom sync

Frequently Asked Questions

What does this provide over display-buffer-alist?

The single-window package provides a minor mode that handles edge cases.

While similar behavior can be replicated by adding a catch-all rule to display-buffer-alist, this often disrupts standard Emacs functionality.

For instance, forcing all buffers into the active window via display-buffer-alist interferes with packages that rely on specific user interface layouts, such as Ediff, Transient (which includes Magit), Org Agenda, and many others. This package resolves this by providing default configurations that natively exclude these specific edge cases.

Additionally, the package manages dedicated windows. For example, if a user attempts to open a file directly from a dedicated grep-mode or embark-export search results buffer, standard display rules will often cause Emacs to split the frame. The single-window package intercepts this action, temporarily removes the dedicated flag so the buffer can load in the active window, and then restores the original state.

It also includes a fallback mechanism. If Emacs is forbidden from using the current window (e.g., you invoke a command while inside the minibuffer), Emacs usually splits the frame. This package catches that edge case and safely uses another existing window instead.

Finally, the package allows bypassing the strict window enforcement for individual commands by supplying a prefix argument (C-u).

What is the difference with popper?

The single-window and popper packages are not mutually exclusive and can be used simultaneously.

The popper package displays temporary buffers in a dedicated popup area, typically at the bottom of the screen, which allows for quick dismissal.

In contrast, single-window prevents automated window splitting. It also provides a mechanism for exceptions, allowing specific packages, such as Transient, and popper itself, to bypass the strict single-window enforcement and split the frame as originally intended.

Author and License

The single-window Emacs package has been written by James Cherti and is distributed under terms of the GNU General Public License version 3, or, at your choice, any later version.

Copyright (C) 2026 James Cherti

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program.

See also

• popper
• auto-side-windows
• current-window-only
• popwin

Links

• single-window.el @GitHub

Other Emacs packages by the same author:

• compile-angel.el: Speed up Emacs! This package guarantees that all .el files are both byte-compiled and native-compiled, which significantly speeds up Emacs.
• outline-indent.el: An Emacs package that provides a minor mode that enables code folding and outlining based on indentation levels for various indentation-based text files, such as YAML, Python, and other indented text files.
• easysession.el: Easysession is lightweight Emacs session manager that can persist and restore file editing buffers, indirect buffers/clones, Dired buffers, the tab-bar, and the Emacs frames (with or without the Emacs frames size, width, and height).
• vim-tab-bar.el: Make the Emacs tab-bar Look Like Vim's Tab Bar.
• elispcomp: A command line tool that allows compiling Elisp code directly from the terminal or from a shell script. It facilitates the generation of optimized .elc (byte-compiled) and .eln (native-compiled) files.
• tomorrow-night-deepblue-theme.el: The Tomorrow Night Deepblue Emacs theme is a beautiful deep blue variant of the Tomorrow Night theme, which is renowned for its elegant color palette that is pleasing to the eyes. It features a deep blue background color that creates a calming atmosphere. The theme is also a great choice for those who miss the blue themes that were trendy a few years ago.
• Ultyas: A command-line tool designed to simplify the process of converting code snippets from UltiSnips to YASnippet format.
• dir-config.el: Automatically find and evaluate .dir-config.el Elisp files to configure directory-specific settings.
• flymake-bashate.el: A package that provides a Flymake backend for the bashate Bash script style checker.
• flymake-ansible-lint.el: An Emacs package that offers a Flymake backend for ansible-lint.
• inhibit-mouse.el: A package that disables mouse input in Emacs, offering a simpler and faster alternative to the disable-mouse package.
• quick-sdcv.el: This package enables Emacs to function as an offline dictionary by using the sdcv command-line tool directly within Emacs.
• enhanced-evil-paredit.el: An Emacs package that prevents parenthesis imbalance when using evil-mode with paredit. It intercepts evil-mode commands such as delete, change, and paste, blocking their execution if they would break the parenthetical structure.
• stripspace.el: Ensure Emacs Automatically removes trailing whitespace before saving a buffer, with an option to preserve the cursor column.
• persist-text-scale.el: Ensure that all adjustments made with text-scale-increase and text-scale-decrease are persisted and restored across sessions.
• pathaction.el: Execute the pathaction command-line tool from Emacs. The pathaction command-line tool enables the execution of specific commands on targeted files or directories. Its key advantage lies in its flexibility, allowing users to handle various types of files simply by passing the file or directory as an argument to the pathaction tool. The tool uses a .pathaction.yaml rule-set file to determine which command to execute. Additionally, Jinja2 templating can be employed in the rule-set file to further customize the commands.
• kirigami.el: The kirigami Emacs package offers a unified interface for opening and closing folds across a diverse set of major and minor modes in Emacs, including outline-mode, outline-minor-mode, outline-indent-minor-mode, org-mode, markdown-mode, vdiff-mode, vdiff-3way-mode, hs-minor-mode, hide-ifdef-mode, origami-mode, yafolding-mode, folding-mode, and treesit-fold-mode. With Kirigami, folding key bindings only need to be configured once. After that, the same keys work consistently across all supported major and minor modes, providing a unified and predictable folding experience.
• buffer-guardian.el: Automatically saves Emacs buffers without requiring manual intervention. By default, it triggers a save when the user switches to another buffer, switches to another window or frame, Emacs loses focus, or the minibuffer is opened. Beyond standard file buffers, buffer-guardian also manages specialized editing buffers such as org-src and edit-indirect. Additional features, disabled by default, include periodic or idle-time saving of all buffers, automatic exclusion of remote, nonexistent, or large files, and support for custom exclusion rules via regular expressions or predicate functions.

Part four of Emacs Config Gems is about basic file operations and save functions. I realized as I was working on this that I have the frame configuration here, which is the wrong place for it. I will change it after posting. Alright, here we go.

When deleting a file in Emacs, we should use the system’s trash (or recycle bin) instead of deleting the file permanently, giving us a chance to restore the file in case we’ve made a mistake.

In addition, since we have this turned on, we can also tell Emacs to always delete non-empty directories (because they’ll go to the trash) instead of prompting. It’s just faster.

(setq delete-by-moving-to-trash t)
(setq dired-recursive-deletes 'always)

Let’s set the frame Emacs starts with to be a bit bigger. In Emacs, these measurements are in lines and columns (character width), so we’re basically saying: “make the default frame 100 characters wide and 55 lines high.”¹

(setq default-frame-alist
   '((width . 100)
     (height . 55))
    )

We might want to move Emacs’ backup files and temp files (those are the ones with ~ and #)² to a different dedicated folder (emacs-bks) instead of the main Emacs folder. Since Emacs won’t just create the directory for us, let’s ask it to do so³. It won’t throw an error if we already have it.

(make-directory "~/emacs-bks" t)
(setq backup-directory-alist
      `((".*" . "~/emacs-bks")))
(setq auto-save-file-name-transforms
      `((".*" "~/emacs-bks" t)))

Now, let’s turn on the option to automatically save files we are working on inside Emacs, and set how long Emacs needs to be idle before auto-save kicks in. In my case, 300 seconds (= 5 minutes) is good enough for idle time. Importantly, I want to emphasize again, idle time. It will not auto-save the file as long as you type, so if you type non-stop for an hour and suddenly lose power, this will not save you, since Emacs didn’t get the chance to be idle for 5 minutes (or even 30 seconds, which is the default). For this, we have auto-save-interval, which auto-saves every 300 characters (globally in Emacs) by default. In my case, I’m lowering it here to 100, since I write plenty of quick notes (using org-add-note, C-c C-z), and it’s common for me to keep using Emacs between those without hitting the 300 mark. Both of those are described in the manual under auto-saving.

(auto-save-visited-mode t)
(setq auto-save-visited-interval 300)
(setq auto-save-interval 100)

Auto-revert checks the buffer we’re visiting against the saved file itself. If the buffer has no changes, but the saved file does have changes, it loads those changes into the buffer silently. However, if the buffer has changes (meaning, we’re writing something into the file and we haven’t saved yet), it won’t do a thing and won’t say anything. Since my particular setup means that all of my org files are inside a folder synced by Syncthing, this is ideal: if I save changes to a file on my Mac, when I switch to my Linux desktop I’ll have the file and the buffer visiting it refreshed and ready to go, provided of course that Syncthing is working and the sync is complete⁴.

(global-auto-revert-mode t)

Activate recentf mode, so Emacs has a list of the recent files we worked on last time, up to 30 by my config. 10 is too little; 50 starts to feel more like “everything I opened this month,” which defeats the purpose. Useful when we don’t want to navigate to the same file each time, and we don’t want to have a bookmark. Note: since I’m using consult, recent files are integrated and show under the file header in the consult minibuffer, and can be quickly viewed with f while visiting the consult minibuffer.

(recentf-mode t)
(setq recentf-max-saved-items 30)

I installed Donovan Ratefison's brand-new Vakana app¹ on my Android device this morning. After following the tutorial, I exported the thread as an Org-mode-compatible package in a ZIP and emailed it to myself in order to transfer it to my desktop.

After opening the Org file that Vakana generated, I exported the entire buffer to HTML. The result is shown below. The only change I wanted to make was to scale the bead of each heading 25%.²

It's fortuitous that Donovan Ratefison released Vakana in a month whose Emacs Carnival theme is "The Search for Knowledge," because Vakana provides a unique way to manage one's knowledge. I'll need to become proficient in it before adding it to my workflow. So my eventual Emacs Carnival submission will be more pedestrian.

¹ Learn about Vakana here or download here.

² The images used for beads are SVG files. However this blogging platform does not support that file type, so I converted them to GIF for this post. This should explain why they don't look awesome.

Your first thread

Your first thread
A 90-second tour. Walk it bead by bead, then make it yours — delete it, or reload it anytime from Settings → Pro Tips.

Table of Contents

• 1. The thread
• 2. Start here · a 90-second tour
• 3. 1/5 · Tap the bead
• 4. 2/5 · Open the thread
• 5. 3/5 · Comment — swipe me right
  • 5.1. Comments
    • 5.1.1. Comment — [2026-08-09 Sun 18:50]
• 6. 4/5 · Long-press a bead in the list
  • 6.1. Comments
    • 6.1.1. Comment — [2026-08-09 Sun 18:22]
    • 6.1.2. Comment — [2026-08-09 Sun 19:14]
• 7. 5/5 · Close it, then make it yours

1. The thread

2. Start here · a 90-second tour

[2026-08-09 Sun]

Welcome — and if this is all new, that’s perfectly fine. We’ll go gently.

Vakana is the Malagasy word for beads — there’s no other word for them in the language, and it’s where this app takes its name. The idea is old and simple: you turn a moment into a small bead — a little coloured token — and beads you keep together form a thread you can walk back along, like beads on a string. (These six notes are already a thread — “Your first thread.”)

That’s the whole shape of it. What a bead means is always yours — the app never decides that for you.

This is a short, hands-on tour: five steps, each one a thing you try yourself.

Next → 1/5 · Tap the bead.

3. 1/5 · Tap the bead

[2026-08-08 Sat]

,*Tap the bead* at the top of this note — the composer opens. That’s where you pick a bead’s shape, pattern, mood-colour and a tiny glyph (this one’s is the number 1️⃣).

Eight shapes, eight patterns, eight moods — small enough to learn, wide enough for anything. There’s no legend: a circle isn’t “an encounter” unless you decide it is.

How does the user navigate the beads? Now I see "< Prev" and "Next >" so it's obvious.

Next → 2/5 · Open the thread.

4. 2/5 · Open the thread

[2026-08-07 Fri]

You’re on a thread right now — a chain of beads strung together on purpose. Open “Your first thread” (tap its chip here, or find it in the Threads view) and you’ll see all six beads in a row you can walk, bead by bead.

The app also keeps a quiet thread for every day you write, under Days in the Threads view — built for you, no effort.

Next → 3/5 · Comment.

5. 3/5 · Comment — swipe me right

[2026-08-06 Thu]

Some thoughts arrive after the moment. Instead of rewriting a note, leave a comment in its margin.

Try it: tap the 💬 at the top of this note — or, back in your list, swipe this row to the right. Either opens the margin, where you can jot a thought or even set it to remind you later.

(The next bead, 4️⃣, already has a comment — spot the 💬 on its row.)

Next → 4/5 · Long-press the bead.

5.1. Comments

5.1.1. Comment — [2026-08-09 Sun 18:50]

The tutorial shows an icon for comment as a white-filled rectangular balloon with three dots. However the actual icon is a balloon that's an empty circle

6. 4/5 · Long-press a bead in the list

[2026-08-05 Wed]

Beads repeat, and you’ll want to find a bead’s kin. This is a thing you do from your list, not from inside a note — so head back to the list first.

There, press and hold any bead: the list instantly filters to every bead like it. (Long-press is the move most people miss.)

Want finer control? Tap the funnel at the top of the list to filter by shape, mood, pattern or glyph, then gather the results into a brand-new thread.

Next → 5/5 · Make it yours.

6.1. Comments

6.1.1. Comment — [2026-08-09 Sun 18:22]

I keep coming back to this one — long-pressing a bead is the move most people miss.

6.1.2. Comment — [2026-08-09 Sun 19:14]

The alarm clock icon next to the note field is for a reminder, not a timestamp. It puts it on the next business day at 9:00 a.m., perhaps. I pressed it at 3:00 p.m. on Sunday August 9th, and then entered the reminder for the next day at 9:00 a.m..

7. 5/5 · Close it, then make it yours

[2026-08-04 Tue]

This thread is closed — notice the clasp. Closing marks a loop that finished; you can reopen it anytime.

A finished thread can leave the app: open it and Export to turn it into a web page or a slide deck.

That’s the whole grammar — bead, thread, comment, close, export. Now make it yours:

• Delete this tour — swipe any note left, or remove it in one tap from Settings → Pro Tips → Interactive tutorial. • Want it back later? Reload from the same place.

Now write your first real moment, and bead it however you like.

Created: 2026-08-09 Sun 16:42

Validate