The ability to mark items in GNU Emacs Dired allows for bulk operations on both files and directories. With marking, onerous tasks can be turned into a trivial ones.

While default Dired has many bulk operation commands, not everything is covered. That is the motivation for mdired, an Elisp package which extends Dired with some SIMD-style commands.

Using these commands fall into two steps:

1. Mark the items of interest in Dired.
2. Run the mdired command.

mdired supports the following four commands:

• mdired-copy: copy a single file to multiple directories.

• mdired-do-command: run an Elisp command or named keyboard macro on multiple files.

• mdired-compile: run compile on multiple directories.

• mdired-byte-recompile: byte-compile selected files or directories.

Refer to the mdired User Guide for more details on usage.

Closing Thoughts

Bulk operation commands are chainsaws. Use them with caution. That said, they are great for improvised workflows:

• “Here’s this file that I want copied to a bunch of directories.”
• “I want to do the same edit operation on this set of files. I’ve got a named keyboard macro ready to go on them.”
• “I want to run the same make command on a bunch of directories.”

As mdired is new, I’m open to feedback on it. Let me know what you think.

mdired v1.0 is now available on MELPA.

After grumbling about the inadequacy of LaTeX previews in Emacs – and specifically Org mode – for over a decade, Tecosaur and I decided to take the leap and rewrite the feature from the ground up. The result is a preview system for LaTeX math that can provide near-WYSIWYG feedback but retains the properties we expect in the Emacs environment: text-first, extensible and composable.

It’s not much code, but it contains many moving pieces and makes contact with several corners of Emacs. Now that the feature is part of Org mode, I thought I would take this opportunity to document how it works from the ground up, and use it as a launchpad to explain relevant aspects of Emacs’ event loop and its unofficial package API Emacs doesn’t really have a “package API”, since you build Emacs packages from the same elements as Emacs itself. .

This article is not an exhaustive demo of all the shiny new features, although there are a few videos peppered throughout. It’s also not the user manual (not yet updated on orgmode.org) or a tutorial (see Tecosaur’s This Month in Org writeup).

Instead, it aims to provide an overview of the goals and design of the library, along with some explainers of relevant aspects of the Emacs API and tips to write your own features. This write-up is for you if you are interested in

• a broad understanding of LaTeX preview generation (how and why),
• learning about Emacs’ event loop, subprocess interaction, overlay-based display and UI, or
• a case study on building a non-trivial Emacs “application” from scratch.

What is org-latex-preview?

This is a feature included with Org mode to preview LaTeX math snippets as images in Emacs buffers. The contents of LaTeX fragments and environments in Org mode are replaced with rendered images.

It has existed for decades at this point, but in a form that I consider barely usable; this rewrite overhauls the code base and adds a number of quality-of-life features. There is a 13 minute demo that can give you a good idea of the new capabilities of Org mode:

The bullet points, if you prefer:

• Preview generation is fully asynchronous Or as asynchronous as Emacs in its current form allows. , with images placed continuously as they are generated
• Bulk generation: Preview 200 to 800 snippets per second
• Previews blend in correctly with surrounding colors
• Automatically match the current Emacs theme (even through theme changes)
• Previews are aligned with and scaled to match the font baseline and size
• Previews auto-generate for newly inserted LaTeX
• Previews auto-update as you change the underlying LaTeX
• Preview as you type: Live-previews of LaTeX fragments
• Consistent (correct) equation numbering across the document
• LaTeX compilation error reporting for previews

And a couple more quick demos:

The rest of this article is mostly about how it works, and briefly why. As such, it has a “fractal” level of detail. There is information intended

• to give the casual reader a bird’s eye view of LaTeX preview generation,
• to give the motivated reader a detailed look at its many pieces,
• for the potential new Emacs package author looking for pointers on aspects of Emacs’ API,
• for folks wanting to develop a similar feature for applications other than Emacs,
• and information that is of no use whatsoever except to the future maintainers of the org-latex-preview library.

To that end, many details are tucked away in blocks like the following. You can safely ignore them in favor of the top-level headings, images and video demos.

Implementation details

Blocks like this describe the concrete implementation of aspects of the code.

This is probably only interesting if you are looking to dive into the code itself, or if you are looking to write a similar package.

Emacs API notes

Blocks like this are for additional notes on aspects of Emacs’ API, including the odd code snippets.

Warning: Here be idiosyncratic takes.

Org Mode notes

Blocks like this describe other Org features relevant to LaTeX preview generation.

Command output

Blocks like this describe CLI commands associated with this process, or their output.

Isn’t this a narrow feature to spend so much time on?

Indeed, this feature

• requires a LaTeX distribution installed,
• works only with Org mode (for now),
• and is glued together from several processes and grossly inefficient in the larger scheme of things.
• It’s also finicky, as all hyper-configurable software is.

LaTeX was not built with the aim of minimizing latency. Having to start multiple new processes even for a one-character change places a hard cap on what’s possible in terms of real-time feedback. Implementing an equivalent preview feature for a system designed for modern computers, like Typst, is trivial in comparison.

Moreover, as popular as Org mode is, it’s a small player in the space of markup languages. The fraction of Org and LaTeX users who would prefer to use Org mode to write LaTeX is smaller still. And while Org attempts to integrate well with LaTeX, navigating the mishmash of Org and LaTeX syntax presents an extra learning curve on top of learning to use the two markup languages individually.

But it also has a few things going for it.

First, LaTeX is ubiquitous, and Org mode is a far more convenient format for writing than raw LaTeX. There is significantly less visual noise (think Markdown vs HTML), and Org provides an escape hatch for adding LaTeX verbatim. Org’s simple interface for shuffling text around, monitoring task progress and executing code blocks makes it easy for eventual LaTeX documents to begin as Org files. Since everything in Emacs composes with everything else, your system for (say) fast LaTeX input transfers over to Org mode seamlessly.

Second, the fact that Org is versatile as a publishing tool implies that some benefits of better LaTeX support transfer over to other formats too, like equations in HTML or ODT exports.

There is a wide swath of applications built on Org mode that benefit from LaTeX math input, such as Org Roam and Org Noter. For these applications converting Org documents to LaTeX is not the goal, as they are not primarily publication tools: they stick around as private digital archives, and better LaTeX support is a bonus to the user’s expressivity.

Real-time feedback when editing LaTeX snippets is a categorical improvement to the user’s experience. I did not realize this when I started work on org-latex-preview, but now I wouldn’t want to LaTeX without it. It baffles me that web LaTeX editors (Overleaf etc) don’t provide this out of the box, especially as they target novice LaTeX users. .

Finally, we can keep Org mode out of the picture: org-latex-preview can technically work anywhere in Emacs, and in every major-mode. it’s just not there yet (See below) .

But perhaps the most germane reason is that Emacs users don’t shy away from settling comfortably into tiny, cramped and poorly insulated niches. Comes with the territory!

The Objectives

Never Block Emacs

Emacs users are closely acquainted with its frequent unresponsiveness. You’re never more than one minor-mode or mode line indicator away from causing Emacs to block or lag. While it’s not a big ask to wait a second for the result of an action you initiate, the unresponsiveness often manifests as short random freezes, which is unacceptable. But there’s more. Beyond the annoyance and inconvenience, poor responsiveness denies us an entire class of uses: real-time feedback is everything for interactive applications.

Owing to both its design and age, Emacs is not very well suited for asynchronous applications. Certain patterns of asynchronous usage are viable (see below), but concurrency support is limited and parallelism is absent: no worker threads, channels, async-io, or anything of the like.

The upshot is this: we want org-latex-preview to be as asynchronous as possible within Emacs’ effectively single-threaded event loop model. The goal is to minimize how long the user has to wait, in terms of both the overall run time and the fraction of that for which Emacs is unresponsive. We end up having to trade these off against each other.

Go Fast (relative to LaTeX and Emacs)

A close second concern is preview generation speed. This is desirable both in the large and the small. Previewing upwards of a hundred LaTeX math fragments in a math-heavy Org document used to be an exercise in patience. Now it takes about one second, and can be much faster with some trade-offs.

Provide Real-Time Feedback

Speeding up bulk generation is at most a boost in convenience. You don’t regenerate a large buffer’s worth of previews more than once every few sessions, and the resulting images are cached anyway. The more interesting aspect is that speed enables a close to real-time feedback loop that wasn’t available before. This is especially useful when you’re deep inside a messy structure like an array:

No more counting field separators. No more exiting, regenerating and re-examining snippets. It’s the best parts of WYSIWYG and visible markup, together.

Look Pretty

Even in the niche of academic types who use Org mode with LaTeX, there are very different orientations. There’s Org the transient format, where an Org document starts out as a rough sketch, a thought bubble translated to the screen, and soon transitions into a TeX file that becomes the source of truth. There’s Org the intermediate publication format, where the document lives as an Org file, but its value is in the web page or PDF document it eventually becomes. For the adherents of this style the appearance of the Org document is irrelevant.

Finally, there’s the class of uses described above, where the desired output is the Org document itself, or a cross-linked collection of them. These are folks who care about the aesthetics of Org documents and often suffer a thousand cuts in trying to make Emacs look “modern”.

One of the objectives of org-latex-preview is to ease their self-imposed burden somewhat: LaTeX previews should blend in perfectly with the surrounding text. This means

• preview image sizing that is consistent with surrounding text,
• with perfect baseline alignment at any font size,
• and Emacs theme-aware colors that change automatically with the theme.

Getting the fonts to match is possible too, but requires some degree of compromise on the part of the user You could start by using the variable-pitch Latin Modern font in your Org documents. .

Each of these is a long-standing issue with LaTeX previews in Org, and Stack Overflow and the usual haunts have decades of discussions on how to fix them, with band-aid after band-aid proposed as solutions. We took an elephant gun to this problem, starting by throwing out the giant mess that was Org’s accreted LaTeX preview code of the past two decades.

Here’s a demo of theme-aware LaTeX preview colors:

Windfalls: Consistent numbering, error reporting

Finally, there are a few features we picked up along the way because they came free.

Recording compilation errors was a simple matter since we scan the LaTeX output anyway.

Consistent equation numbering was expensive in the past because numbering changes can propagate across the document, and parsing the Org document and LaTeX fragment compilation were both slow. Recent changes to Org have made the former a non-issue (see the parsing section below), and the performance scaling of our bulk LaTeX runs has fixed the latter.

There are several more minor features along for the ride, such as improvements to editing LaTeX with org-edit-special (C-c ').

The Emacs API: An Overview

As mentioned in the introduction, the LaTeX preview system draws on a few different facets of the Emacs API: mainly async process interaction (the “backend”) and overlays (the UI or “frontend”). The live-updating behavior leans heavily on hooks and timers, and we join these pieces together with very simple Lispy data structures, like alists and plists.

We also (naturally) use a few Org mode specific APIs, including ones developed by us for this purpose. We cover these further below as we encounter them.

The Substrate: Emacs’ Event Loop

If you are designing an Emacs application that interacts with the outside world, it helps to start with a mental picture of Emacs’ event loop. To a first approximation, the main loop does only four things:

• Read input events: This includes keyboard, mouse and touchscreen events, but also some OS signals. This is the user’s interface to Emacs.
• Evaluate commands and redisplay: This is the heart of the Lisp evaluator, and Emacs’ interface to the user.

Together these two connect the user and Emacs. If the main loop did only these two things Emacs would still qualify for the title of “Lisp evaluator masquerading as a text editor”, but it wouldn’t be nearly as useful. For that we need it to

• Read subprocess output: This includes output from “regular” processes like shell commands or LaTeX, but also network requests. This connects Emacs to the world (your computer and the network) , and vice-versa. Command shells, LaTeX previews, LLM clients and most IDE features work because of this.

The last event loop function combines the above three, but across time:

• Run timers: Schedule code for the future and run them when timers are ripe. Somewhat tentatively, I’m including garbage collection here.

This design explains why timers in Emacs are not reliable in the absolute sense. The timer runs not when it’s ripe, but when it’s ripe and when the main loop gets around to it. Nevertheless, scheduling code provides a much-needed degree of flexibility to a rigidly ordered task list.

The way these four tasks are actually organized in the main loop code is less pleasing:

Also, Emacs is obviously doing things outside of the event loop as well. Font caches are compacted, Emacs is responding to the compositor and some OS signals, interacting with dynamic modules, and so on. In the currently experimental MPS branch, some garbage collection activities also occur in the background. These are invisible to the Lisp evaluator and thus out of scope when learning to build an Elisp package.

The Backend: Subprocess Interaction

This design suggests that Emacs can only do one thing at a time As of Emacs 31 , so that designing a responsive application is a steep ask. But the situation is more nuanced:

1. Yes, the Lisp evaluator holds a global interpreter lock. At any point in time Emacs is doing exactly one of the following: painting the screen (redisplay), updating syntax highlighting (fontification), running hook functions or timers, responding to window changes, handling keyboard input, and – crucially for us – interacting with subprocesses. Every action is thus blocking.

2. The only asynchronous interaction possible is by starting an OS-level subprocess Another lie, since we have dynamic modules, covered below. . Emacs continues to run independently from the subprocess, but it still has to handle its STDOUT and STDERR streams and respond to process signals. When it is doing this, it cannot pay attention to your input or anything else. Again, Emacs can only do one thing at a time.

   Starting asynchronous subprocesses

   There are multiple commands to start an asynchronous subprocess from Emacs (see M-x shortdoc process), but start-process covers most common use cases.

         (setq my-process-object
               (start-process "name" "buffer-name" "program" "--arg1" "--arg2" "..."))
   

   Processes are (optionally) associated with a buffer where process output is inserted. To send a subprocess some input, there’s process-send-string and process-send-region. Responding to process output and signals is the responsibility of process filters and sentinels (next block). kill-process does what you’d expect. All of these functions take the process object that start-process returns as an argument.

   Except for some fiddly details, that’s essentially all there is to the process interaction API. There are several variants of start-process available – the synchronous call-process, the shell versions start-process-shell-command and call-process-shell-command, and so on. The only one that does something different is the primitive make-process, which is a more extensive version that can (additionally) create network processes, send data through TCP or Unix sockets and so on.

3. Emacs will try to prioritize user input events. To do this it can delay tasks like reading from subprcesses if necessary. Idle timers are another example of this. Some actions are thus delayable, but they block Emacs when they (eventually) run. There might be a penalty to pay afterwards, for instance when there’s more subprocess output to process as a result of delaying the task.

   Process filters and sentinels: Handling process output

   By default, Emacs inserts the output from a subprocess into the process buffer, or ignores it if there is no process buffer. (Crucially, it still has to read the output from the process pipe.) This is good enough for simple tasks. To use or transform subprocess output in more specialized ways, you can write an elisp function that is used as a process filter. It is called whenever Emacs reads new process output. In the language of shell commands, I think of process filters like this:

         $ start-process "some-process" 2>&1 | process-filter
   

   Process filters can be tricky to write if you want to parse structured process output, because the amount of data that Emacs reads from the pipe can be arbitrary. Unless latency is a concern, it’s often preferable to work with process sentinels for this reason. Sentinels are the second tool Emacs makes available for reacting to processes. A process sentinel is an elisp function (callback) called whenever the process changes state or raises a signal, including when it terminates. Practically speaking, I think of them like this:

         $ start-process "some-process" 2>&1 > process-buffer && \
             process-sentinel < process-buffer
   

   They are typically used for cleaning up after the process, and updating Emacs’ state depending on how the subprocess ends. But you can use them to access the process buffer containing all the process output, and thus do whatever you would in the filter.

   Filters and sentinels can be attached to a subprocess object created with start-process using set-process-filter and set-process-sentinel respectively.

4. Many blocking operations can be interrupted by signaling a quit: this is what pressing C-g does, with some variations, in most contexts. Crucially for us, however, quitting is suppressed when Emacs is handling subprocess output or signals This is to keep your C-g from doing something unpredictable to “background” code that you didn’t initiate. . If Emacs is blocked because it’s reading a large data dump… well, tough luck.

Despite these carveouts, a package that interacts heavily with external processes faces a latency-throughput tradeoff. The more time Emacs spends starting processes and managing their output, the less attention it can pay to your input. Designing Org’s LaTeX preview thus involves finding an acceptable balance.

It is significantly easier to write a large Emacs library than an equally versatile plugin for most plugin systems built around multi-threaded GUI applications. I say this as a non-programmer who has only succeeded at the former. We lean on the interpreter lock in many ways, choosing simple data structures and control flow that wouldn’t work if Emacs was multi-threaded. But most of Emacs wouldn’t work if Emacs was multi-threaded, anyway. In for a penny…

The Frontend: Displaying images over text

Overlays are a way to alter the appearance or behavior of regions of buffer text without modifying the text itself. Displaying images is one of their most common uses: LaTeX preview images are overlaid on top of the source fragments.

Once you have the preview images in hand, placing them in overlays and managing their state is essentially all the LaTeX preview code does.

In fact, overlays account for much of the display trickery in Emacs: Images over text? Overlays. “Virtual text” like in whitespace-mode? Overlays. Inline results of code evaluation: overlays. Multiple cursors? Those are overlays. Emacs has only one cursor.

(setq ov (make-overlay BEG END))

(move-overlay ov NEW-BEG NEW-END)

These alterations are specified by adding or modifying the overlay’s “properties”. Like symbol properties, overlay properties are a way to store arbitrary information along with the overlay, and org-latex-preview uses them to keep track of state, such as whether the preview image is out of date because the LaTeX fragment has been edited, and to store LaTeX compilation errors for the corresponding fragment.

(overlay-put ov prop value)
(overlay-get ov prop)

Some properties have special meanings as interpreted by Emacs’ display engine. display, the most common property, changes how the overlay region appears on screen, and this is typically set to the image we want to see in place of the text.

But several more interesting modifications are possible with overlays, such as changing the face (font+style) of the underlying text, making it invisible, making it intangible to the cursor, or specifying keymaps that are activated when the cursor is within the bounds of the overlay.

(let ((img (create-image "/path/to/image.png")))
  (overlay-put ov 'display img))

(overlay-put ov 'face 'shadow)

(defun notify-on-ov-change (ov after-p beg end &optional _)
   (when after-p
     (message "Text changed: %s"
              (buffer-substring-no-properties beg end))))

(overlay-put ov 'modification-hooks (list #'notify-on-ov-change))

(overlay-put ov 'mouse-face 'highlight)
(overlay-put ov 'help-echo "You're on an overlay, pal.")

(overlay-put
 ov 'keymap
 (define-keymap "RET"
   (lambda () (interactive)
     (when-let* ((img (get-char-property (point) 'display))
                 ((imagep img))
                 (file (image-property img :file)))
       (start-process "view-image" nil
                      "xdg-open" file)))))

(let* ((img (image-create "/path/to/image.png"))
       (spacing (propertize
                 " " 'face 'default
                 'display
                 `(space :align-to (- center (0.5 . ,img))))))
  (overlay-put ov 'display img)
  (overlay-put ov 'before-string spacing))

The Reactive UI: Hooks and Timers

In its basic form, the LaTeX preview feature involves no reactive behavior: there is one command to overlay preview images on LaTeX fragments, another to clear those overlays, and nothing else.

But this is a far cry from our goal of real-time feedback. For LaTeX previews to be automatically generated and updated as we type, we need both timers and hooks.

Hooks are variables provided by Emacs where we can register code to run at certain points. In this case, we want to react primarily to two kinds of user inputs:

• Cursor motion, so that entering a previewed LaTeX fragment reveals its source and leaving it re-displays the image.
• Buffer changes, so that a preview generation subprocess automatically fires when a new LaTeX fragment is typed in or an existing one is edited.

In turn, org-latex-preview exposes hooks of its own for consumers to run additional processing. These fire when LaTeX subprocesses finish, when overlays are created, and so on.

Timers are complementary to hooks, used to space out or limit the consequences of hooks firing. They are used

• to keep these hooks from firing all the time, which would create redundant subprocesses with each edit, locking up the main loop. They provide the means to implement throttling and debouncing.
• to delay clean-up tasks like deleting intermediate LaTeX output until Emacs is idle.

The structure of org-latex-preview

Besides basic Elisp data structures, that’s everything we need from Emacs to implement non-blocking, fast LaTeX previews. Assuming you have a handle on what org-latex-preview does, we can start peering into the how.

How it works: control flow

Here is a high-level overview of the control flow of LaTeX preview generation:

This is a rough picture of how LaTeX previews are generated in Org mode, subdivided into tasks The made-up term “task” corresponds to a handful of functions devoted, in our heads, to one purpose. . Each action belongs to one of three categories:

• Blocking tasks: These must run synchronously and thus require the user to wait while Emacs is unresponsive. We want this to be minimal and/or done ahead of time.
• Delayable tasks: These tasks can be delayed if more immediate actions – such as accepting user input – are pending. However, once such a task is started it runs synchronously and we’re locked in. We want this work to be chunked into small independent pieces.
• Asynchronous tasks: These are subprocesses spawned by Emacs and managed by the OS. Emacs monitors the process status and handles process output in a delayable fashion, but is otherwise unencumbered by them.

When a LaTeX preview command is issued, the first chunk of processing (the PREPARE block)

1. sets up overlays in the buffer that “cover” the fragments, with the intent to add preview images to them at the end,
2. creates a TeX file containing the relevant LaTeX fragments from the Org buffer, along with a preamble. This preamble is optionally precompiled, which can speed up processing considerably.

It then starts a two step process chain (the RUN block) that runs asynchronously. The end result of a successful run is a preview image or series of images.

The PROCESS FILTERS block: From this point on until either process ends, Emacs checks in periodically through the associated process filter, acting on the STDOUT to capture various bits of preview metadata. It also keeps track of images that have finished processing, and (synchronously) caches them and adds them to the overlays in the buffer for these fragments. This continuous update is doubly useful:

• Previews start appearing in the buffer much faster, with the window viewport being updated first.
• This processing happens in small chunks instead of all at once at the end, so Emacs stays more (even if not fully) responsive to input.

The POSTPROCESS block: After the subprocesses have finished, Emacs runs their process sentinels, which clean up the detritus of this process chain, or reset the buffer if the preview run failed.

And speaking of detritus…

How it works: file I/O

This figure shows the same process but with an emphasis on disk I/O. The primary chain is TeX file → DVI/PDF output file → SVG/PNG preview images.

Of the file categories involved in the process, we care about two: the “format dump file” produced by precompilation, and the preview images. Both are cached and persisted across Emacs sessions. All other produced files are deleted by the POSTPROCESS block.

How it works: data flow

Displaying previews that are color-, alignment- and size-aware, along with associated information like errors, requires a considerable amount of bookkeeping. Since this information arrives piecemeal and processing happens asynchronously in chunks, we also need some way of storing and passing along this context. There are perhaps clever ways to do this, but we use a straightforward solution – a (dynamic) global plist that associates each active process chain with its data (see org-async below).

All of the data generated and required for the many tasks in our process chain are captured in a single mutable container, referred to here – for convenience – as “Extended Info” (extended-info). This data includes

• User preferences for the preview run, such as the LaTeX compiler in use,
• Input LaTeX strings to be rendered,
• Input file paths, output image paths and image cache details,
• Emacs’ context like the current buffer – which is important since we need to restore it before we can run asynchronous callbacks,
• Overlay positions and properties,
• Compilation errors,
• Computed preview geometry and fontsize for alignment,

and more besides.

(cl-defun foo (&key (buf (current-buffer)) (valid-p t) (pred #'ignore)
                    &allow-other-keys)
  ;; body of foo
  )

(foo :buf some-buffer :valid-p t :pred #'always)

(let ((arglist `(:buf ,some-buffer :valid-p t :pred ,#'always :unknown-key nil)))
  (apply #'foo arglist))

How extended-info is populated

The setup functions in the PREPARE block initialize this bucket with data from parsing the buffer – i.e., LaTeX fragment locations, equation numbers, etc. From then on, each task updates extended-info with progressively more information. The structure of extended-info and this flow of information into it is visualized in this “data flow” diagram:

Contained in “Extended Info”: “Processing Info” contains information about and relevant to the external process (LaTeX and the image converter). “Fragment” is a list of metadata for fragments to be previewed, including the overlays that will eventually display the preview images. All of this preview metadata is obtained from the outputs of the latex and image converter runs via the process filters.

Note that Emacs’ interpreter lock precludes data races and other concurrency issues, since only one function modifies extended-info at a time.

How extended-info is accessed

The above chart only captures the flow of data in one direction: from the sources of computation into the extended-info container. Tasks that don’t modify extended-info still need to read it to do their jobs. For example,

• Clean up temporary files needs the paths to the temporary files.
• Cache images and metadata needs the generated image paths, as well as all the geometry metadata.

Most functions in the process chain are passed extended-info, or a subset thereof, as an argument.

Once again, we get away with it because there are no concurrency problems when there is no concurrency. This design pattern of passing around a single heap-allocated container across setup functions and callbacks works for all kinds of applications in Emacs. This is exactly how Org’s (synchronous) export system manages information as well.

org-latex-preview Pieces and the Org API

This is where we get into the weeds. If you’re here for the bird’s eye view, you can skip ahead to Live previews now.

Parsing

This is the Collect LaTeX Fragments task in the control flow diagram.

Org’s syntax is extensive, and parsing Org files used to involve a giant mess of regular expressions. Thankfully the mess is now handled by the org-element library, which provides a simple and powerful API for querying or acting on Org’s AST. A fair amount of work has gone into making it perform well under the constraints of Emacs’ single-threaded event loop Besides caching its state, it uses timers to schedule parsing work outside of the times the user is interacting with Emacs. .

Crucially for us, Org has first-class support for LaTeX environments and fragments, and this greatly simplifies parsing and metadata handling. This support is what makes using LaTeX in Org a pleasant experience in the first place.

The objective of the parsing step is to find the bounds of LaTeX fragments in the buffer (or in some region). In principle, we could do this with org-element:

(org-element-map
    (org-element-parse-buffer)
    '(latex-environment latex-fragment)
  #'identity)

But this would be too slow, and would allocate far more memory than we need. Instead, we use a simple regexp scan of the buffer to find the bounds of LaTeX fragments and environments, and org-element only to gather specific metadata about these elements.

Preamble generation

This is the Create preamble task in the control flow diagram.

Many editor plugins (and web apps) implement LaTeX previews, usually via MathJax or KaTeX. KaTeX is fast, and both function well for web pages with limited needs. But they implement ersatz support for a limited number of LaTeX packages, and cannot consume an actual “full-fat” LaTeX preamble of the kind you might use when writing a research paper. There is no \usepackage{} macro or TikZ support, for example.

By comparison, org-latex-preview is backed by a full LaTeX engine and LaTeX distribution, so nothing is off the table. Of course, this means we need a way to construct the preamble and feed it to the LaTeX engine.

In addition to Emacs-wide settings (like org-latex-preview-preamble and org-latex-packages-alist), document-specific LaTeX headers can be specified with the #+latex_header: directive:

#+latex_header: \newcommand{\sOmega}{{\scriptstyle \Omega}}
#+latex_header: \DeclareMathOperator{\diag}{diag}
#+latex_header: \DeclareMathOperator{\toep}{toep}
#+latex_header: \usepackage{calc,cancel}
#+latex_header: \usepackage{rotating}
#+latex_header: \usepackage{tikz}

The combined preamble must be constructed when exporting the Org document to LaTeX, and this machinery lives in the ox-latex library. org-latex-preview simply calls into it for the preamble. Among other benefits, this means the preamble used for the preview run is identical to the one used for LaTeX exports unless you want them to differ, because of course Org provides ways to do that , so these truly are previews.

This does make ox-latex one of the few dependencies of org-latex-preview, which is regrettable given the larger aim of providing LaTeX previews across Emacs.

Precompilation

This is the Precompile LaTeX preamble task in the control flow diagram.

To process a preamble, the LaTeX engine needs to tokenize and execute tens of thousands of lines of macro source. For a complex preamble, the kind you would use for a book, this can take several seconds on a modern processor.

Since org-latex-preview aims to provide close to real-time feedback as you type, we resort to a trick from the 1990s: we serialize the entire engine state – the string pool, macro bodies as token lists, font data, engine execution parameters and so on – into a single binary memory image. This process, called format dumping or precompilation, was automated for document preambles by David Carlisle’s mylatex.ltx, modernized as the mylatexformat package by Florent Chervet.

The upshot is that precompilation saves a significant amount of LaTeX startup time, reducing and (almost) flattening it across all preamble sizes.

Precompilation relies on a number of hacks and only works because pdftex has changed little for decades. Unfortunately, precompilation is not supported at all by xelatex and only partially by lualatex preambles that load OpenType fonts or Lua code are unsupported , so org-latex-preview is slow with the Unicode engines.

Under a different LaTeX preview architecture, none of this would be needed. But it’s what we have so far: a very 90s solution for a very 90s editor.

Creating the TeX file

And speaking of being stuck with an old architecture, depending on pdflatex implies that we have to create and feed it a TeX file for each batch of previews pdflatex and friends do accept input via STDIN, but this did not work out for finicky reasons. .

This is the Create TeX file task in the control flow diagram.

As you might expect, the generated TeX file contains a reference to the precompiled dump file and a listing of all the LaTeX fragments to be previewed. Instead of placing them into the document separated by something like \pagebreak, we place them inside \begin{preview} and \end{preview} blocks provided by the preview.sty CTAN package.

preview.sty is authored by David Kastrup, who also wrote the Emacs-side preview.el package that’s part of AUCTeX. preview.el was the inspiration for org-latex-preview – it was clear at least that previews in Org mode could be much, much faster.

preview.sty does three critical things for us:

1. It places each preview snippet (enclosed within \begin{preview} and \end{preview} blocks) on a separate page in the LaTeX output;
2. it finds the boundaries of the generated text and crops the page down to them;
3. and it reports the font size, image size and baseline position in the LaTeX process’ output stream.

These modifications were technically doable through a combination of other packages (Org’s old implementation used the tightpage option of the preview machinery), but in cumbersome and error-prone ways.

This makes preview.sty an external dependency of org-latex-preview. Fortunately this package is included by default even with minimal installs of all common LaTeX distributions.

The process runner

The pipeline from the LaTeX fragment text in the TeX file to images suitable for preview consists of two steps. A LaTeX engine (pdflatex, xelatex or lualatex) produces DVI, XDV or PDF output, which is fed to an image converter (dvisvgm, dvipng or imagemagick) to produce PNG or SVG images. This is the RUN block of the control flow diagram.

This involves a fair bit of bookkeeping, and Emacs’ callback-based async process management (via “process sentinels” and “process filters”) isn’t the most ergonomic tool for this. In the absence of reliable async-io support, we use org-async, a declarative process chain manager now bundled with Org mode.

(setq task-spec
      (list 'org-async-task             ; <-- LaTeX compilation task
            '("latex" "-interaction" "nonstopmode" "texfile.tex")
            :buffer t
            :info extended-info
            :filter #'latex-preview-filter
            :failure #'latex-failure-callback
            :success (list 'org-async-task ; <-- Image conversion task
                           '("dvisvgm" "--page=1-" "-o out-%p.svg" "texfile.dvi")
                           :buffer t
                           :info extended-info
                           :filter #'dvisvgm-place-previews-filter
                           :failure (list #'dvisvgm-failure-callback
                                          #'log-errors-callback
                                          #'cleanup-callback)
                           :success (list #'check-fragments
                                          #'cleanup-callabck))))

(org-async-call task-spec)

An example of this bookkeeping is that the pipeline isn’t always serial. When generating PNG images with dvipng, we start LaTeX and dvipng in parallel. Dvipng processes pages of the DVI file as they appear, while the LaTeX process is still churning them out. (Generating PNG preview images for a large Org buffer is much faster than the other routes.)

Tracking with process filters

On the other side of the process invocation are the “process filters”, which are callbacks called by the event loop whenever Emacs reads chunks of subprocess output. This is the PROCESS FILTERS block in the control flow diagram.

some-process 2>&1 | process-filter

latex -interaction nonstopmode -output-directory /tmp preview-file.tex | latex-process-filter; \
dvisvgm --page=1- --bbox=preview -o image-file.svg preview-file.dvi | image-converter-process-filter

{ latex -interaction nonstopmode -output-directory /tmp preview-file.tex | latex-process-filter; } & \
{ dvipng --follow -T tight --depth --height -o image-%09d.png preview-file.dvi | image-converter-process-filter; }

In org-latex-preview’s process filters we look for the output (DVI or image) file paths, but also a variety of metadata that preview.sty and dvisvgm emit. This includes geometry information like the width, height and baseline alignment of the image, and any compilation errors.

Preview: Fontsize 10pt
! Preview: Snippet 1 started.
<-><->

l.9 \begin{preview}

Preview: Tightpage -32891 -32891 32891 32891
! Preview: Snippet 1 ended.(973936+0x22609920).
<-><->

l.14 \end{preview}

pre-processing DVI file (format version 2)
processing page 1
  applying bounding box set by preview package (version 13.1)
  width=346.003754pt, height=15.362961pt, depth=.501877pt
  graphic size: 346.003754pt x 15.864838pt (121.606411mm x 5.575853mm)
  output written to /tmp/org-tex-ang3Se-000000001.svg
1 of 1 page converted in 0.16035 seconds

[1 (preview-latex version 13.1) (preview-latex tightpage option detected, will use its bounding box) depth=1 height=29]

“Whenever Emacs reads chunks of subprocess output…”

This phrasing omits some important but fiddly details about how often and how much output is read at a time, in much the same way as the Unix pipe | symbol does.

While the event loop is switching between its four main tasks continuously, there are (only) a couple of knobs available at the Elisp level to manage how Emacs reads subprocess output.

• read-process-output-max limits how much it reads in one event loop turn. Setting it to a high value means output from chatty processes will be read sooner, but at the expense of blocking user input. This is, essentially, Emacs’ latency vs throughput curse in a nutshell.
• process-adaptive-read-buffering tries to delay reading from subprocesses that produce very small chunks of data at a time, as this is inefficient. In practice turning this on has tended to make things worse instead of better when running most subprocesses.

Trying to optimize this for org-latex-preview has proved to be… difficult. The rates and sizes of output emitted varies significantly between different LaTeX engines and image converters:

They differ even between different versions of the same program across Texlive versions:

org-latex-preview settles for a broadly acceptable set of defaults in this regard.

But the main reason we use process filters here is that we can place images in the buffer as they are generated (and read in from the process STDOUT by the event loop), and don’t have to wait for the LaTeX or image converter processes to end.

Cleaning up with process sentinels

The unfortunate result of being forced to do file I/O at each step of the pipeline is that we are left with a trail of intermediate files that need to be swept away Instead of, say, a block of shared memory that can simply be freed. . This is the POSTPROCESS block in the control flow diagram, accomplished in the “process sentinels”.

A process sentinel is a callback invoked by the event loop when the process changes status. In principle this includes any status change (exit, signal, stop/continue), but in practice we only care about it after the process exits.

Clearing the intermediate detritus of the compilation is not an urgent task, so org-latex-preview’s process sentinels actually schedule this on an idle timer. Their other major function in this design is to diagnose process failures and restart the job when the cause looks transient.

Caching

This is the Cache images and metadata task in the control flow diagram.

LaTeX preview generation is an order of magnitude (or two) faster than what Org did before, so caching preview images might seem like a secondary concern. But org-latex-preview still caches images, for a few reasons:

• The same state may be encountered dozens of times when editing a fragment with live previews.
• We would like to avoid rerunning LaTeX in contexts where the Org document itself is the final output, such as in-Emacs slideshow programs.
• When exporting to other formats (HTML or ODT), org-latex-preview is responsible for generating the images to be bundled with the web page or document.

In addition to the text of the LaTeX fragment itself, preview images are specific to the LaTeX preview pipeline configuration, the preamble, the Emacs theme and even the fragment’s position in the buffer when equation numbering is turned on. To cache previews reproducibly, all of these inputs are hashed together as the key to the cached image.

Displaying images and overlay management

This covers the in-buffer UI and affordances of org-latex-preview, indicated by the Create overlays and Place LaTeX previews blocks in the control flow diagram.

Beyond what is covered in displaying images over text, displaying the image itself is simple: the image just needs to be resized and aligned according to the recorded geometry. The overlays themselves are set up before starting the LaTeX run, and a series of overlay properties are set or unset over the course of the process.

• If an existing image is being updated, the overlay optionally gets a “face” property indicating that the preview is out of date.
• If this is a fresh preview, an overlay property marks it as “processing”, displayed in the fringe.
• If any compilation errors are captured, they’re placed as tooltip text via an overlay property. Via the SVG’s currentColor attribute, we also color the overlay image red to indicate that there was an error.

These are basic but (hopefully) intuitive indicators of the state of the preview.

Live previews: Hooks galore

The breakdown provided so far does not explain the claims we made in the objectives section, like real-time (or at least fast) feedback as you type. As seen in the demos above, there is one more element to making the previews appear “live” and reactive to cursor movement or buffer edits.

For the seamless hide/show behavior:

• Moving the cursor into the region covered by the overlay should “open” the overlay, reveal the underlying text and move the image next to or below the LaTeX fragment.
• Moving the cursor out of the region should do the reverse, and “close up” the overlay.

For real-time feedback:

• Editing a fragment with a visible preview marks the preview out of date, so the image should either disappear or be updated.
• If editing displaymath and the numbering changes, all other numbered environments in the buffer should be updated as well.
• Editing a previewed fragment in another buffer (with org-edit-special, C-c ') should cause the preview to be updated as you type.
• When typing or pasting text, LaTeX environments need to be detected and parsed, and the preview pipeline started in real time.

All of these are achieved using hooks, which is ultimately the only mechanism we have to trigger reactive behavior in Emacs. The hide/show behavior involves tracking the cursor position via pre-command-hook and post-command-hook (made buffer-local). Buffer edits are tracked via after-change-functions, but with several fast-fail heuristics to avoid slowing down Emacs The difficulty of identifying, in real time, $ and $$ as LaTeX delimiter starts, delimiter ends, or as actual dollar signs is why live previews require the unambiguous \(...\) and \[...\] delimiters, even though the dollars are supported in non-live usage. . The list goes on, since we need to track Org’s folding states, as well as changes in other buffers when using org-edit-special.

The other strategy we’re forced to employ, given the event loop’s limitations, is to throttle and debounce pipeline calls, batching edits and avoiding race conditions between in-flight LaTeX runs – the interpreter lock protects Elisp state, but independent subprocesses will happily interleave and clobber each other’s output.

Finally, this feature is the source of dozens of edge cases, such as editing fragments inside folded regions (during global text replacement, say), or the many invalid intermediate states of a LaTeX fragment causing the preview to fail repeatedly. Knocking down these bugs while keeping this path fast was a substantial portion of the effort over the years this library was developed Now that it’s part of Org mode and seeing more widespread use, there are no doubt several more edge cases waiting to be reported! .

LaTeX previews everywhere in Emacs

A proof of concept: the design of org-latex-preview makes it possible to preview LaTeX outside of Org mode. Here’s an example previewing LaTeX-formatted comments in a prog buffer (Clojure, here):

In fact, you can use the same code to preview LaTeX fragments literally anywhere in Emacs, including, delightfully, the Emacs calculator. This (18 minute) demo runs through a bunch of contexts outside of Org mode showcasing live LaTeX previews:

While this feature exists only as a prototype, it’s simple to implement and extend. To see why, let’s look again at the preview process breakdown. All tasks here are agnostic of Org mode save for two:

• Collect LaTeX fragments: currently handled by org-element,
• Create preamble: currently assembled by the org-export (ox-latex) library.

To use LaTeX previews outside of Org mode, we only need providers for these two tasks:

• A parser that can identify the boundaries of LaTeX fragments in the buffer Technically you could reuse org-element in non-Org buffers for this, but there will be many false negatives and occasional false positives. . This does not need to be a full-fledged parser – just a regexp scan of the buffer looking for \begin{ or \[ can suffice. This is how the above demos were created.

• A LaTeX preamble generator appropriate for the buffer. This can just be a constant string (instead of a function) that includes a reasonable set of LaTeX packages. I used Org’s default LaTeX preamble string everywhere in the above demos.

(require 'org-latex-preview)

(org-latex-preview-place 'dvisvgm entries nil preamble)

;; entries is a list of lists
;; Each entry is (start end),
;; or (start end contents)
((1342 1388)
 (1911 2104)
 (2273 2295 "\\( \\epsilon + 3 \\)"))

;; preamble is a preamble string
;; See `org-latex-preview-preamble'
"\\documentclass{article}
 [DEFAULT-PACKAGES]
 [PACKAGES]
 \\usepackage{xcolor}"

As of late 2026, abstracting the library from its major-mode adapters remains on the TODO list.

How a modern LaTeX preview system should work

When we started org-latex-preview in 2021, live-updating previews were not available anywhere except one LaTeX formula-editing website and, to a lesser degree, LyX. We often wondered why, since preview.sty did most of the work for you and the editor side was pretty simple to implement. If org-latex-preview were a thrown-together external Emacs package providing many of the same features (sans polish), it could have been written over a couple of weekends. I know this because I wrote it. Twice.

Over the years, however, this feature has grown in ubiquity and there are plugins for most note-taking (Obsidian) and editing software (Neovim, VS Code) that provide this. Emacs itself has at least four active implementations of live LaTeX previews now, and a frontier LLM can probably implement a basic version for your preferred platform with one prompt.

Even so, Emacs remains the oldest platform to implement this feature, and does so in the most complete and mature form As of 2026. . Considering I spent a lot of this write-up complaining about the limitations of the Elisp runtime, this is remarkable.

But creating temporary files after every buffer change and spawning separate LaTeX processes remains a terrible way to do real-time updates. Precompilation is another hack, unsupported by LaTeX engines besides pdflatex. While org-latex-preview is a massive improvement over the previous LaTeX preview implementation for Org mode, it’s still the Elisp equivalent of a Bash script that got out of hand. Quite simply, this is the wrong level at which to address the problem. A better way to implement continuous previews would be to talk to a managed process over a pipe or socket. The right approach here is to work at the level of the TeX engine, as TeXPresso does.

But it would be even better to avoid inter-process communication entirely and use an Emacs dynamic module, linking with a modern LaTeX library that does incremental (instead of batch) compilation. “Lightweight” alternatives like KaTeX or MathJaX don’t cut it, since we need a full-fat LaTeX compiler, macros and all. One possible candidate for this is realtime-tex, the rtex library, which embeds LuaLaTeX (the most modern of the LaTeX engines) and compiles incrementally and effectively instantaneously Although I would be inclined to wait for the project to mature. . This would be a quality improvement almost as drastic as the one org-latex-preview makes over its predecessor.

Of course, a dynamic module linking an incremental compiler is a completely different architecture from what we have now, and would share at most the image display and UI layer. So projects like this and the inevitable official Typst preview package for Org are tabled for another day. Maybe you’ll be the one to implement them?

This is a long one but I really want to get transcript+links sorted out, so I might as well share the transcript draft as I go along.

• 0:00 Linux is the library that Emacs uses to talk to my hardware
• 0:05 Highlight: AI churn
• 0:17 Highlight: Maybe your editor makes you grumpy
• 0:26 Highlight: shelling out to Emacs from Vim
• 0:39 Highlight: My husband
• 0:46 Highlight: automation
• 1:00 Highlight: Thumbnail: my daughter rates it 0 out of 5
• 1:14 Sacha's idea for monitoring six EmacsConf calls at once
• 1:47 Intro
• 3:07 frazzor749
• 3:27 Intro
• 5:07 Weekly news
• 5:27 EmacsConf
• 9:20 Cross-pollination
• 12:01 Not Emacs vs Neovim; it's about what we can imagine
• 12:20 What's the catch?
• 13:05 Unix Power Tools
• 14:02 What is Meta x?
• 14:24 Searching handwritten sketches: Evernote to ripgrep
• 16:03 Manila to Toronto
• 16:50 Not about converting people, but about finding the tools that fit you best
• 17:23 What do I do right now?
• 18:38 Learning French
• 18:57 Sitting out the AI churn
• 20:10 Thanking YouTube members
• 21:00 Backstory of real-time speech-to-text transcript
• 23:15 Demo: real-time transcript and instant replay in Emacs
• 24:03 Demo: Video editing witin Emacs
• 27:51 Demo: generating video title cards from WebVTT in Emacs
• 29:06 fframes, generative AI
• 29:49 Demo: Stepping through SVGs in Emacs
• 29:56 I draw on an iPad with Noteful
• 30:20 Light themes and dark themes
• 30:58 Art and stick figures
• 31:58 Linkarzu's video editing workflow
• 33:05 Local CPU-only speech recognition in Emacs
• 35:15 Sharing speech commands
• 36:14 Speech commands and more shortcuts
• 36:23 Having fun with speech commands
• 37:01 Dictionaries for correcting speech recognition
• 38:19 Demo: Adding a misrecognized term to my common edits dictionary
• 39:57 Turning video transcripts into searchable blog posts
• 42:07 Demo: Saving and cropping screenshots from a video at a timestamp
• 43:22 Demo: M-x doctor with speech in and out
• 44:09 Demo: speech-enabled conversation with a large language model in French
• 45:46 Sacha's Linux setup: XFCE, X11 and Emacs on top
• 47:18 Automating other apps with Emacs; X11 versus Wayland for automation
• 49:15 Just a regular laptop keyboard
• 49:56 Using Emacspeak to deal with laptop screen failure
• 51:45 Anticipating physical and cognitive challenges
• 52:37 Describing Emacspeak
• 53:51 Linkarzu adjusts his electric sitting/standing desk
• 54:13 Parenting and fragmented time
• 56:20 Capturing tasks from the phone with Orgzly Revived
• 1:01:55 Sacha Chua on AI and the Emacs community
• 1:08:03 Kids' obsessions: Harry Potter, Pokemon, Wings of Fire
• 1:14:46 AI-generated code, slop PRs and the Lisp Curse in Emacs
• 1:20:58 Advice for Emacs beginners: connect with people
• 1:25:16 Why is the Neovim subreddit toxic while Emacs is friendly?
• 1:31:02 Planning an Emacs and Neovim panel with Prot
• 1:35:53 Do editors and terminals still matter with AI agents?
• 1:41:04 Speech synthesis in Emacs: whispering slide hints

0:00 Linux is the library that Emacs uses to talk to my hardware

Sacha: At the moment, Linux is the library that Emacs uses to talk to my hardware.

0:05 Highlight: AI churn

Sacha: I'm going to sit out all the AI churn. I'll figure that out. And then I will check back in next year, a couple of years, maybe never, and see if there's anything else I can help with.

0:17 Highlight: Maybe your editor makes you grumpy

Sacha: Hypothesis number two. Maybe your editor makes you grumpy. Turns out I cannot say start streaming reliably. Sometimes I say start screaming.

0:26 Highlight: shelling out to Emacs from Vim

Sacha: And the guy hemmed and hawed and eventually admitted that he had actually shelled out the Emacs to run the code and evaluate it and then get the image, get the layout back and then put it in Vim.

0:39 Highlight: My husband

Sacha: I came here for my masters and stuck around because of my husband who is coincidentally a Neovim user.

0:46 Highlight: automation

Sacha: I find myself automating things that really aren't technically justified by how often I do it, but because all those little bits of code add up and they become useful in a combinatorial way.

1:00 Highlight: Thumbnail: my daughter rates it 0 out of 5

Sacha: So you got like a zero out of five.

Linkarzu: A zero out of five. And it's one of my favorite ones, Sacha, come on.

1:14 Sacha's idea for monitoring six EmacsConf calls at once

Sacha: In fact, I have EmacsConf coming up, right? And sometimes we get to the point of having six simultaneous conversations. I might have to actually monitor all of them. So I'm thinking of making myself a little overlay that lets me tab to the different web conferences and then do something fancy with the audio stream so I can isolate it and maybe have some speech recognition running on all of them in the background so that if somebody says, "Help, Sacha!", I can just pop them right up.

Linkarzu: Oh yeah, quite interesting.

1:47 Intro

Linkarzu: So I don't like doing an intro and all of that stuff, so thank you for being here. Sacha, this is the first time that you've been on the channel, right?

Sacha: Yeah, yeah. I mean, you've had plenty of time, so you've certainly crossed over into the Emacs community and things like that. But I'm not sure, am I the oldest Emacs user you've had so far?

Linkarzu: The Professor, he's like 80 years old. But you're not talking about age, your age, but you're talking about Emacs, right?

Sacha: [He would] definitely have been using it for longer than I am. I'm a relative newbie compared to those folks, right?

Linkarzu: No, I was just playing. I always play that he's like 80 years old, but no, he's not. You know the Professor by any chance?

Sacha: I came across some of your videos with him.

Linkarzu: Okay. That is why I found out about you. Because he was like, you should check Sacha Chua's blog. And I was like, who is Sacha? You know, because I knew Prot, I knew, you know, the system crafters, DistroTube, stuff like that. But he is the one that mentioned Sacha. And I was like, okay... How do you pronounce your name, by the way? Is it Sacha? Sacha? Am I saying it wrong?

Sacha: Sacha Chua.

Linkarzu: Sacha Chua. Okay, okay. So, the professor is definitely not 80.

3:07 frazzor749

Linkarzu: You see what frazzor749... frazzor749 is an Emacs user, the guy in chat there.

Sacha: Oh yeah! Yeah, yeah, frazzor749.

Linkarzu: I'm going to convert him to Neovim.

Sacha: No, he's been helping me with French. Leave him alone. He's mine.

Linkarzu: Okay, you know him? You know him?

Sacha: Hands off.

3:27 Intro

Linkarzu: Okay, let me just play a little video of what I know about you. You're going to see it in the background. It's going to be a little bit confusing, okay? But this is just so that people have a little bit of context on who Sacha is, okay?

Sacha: I'll try not to laugh too much.

Linkarzu: Okay, so what do I know about Sacha? She has a YouTube channel. You have close to 5000 subscribers, right? Also, you have a blog, which is pretty popular out there. You do EmacsConf, which I don't know what it is. I'm curious to hear about it a little bit more. And I've seen your livestreams. I've seen that you speak in French. So I'm like, is French her main language? Is English her main language? You've been doing Emacs for, you mentioned, 25 years. Is that right?

Sacha: Yeah, it's about...

Linkarzu: Okay, okay. And I heard about you because of the professor. He mentioned your blog in one of the live streams we had. And I think that's about it. I don't know, like, a lot more. And that's what this call is for, you know, to get to know you a little bit more. Like, on the Neovim side of things, I don't know if a lot of people know you. On the Emacs side of things, you seem to be pretty popular. So... You want to share a little bit about you. Like, who is Sacha? You can share your screen if you want. You can share your blog post if you have some notes or something like that. It's up to you.

Sacha: I think you've already covered all the basics.

5:07 Weekly news

Sacha: I've been enjoying playing around with Emacs for the past 25 years and I love putting together a weekly newsletter. I'm going to try to convince you or someone in your community to put together a newsletter like that for Vim because it's such a great way to come across all the interesting things that people are sharing.

5:27 EmacsConf

Sacha: Because I also want to encourage people to get cool demos out of their head and off their computers and into a form other people can watch. I help organize EmacsConf, which is a yearly Emacs party. We're just sharing the cool things that we've come up with and meeting people with similar interests. It's all online. And then I get to turn all of those into captions so that people can search them afterwards. It's a lot of fun.

Linkarzu: Is it like a live stream? Is it like a video thing? Or what is it?

Sacha: Yeah, we're live streaming on December 12 and 13. We have two days of two tracks. That's how much people want to talk about Emacs. It's kind of like NeovimConf, except we actually run everything on time.

Linkarzu: Oh! Who copied who? Did you copy Neovim or Neovim copied?

Sacha: No, this iteration has been since 2019. The first one was in 2013. So this one's been running since 2019 completely online and completely free.

Linkarzu: And where can we watch it? Is it in your channel or is there an official YouTube channel?

Sacha: All right. So we have like this whole thing, right? It can be watched using entirely free and open source software. If you go to https://emacsconf.org, you can find all the details. So people can watch it using MPV or VLC or whatever. We'll stream it over Icecast. But of course, since a lot of people come through YouTube, I'll also restream it through the EmacsConf channel.

Linkarzu: Oh, so it has a YouTube channel, EmacsConf.

Sacha: Yes, which we don't actually talk about much, but if you search for it, you'll find it.

Linkarzu: Where is it? Is it here?

Sacha: I do not need to tell you how to use YouTube to search for things.

Linkarzu: Oh! Oh, man. Okay. Let me see.

Sacha: Now that it's possible to use Canvas inside Emacs to play things, people have been playing Doom in Emacs. I'm pretty sure someone could probably write a player to watch EmacsConf from within Emacs, which I think would be super cool.

Linkarzu: Oh, really? Okay, it's crazy. I think, well, people have been playing Doom on Neovim. Like, we won that one, I think. Okay, let me see. EmacsConf, so it has its own YouTube channel. So, okay. This is all the previous events, right? Interesting.

Sacha: Yeah, those are my notes and how it's run. It's surprising... Going back to Neovim... There was a NeovimConf and there hasn't been one, what's up with that? Come on, you know, you can do it again. Although actually I should probably be bugging Prime and TJ about that, maybe? Anyway, so our experience with EmacsConf is that it's totally possible to run a very fun online conference about a text editor for a shoestring budget and totally volunteer labor. Worth a try.

Linkarzu: Okay. When was the last NeovimConf? By the way, you're right.

Linkarzu: Last year, I think there was no, there was not a NeovimConf. I'm not exactly sure when the last one was. I don't know.

Sacha: Maybe it's because you lost bashbunni and then everyone gave up hope.

Linkarzu: Right? That is actually true. And who is invited for this EmacsConf, the next one?

Sacha: Everyone! We actually get a lot of people who are interested in other editors as well, and sometimes they present things too. I can probably squeeze an extra talk into the schedule if I really need, you know, if someone comes up with a really good one. But in the past, we've had talks about Guilemacs, remacs, which is a Rust port, things like that too.

9:20 Cross-pollination

Sacha: But of course most of it is Emacs and Org Mode. I have this afternoon of very interesting Org Mode talks and I want to attend all of them. As I mentioned, bashbunni is speaking there, but also Ihor Radchenko, the current maintainer of Org Mode has a talk on how he deals with an overwhelming task inbox and lots of stresses and how he makes sense of that in Org. And now that heisenbug is working on org.nvim, a lot of the workflow things might be easy to translate into your setup.

Linkarzu: Exactly. What do you think about that betrayal? I asked Prot, you know, because Heisenbug is betraying Emacs.

Sacha: No, no, I think it's wonderful. I think it's fantastic to have more people be able to take these interesting workflow ideas and experiment with them in the environment that they particularly like or are familiar with. So yeah, I mean, you tried Emacs, you gave it a a fair shake over several weeks. You're finding that your local maximum of enjoying how you've set up your Neovim shortcuts and your environment and all that stuff still works out better for you. That's fantastic. I'd love to see if there are any cool ideas that you want to steal from either the things that you've explored or from a conversation or anywhere else that you can translate into your environment. Then we can then go steal those ideas back with extra icing on top, which the Emacs community loves to do on a regular basis.

Linkarzu: Yeah, I see that a lot. Stuff porting over either from Emacs to Neovim or from Neovim to Emacs, you know? Like, yeah. I think it's cool, you know? I also agree to that, 100%. If Neovim becomes better, Emacs becomes better and the other way around, right?

Sacha: Yeah, absolutely. And you know it's entirely possible that once people get used to using org.nvim and they're like capturing new notes and tasks from their mail, because you have notmuch.nvim, and their feed reader, because you also have a feed reader inside nvim, and then they're like, oh you know I want to do this from my whatever it is and either you'll be able to vibe-code or actually write such a plugin, or you'll be like, you know, why don't I just use that other editor that already has five different implementations of this?

Linkarzu: Yeah, I think that is a good entry point into Emacs. The org.nvim plugin, it's going to help with friction. People that are in Neovim are going to start wondering, okay, what else is Emacs capable of, right? And they will probably finally do the switch.

12:01 Not Emacs vs Neovim; it's about what we can imagine

Sacha: And really, it's not so much an Emacs versus Neovim thing, right? It's more about what can we imagine? What can we try out? How can we build our tools to reduce the friction and make more things possible and more fun?

Linkarzu:

Yeah, 100%.

And I have a question for you.

Sacha: Yes.

12:20 What's the catch?

Linkarzu: I live in the third world, and we have a saying here, if it sounds too good to be true, it probably is not. Like, what's the catch with Emacs? Why do you do all this? Like, what do you gain out of all of this work that you put into Emacs? And why do you do it?

Sacha: It tickles my brain. It's just fun. Ever since I started, I've been fascinated by how I can both shape the tools to fit my quirks, fit the strange things that no software company is ever going to anticipate, and also, I've always been fascinated by how other people do this too.

13:05 Unix Power Tools

Sacha: I came from a third world too, right? I grew up in Manila. And as a 17 or 18 year old student, I was trying to read through all the computer science books in the very, very small university library. Well, it's a big university library for the Philippines, but the computer science section was only so big because it's hard to order books when you're far away. And one of those books was Unix Power Tools. They had a chapter on Emacs, of course, and one of the things in it was just this throwaway mention of, oh yeah, if you have plenty of time to waste, check out M-x doctor. And I was like, what? Back then I was, like, what kind of editor has this kind of stuff in it? As I've gotten to know people and their customizations and the things that they've built to support their lives, I've just become more and more fascinated by what people can do with it. So I do a lot of things for free for Emacs because it's a wonderful community.

14:02 What is Meta x?

Linkarzu: Okay. What is M-x, by the way?

Sacha: M-x is the totally old way of saying Alt X because apparently there were fancy keyboards where the Alt key was called Meta back then. And so M-x or Alt X is the way you call commands by name if you don't remember the keyboard shortcut or if they don't have a keyboard shortcut in the first place.

Linkarzu: Okay.

14:24 Searching handwritten sketches: Evernote to ripgrep

Linkarzu: In the video that played at the beginning when I was talking about what I know about you, one of your most popular videos is Evernote. Like, what's up with that? You know? I guess it started before Emacs, right?

Sacha: No, no, that was actually in between. So around the time that I was doing a lot of drawings, I wanted to figure out if there was a way that I could search through my drawings. Evernote at that time had a way to just dump all of your sketches into it. Then it would do the optical character recognition on handwriting, so I could theoretically search for text and see which sketches of mine had that text in it. I find that writing on a tablet or on paper scanned in is a great way to explore a thought non-linearly, because my mind likes to jump all over the place. I wanted to be able to search them. I couldn't figure out how to do the OCR of handwriting all the way back then, because this was, what, 2018 or something? Actually, older than that. Much, much older than that, I think. So I used Evernote for that. But then, of course, Evernote got worse, like many subscription services do. I haven't used it in ages. But now I can use either Google Cloud Vision to do the OCR of my handwriting to get the text out of it, or I can use speech recognition to just blergh all the text in my sketch and then have the plain text that I can just ripgrep through or search through.

Linkarzu: I'm interested in that. You're going to demo the speech-to-text thing that you set up, right? You have something... Oh yeah, I totally can. Okay.

16:03 Manila to Toronto

Linkarzu: Now, you mentioned that you grew up in Manila, right? Manila, where do you live right now in case that you want to share it? I'm not sure if that's private or...

Sacha: I don't know. I live in Toronto now. I came here for my master's and stuck around because of my husband who is coincidentally a Neovim user. Somehow we managed to get along. Yes, yes. So I'm here in Toronto and I have learned to put up with winter.

Linkarzu: Okay. And for how long have you been there in Toronto?

Sacha: I moved here in 2005. Actually, my main reason for staying here was the Toronto Public Library, which is amazing. And then of course, I met my husband afterwards.

Linkarzu: He's from Canada?

Sacha: Yes. He's from Canada.

Linkarzu: Okay.

16:50 Not about converting people, but about finding the tools that fit you best

Linkarzu: Now with all of this power and influence that you have, why haven't you turned him to the, to the Emacs side? Is it because Neovim is better?

Sacha: No, it's because it's not about that, right? It's about figuring out what kind of tool fits you really well. For us, for example, he picked up using Ledger from me. I like using the Ledger command line tool, also by John Wiegley, to manage my finances. That's something he uses as well, because it's plain text. But he can do that within Vim perfectly fine.

17:23 What do I do right now?

Linkarzu: Okay, okay. You went there for your masters. What do you do if you want to share with us? What do you do right now?

Sacha: I'm retiring today! I'm wrapping up my consulting contract. So over the past 14 years, I've been on this four-year experiment with semi-retirement. Sorry, five-year experiment with semi-retirement. It got interrupted by parenting, and so it just kept extending, in which the little bit of consulting that I was doing was mostly focused on coming up with web prototypes, doing some data analysis. The data analysis part, my proudest moment was figuring out this complicated common table expression in PostgreSQL so that you could do this recursive query and report by organizational chart. Fancy stuff. Anyway, so this and that, some JavaScript and HTML and whatever, to basically take whatever crazy ideas my client had and see what I could do to automate it or build it on top of this other person's system, the vendor's system, which was poorly documented but still had a REST API. Anyway, that sort of stuff.

18:38 Learning French

Sacha: And then for the rest of the time, just tinkering around with Emacs, writing things, learning French. It's not my main language. You can probably tell because of my terrible pronunciation, but that's okay. I'm working on it. And I'm learning that because my daughter is learning that in school. I figured it's good for her to have someone to talk to. So there are many things to keep me busy.

18:57 Sitting out the AI churn

Linkarzu: Oh, okay, okay. So you do consulting then, right?

Sacha: I did consulting. I am now experimenting with not doing any consulting. I'm going to sit out all the AI churn, you know, you all figure that out. Then I will check back in next year, a couple of years, when maybe never, and see if there's anything else I can help with. In the meantime, I can just hack on the things that I want to hack on.

Linkarzu: Okay. What are you going to do? YouTube? Emacs? What's the plan?

Sacha: Have fun? We like biking. We like going outside. I like writing and drawing. I can always find things to tinker with in Emacs. Coming up with ideas for things to do is never really a problem. It's more like... Trying to finish enough of those things so I can post them and make them something that other people might be able to learn from or build on, right?

Linkarzu: Yeah, yeah, okay. I had something for you. I had a question for you. I just... Hold on, let me think. Let me think. Oh, you were talking about something. Oh, but before we continue, Sacha, just...

20:10 Thanking YouTube members

Linkarzu: Let me thank my YouTube members. The CEOs are shown on the screen. @web2three, https://web2three.com, Ted, https://cpnllc.com, and also Gallo. These are the three CEOs. And I just want to thank the rest of the YouTube members, which are the ones that are shown here. So just appreciate each one of the members for supporting the channel. Okay, so back to this here. That's just my little announcement that I do there on every live stream.

Sacha: All right. So, what do you want to go into?

Linkarzu: Yeah. I want to take a look at what you were sharing a moment ago. The speech-to-text, and it happens in real time, right?

Sacha: All right.

21:00 Backstory of real-time speech-to-text transcript

Sacha: Like many things in Emacs, this came out of a bunch of small seemingly unrelated hacks. One was I was having this conversation with a French tutor and I was like, man, I am having a hard time making sure... Like, he would switch into lecture mode and I was trying to have more conversation mode so I could practice some more, right? So I think I've got this right. Hang on a second... Stats...

Linkarzu: You let me know when I switch to your screen.

Sacha: Okay. Feel free to share my screen.

Linkarzu: Okay. Let's see here. There we go.

Sacha: Anyway, so I had a large language model generate a Python server because sometimes I'm like, I just want a proof of concept for this. I don't necessarily know all the details of how to work with the Silero voice activity detection thing. Anyway, so make me a server that can listen to my audio devices in real time without messing up my actual microphone use if I'm on stream. Okay, so I have this Python server, and then I wanted to visualize it within Emacs. Okay, I got that visualizing inside Emacs. And then I wanted to say, all right, you know, why don't I have speech recognition listening on this thing so that if I say something, it can check it off. Like playing Bingo, you know, if I say it, then it gives me a note that I've actually said that word or phrase. And so it could show me a list of the words or phrases that I still want to say in conversation. And then as we were preparing for this conversation, I was like, you know what would be really cool is if I could have that speech recognition, which is running anyway, give me a transcript of the current conversation in a way that I could then clip if I wanted to, because sometimes I'll be doing a live stream and I'd be like, You know, that was a really cool demo and I should grab that so that I can just grab the screenshot or put it into a blog post or just get a text or extract a clip out of it, turn it into a video, right? And so now I have this thing where, hang on a second. If I'm somewhere else, for example, it's easy for me to get to.

23:15 Demo: real-time transcript and instant replay in Emacs

Sacha: I have a voice command for it. Prepare to fast forward. Which is of course a [Spaceballs] reference. It'll show me then this thing. And if we are... Let me load this real quick. And it will show me the video that we have, or at least the recording that I've got of it. That's on the right side here. This MPV is controlled by Emacs. And if I go here. Let's say this one.

Sacha: So here's your waveform for it. If I play it back, which is of course the Spaceball reference, it will show me then this thing. I can copy the text if I wanted to, or I can extract this into its own video.

24:03 Demo: Video editing witin Emacs

Sacha: Of course I do my editing within Emacs. This is what my video editing looks like within Emacs. I can just copy and paste the subtitle cues that I want. I tell it where I want the output to be. I tell it what audio that I want to use in case I've replaced it. Here, for example, I'm using the same audio as well as the video from a previous live stream recorded session. and then I can just reorder things, clip things, change the timestamps here. If I want to cut from there onwards, sample bits of it and so on, it's something I can do.

Linkarzu: Can you remove words as well or just entire sentences?

Sacha: One way to do that is to split at that point. So for example, if I want to remove definitely, let's load this one so we can see where I am. I can follow along here. So this is my livestream from yesterday. "My bottleneck is definitely thinking speed." So here's definitely, right? This is the start of "definitely thinking speed". If I split here, and I split at the end of "thinking speed", I can say let's skip this. And I think, assuming I haven't broken... "My bottleneck is thinking speed."

Linkarzu: Okay. Yeah. Just a little tail there, but I get it.

Sacha: Yeah. It's just a matter of choosing the right timestamp. "Thinking speed."

Linkarzu: So that is pretty interesting and based. So you do all of your videos in Emacs, edit all of them there.

Sacha: Yeah, pretty much. Well, it started because in 2020, I think, I wanted to make a presentation for EmacsConf. And I wanted to record my audio and then just add the visuals on top of it. But I don't like clicking the mouse because I'm on a Lenovo ThinkPad. The tiny little pointer is handy, but... if I use a separate mouse, it's annoying. Anyway. Clicking is annoying, especially since I'm so used to being able to automate everything with keyboard shortcuts. So I said, why don't I use Emacs for video editing and audio editing? So what I can do then is I can take my audio recording... Or actually, I can record from Emacs itself and then I can edit it to remove the oopses and the false starts and change all the things that I want to. Then I can add the images or videos that I want for each clip and it will automatically speed up or slow down the video to fit the duration of the audio. So if I'm saying, you know, this is a quick preview of the conference schedule, et cetera, then it speeds up the scrolling automatically so I don't have to worry about doing it fast enough if I want to. I can also tell it to play this original speed. That has just grown since then. Every time I want to do something else... Like now I'm thinking, you know what would be really cool is if I could add a title card very easily, right? So let me go to, let me start a new thing here. WebVTT. So if I want to say, I want to add a title card that says "Hello world", right? Oh, I need to actually save it. Let's save it as, hang on a sec. Breathe, Sacha. It's okay. test.vtt. Yeah, that one. Okay. All right. So now I have a test.

27:51 Demo: generating video title cards from WebVTT in Emacs

Sacha: If I say Hello World, then it just calls ImageMagick to create this file here. If I open that file, it's super simple.

Sacha: It's just white text and a black background using my custom font, because I went to the trouble of figuring out how to make a font with my handwriting and then kern it using Org Mode. Because why not?

Linkarzu: Okay.

Sacha: That's ready. Then I can pop that in and I can say, you know, this is a test here. Let’s do a subed-record here. "This is a test here." And then that audio here, it becomes a whole thing. If I compile this, I think it will just make a thing. Let's put it into #+OUTPUT: test.webm, sure. All right. mpv test.webm "This is a test here."

Linkarzu: I see. Pretty cool. Have you seen...

29:06 fframes, generative AI

Sacha: If I can figure out how to get fframes, that thing that you're using... If I can figure out how to get that working, that might be interesting too. Although, I have to say, I'm very attached to my stick figures and the way that I like to draw things. And I have tried using generative models to say, "Okay, here's my sketch. Can you animate this SVG, move things around or whatever." It keeps trying to rewrite things to plain text. I'm like, no, I want my actual paths. So I have to fiddle with it some more. In the meantime, however, I can animate things myself, thank you very much. Like, for example, this... animate... let's go with that one.

29:49 Demo: Stepping through SVGs in Emacs

Sacha: "Some things that work really well." This is within Emacs again. I can just highlight the different things.

29:56 I draw on an iPad with Noteful

Linkarzu: How do you do your drawings, by the way? Like, do you have like a tablet or something?

Sacha: Oh yeah, yeah. I use Noteful on an iPad. I used to draw using Krita on a Lenovo X230 tablet PC, but at the moment I can just use the iPad with Noteful. Currently I'm drawing in dark mode because you have a dark mode channel, so I have things like my sketches.

30:20 Light themes and dark themes

Linkarzu: Emacs users like to flashbang people, right? They like the white? Is it to tell apart from the Neovim community? What's up with the white themes?

Sacha: I mean, I tend to use dark mode now most of the time too, because I figure most people will be watching my stream when late at night they're just relaxing or whatever. But I guess different people work with different setups. I do like the way that with modus-themes and all the other themes in Emacs, it's super easy to pick one of these dark themes and just go with it.

Linkarzu: Okay.

30:58 Art and stick figures

Linkarzu: So you do it on the iPad then. I have to convince my wife that we need an iPad for the family. I don't know how to draw. I'm pretty bad.

Sacha: I don't really know how to draw either, but somehow people have paid me to do so. I don't know what's going on there. But yeah, I'm really only drawing stick figures. It's fine.

Linkarzu: Okay. Yeah, no, my drawing is like, you have no idea. I lack creativity when it comes to that. My wife paints. She paints pretty good stuff. My daughter paints. Well, these are my daughter's paintings, the ones that are back here. I guess you cannot see them. You can see them there in the background. She's learning, you know, but me... Nice!

Sacha: I see very vivid colors.

Linkarzu: Yeah, she loves rainbows and a lot of vivid colors, but I can't. I'm pretty bad at it. Now, how do you do this speech-recognition thing because I do something similar.

31:58 Linkarzu's video editing workflow

Linkarzu: Let me tell you a bit about what I do with my video workflow. I got tired of editing videos. I'm done. Like, it is a time consuming process coming up with clips. You've been there, right? You have been doing that for quite a long time, way longer than me, right? I just got tired and I was like, I don't want to do this anymore. Never, ever, ever again. I need to come up with a method that allows me to create clips out of a live stream. All of it, AI. AI did all of it for me. It hasn't been easy. It's been months. I've been stuck for months. But I don't do stuff real time the way that you're doing right now. The transcription happens when we're done with the call and the process starts automatically and a few hours after I have the clips in my dashboard that I can upload if I want, right? But it's not real time. I saw how you did it on your side and it's pretty accurate. Like, what's the magic? What are you doing there? You're sending it somewhere, right?

33:05 Local CPU-only speech recognition in Emacs

Sacha: No, no, this is an entirely local model and I'm running it in a computer with hardly any GPU. So I'm actually just making it use CPU only for the speech recognition because I have a Lenovo P52 from 2018, I think. So it doesn't do this GPU thing very well. I think you're usually on a Mac, so you're spoiled for choices there. But speech recognition has gotten really good over the last few years. And I'm using Orukeet at the moment. It's a multilingual model, so it can handle my poor French pronunciations just as fine as my English ones. I can press my keyboard shortcut. For example, I can say, "This is a test during a chat with Linkarzu." Then, because I've modified my dictionary, your channel name actually shows up properly. "We are talking about speech-to-text, dictation, all sorts of other things like that." Where's my phone? It's pretty accurate.

Linkarzu: It's extremely accurate. What's the name you said? Because I use Wispr Flow, a local model as well. I do the transcript locally on my Mac. Wispr Flow is what the AI decided to use. And I'm like, oh, it gets it. But not...

Sacha: Yeah. The model I'm currently using is called Orukeet. I think it's based on Parakeet, but it's been tweaked for more performance and less memory. But there are so many new models coming out. It's really quite interesting because every day or every other day, there's like, oh, try this new model. I'm not good enough to keep on top of all those changes. If I can manage to get the AI to generate me a server that has an OpenAI interface, I can plop it right into my Emacs setup and it will just work. So I'm happy with that. This is fast enough that I can use it to think. Then, when I have the text, I can rearrange it however I'd like. For example, "prepare to fast forward." We're here.

35:15 Sharing speech commands

Linkarzu: I have a similar command. Let me see if it works. Hold on. You see my terminal right now, right? Yes. I don't know if you can see my screen. Let me see if it works. Hold on. Virgin mode off.

Sacha: Yeah, yeah, yeah. I saw that.

Linkarzu: It didn't work. It changes my wallpaper and it changes my...

Sacha: I have one too. Laser. Look. I changed my cursor to a laser so I can say, here's my mouse cursor, right?

Linkarzu: Okay, pretty cool.

Sacha: Yeah. So the nice thing about it... Oh, it's still listening. Let me just turn off laser mode here. Laser. Laser. Laser.

Linkarzu: It happens to me as well.

Sacha: Edit retry. Laser. Okay, there you go.

36:14 Speech commands and more shortcuts

Sacha: The nice thing about speech commands is that it opens up a whole lot of other ways to run commands without necessarily having to memorize keyboard shortcuts.

36:23 Having fun with speech commands

Sacha: You can have more fun with it too. So for example, now I have this command. It turns out I cannot say "start streaming" reliably. Sometimes I say "start screaming." I know sometimes I accidentally say that, and sometimes that's what the speech recognition hears. So instead my command for starting to stream (because of course Emacs controls my OBS through websockets) is "let's go live". My command for stopping the stream is "over and out", just because it's a little more fun to say. It becomes easier for me to remember what I need to say in order to make this happen.

Linkarzu: Yeah, yeah.

37:01 Dictionaries for correcting speech recognition

Linkarzu: Now, why is it accurate? And how do you do, you have a dictionary of the difficult words? Like if I say Neovim, it doesn't get it. It says Neovim, or it just puts whatever it wants, whenever it wants. Sometimes it puts something random out there. What do you do for yours?

Sacha: Neovim is okay, I guess. Let's see if it does a thing. Yeah, it got that without my needing to correct things. Let's make a harder word. Anti-disestablishmentarianism. Close enough. Okay, you know, that requires very little editing. What is a difficult word? Oh, actually, let's make a different name. Sometimes it gets Prot's name wrong. Prot does a lot of videos on Emacs. Oh no, it got him too.

Linkarzu: Yeah, yeah, yeah.

Sacha: If there was a thing that is difficult to say... heisenbug is making org.nvim. That one. Okay, here we go. heisenbug is making org.nvim. I mean, it's getting him, so...

Linkarzu: Okay, yeah, yeah, yeah. I get it. So, it's a local model. Interesting.

38:19 Demo: Adding a misrecognized term to my common edits dictionary

Linkarzu: Do you feed it a dictionary at some point?

Sacha: It is a local model. If I do need to change things... Let's say for example, okay, "Orgzly Revived". It probably can't get that one. "I use Orgzly Revived on my phone to check my tasks." Oh yeah, so here, right? It says "Orgsley Revived." What is that even?

Sacha: But I can press C-; and it uses substitute. "Orgzly Revived" here. What that does, in addition to the substitutions that happen throughout the buffer, so for example, if I'm adding a transcript, it will change that all throughout the transcript. I've also added some code (because this is Emacs, I can just do that) that saves this in common errors or commonly misrecognized words. And then when I recognize text, whether it's before a voice command or if I'm just doing this or whatever, it will apply all of those common fixes, common edits. Here we go.

Sacha: So it automatically adds it to this thing here which gets saved automatically for me. And that's the change that I've just added.

Linkarzu: Interesting. Pretty cool.

Sacha: It's really nice to have that kind of [dictionary] shortcut built into the way that I edit things. All I know is I just hit C-; and put in what it's supposed to be. Then it gets not only fixed in my current file, but in the future as well.

Linkarzu: Yeah, I need to work on my transcript game. Local models?

Sacha: Oh, yeah, it's so cool.

39:57 Turning video transcripts into searchable blog posts

Sacha: One of the reasons why I love transcripts is that it's so much easier to search, right? Whenever I do an interview or whatever, the fun part for me is actually going over the transcript and turning it into something that I can use. Let me show you proj/yay-emacs/index.org. So these are, for example, my recent chats. In order to include the transcript in my blog post about this, all I need to say is captions, and I give it the link to the transcript. And that turns into... Hang on a second. Let me... I should have a C-. b here. Was it this one? Okay, so that turns into this kind of blog post. Right? You have the embedded video. You have the chapters. Clicking on the chapter link will advance to that.

Sacha: And then you have the whole transcript right here. with screenshots. So then people who don't want to listen through an entire hour-long video can just jump to the interesting parts themselves. I think these ones also go back to the video up there, which someday I'm going to figure out how to make a nice sticky display for. Clearly I need to fix that because it's not actually on that thing over there. Theoretically, if I'm publishing it right, this time I think I've been trying to host the videos on the Internet Archive so people you have to watch on YouTube if they don't want to. But yes, so the idea there is the video gives you so much text that you can then share.

Linkarzu: Yeah. Or edit a video way faster. Before I came up with this automated thing for creating my clips, I used to do that in DaVinci, you know, because DaVinci has like a transcript feature and you can... but I'd just rather not touch it at all.

42:07 Demo: Saving and cropping screenshots from a video at a timestamp

Sacha: Screenshots are super easy for me to do because Emacs, of course. So like, for example, if I wanted here, If I wanted to take a different screenshot here, I can say save screenshot. And then it takes the screenshot and it does that thing. If I wanted to crop it, I can say crop to this and crop to that.

Linkarzu: Oh, okay.

Sacha: Actually I can say, just crop the screenshot. If I say screenshot crop, it will crop the screenshot. If I just say crop, it will crop the whole video to that section.

Linkarzu: Oh, I see. I see what you're saying. That specific segment only, right?

Sacha: Yeah. So text as a medium for video editing, it's actually really powerful.

Linkarzu: Yeah, exactly. Yep, 100% agree. What other tricks do you want to show us there? What other things do you want to brag about your Emacs workflow?

Sacha: It's really hard to say. I told you how doctor was the beginning of my of my experience. Yes, yes.

43:22 Demo: M-x doctor with speech in and out

Sacha: So this is a doctor. You can say things like, I'm feeling happy today, as I said, right? And then it uses that to generate its response. But I have this conversation mode. Yes, especially when I get to tinker with Emacs. And then... What happened when you get to tinker with Emacs? Does the TTS come through? Yeah, it does. The reason I did this was because after I showed off my vocal commands to Emacs Paris, they were like, oh, you know, what if you can have a conversation? So I was like, okay, let's come back full circle to the thing that got me curious about Emacs in the first place and voice enable that. And then, of course, this is a very old AI.

44:09 Demo: speech-enabled conversation with a large language model in French

Sacha: It's much more interesting if you apply it to the new models. So if I want to, for example, practice French. This is one of my voice commands here.

Computer: "I would appreciate it if you would continue." Okay, here we are. Then I might say, "Je parle avec Linkarzu." And then I think, there you go. It will eventually, maybe? C'est toujours enrichissant de partager, toucher ses passions en direct. Quels sujets abordez-vous ensemble aujourd'hui ?

Sacha: All right. So this now uses a large language model. This one uses Gemini because gptel makes it super easy to plug in different models. So, if I wanted to practice French but I don't necessarily want to bug people because I take a while to think about my words and sometimes I'm looking stuff up, then at least I can simulate that kind of conversation. There are gazillion apps that will sell you a subscription to do this. But because it's here and it's plain text and I can control it, then I can more easily go through it afterwards and analyze the vocabulary or correct the things that it didn't get right, which I know is because of the speech recognition and not because of me or whatever. So it's so much fun to be able to tinker with Emacs to do what I wanted to do.

Linkarzu: Yeah, pretty powerful.

45:46 Sacha's Linux setup: XFCE, X11 and Emacs on top

Linkarzu: I have a question about your operating system. What did you go with? I see this is Linux. I would assume it's Linux, right? Of course, it must be Linux.

Sacha: This is Linux. I used to be in Kubuntu because I liked KDE, but when I recently upgraded to the latest version of Ubuntu, then I broke everything. I was like, okay, this Wayland stuff is getting in the way of the automation that I like doing. So I'm back to X11. I was like, hey, let's try something a little more lightweight. This is the XFCE Window Manager at the moment. I'm still settling into it. There are lots of little things that I'm learning how to configure, but yeah, just Linux.

Linkarzu: Okay, Linux, Kubuntu. Why did you decide to go with that distro? Is there a specific reason or no?

Sacha: No, it's more like, well, my husband happened to have an install USB lying around. I used to be on Debian unstable, and then I switched to Ubuntu. It's just one of those things that I haven't bothered enough about to change, on account of changing requires me to go reinstall a lot of things and then get my Emacs working the way that I want it to do again.

Sacha: At the moment, Linux is the library that Emacs uses to talk to my hardware.

Linkarzu: Yeah, it's just the base, right? You just want something where you can run Emacs on, right?

Sacha: Yes.

47:18 Automating other apps with Emacs; X11 versus Wayland for automation

Sacha: I want something where I can let Emacs control as much of my computer as possible. So for example, when I set up the BigBlueButton web conference rooms for EmacsConf, I do that in Firefox because I can have Emacs control Firefox so that it can click through the different screens and set all the moderator access codes or whatever else and confirm the settings. I don't have to do that kind of clicking and typing myself.

Linkarzu: Okay. And you mentioned that you switched back to X11 because Wayland was getting in the way. Can you share a little bit more about that? I'm not a Linux user. I'm a Mac OS user. But I know about the words that you're mentioning because all of the guests that I bring over talk about it and I'm like, okay, so they're like, okay, got it. So what happened there?

Sacha: I think it's just a different security model, right? So for Wayland, which is one of the like the window system compositors(?), how stuff shows up on your screen. The way that it's conceptualized is every application is sandboxed, so it shouldn't be able to mess around with other applications' windows, which is more secure. Great. But I actually do want my Emacs to mess around with other people's windows, and I want things to be...

Linkarzu: Emacs is the king, right? Emacs has to be able to do anything it wants, right?

Sacha: Yeah, yeah. And I want that to happen without a gazillion prompts. "Are you sure you want to let..." Yes, I want it to do the typing so that I don't have to do the typing. So yeah, it's pretty good. Maybe someday X11 will totally shut down and then I'll have to move. But I can give people a few more years or whatever to figure out the automation and accessibility parts that I would need in order to do that kind of automation.

Linkarzu: Okay, okay. So you're in Kubuntu, you're on X11.

49:15 Just a regular laptop keyboard

Linkarzu: Then I also wanted to ask you, do you use like one of these special keyboards that all the cool kids use or are you just a normal keyboard?

Sacha: I'm just on my laptop. Yeah. I'm going to tilt the screen down and mess things up. See, that's it. That's the thing.

Linkarzu: The laptop keyboard. Has it ever caused any issues for you? Like hand pain, wrist pain or something like that?

Sacha: No, the only wrist pain I got was from lifting my daughter the wrong way, which gave me the de Quervain's tenosynovitis. Do not pick up your kids without paying attention to how you do it.

Linkarzu: Because you hold them like this, right? That happened to my wife as well.

Sacha: Yeah, yeah, yeah.

49:56 Using Emacspeak to deal with laptop screen failure

Sacha: But I've been interested in accessibility for a while. Also partially because of... So, okay, so here's what happened. In about third or fourth year of university, I was also on a laptop, and my screen stopped working occasionally. It would glitch out, and I could not see. I mean, it would be super low contrast, and you could see things if you look at it from the right angle, but it would just glitch out like that. I could plug in an external monitor, sure, but I can't plug in an external monitor in the middle of class. I'm not going to lug a monitor around, right? And while I did experiment with a head-mounted display as part of my curiosity into wearable computing, that is also fairly obvious and large and awkward. You know that smart glasses video that you had? Okay, now they can pass off as glasses, right? But back then it was a huge Borg-like thing. But fortunately, Emacs has Emacspeak. So I was using speech synthesis to code and to take notes and do all those other things, which was fantastic. It actually worked. It worked so well that I was like, you know what? I could use this to listen to manuals and write notes and look up things while I'm walking around because all I need is a portable keyboard. They make one-handed keyboards. And a pair of earphones, and nobody can tell that I'm actually reading, well, having read to me some kind of... This is me going through the Emacs manual while walking around, right? Anyway, so, accessibility. The text-to-speech part is very interesting and there are a lot of people who are using Emacs even if they're blind or visually-impaired. all this stuff is actually surprisingly useful also for people who aren't.

51:45 Anticipating physical and cognitive challenges

Sacha: The speech recognition stuff I think will be very helpful in case something happens to my hands. People have accidents or people get sick. My mom has Parkinson's, so her tremors make it really hard for her to type or tap things. It's amazing that we can keep modifying the tools to make this kind of speech input, voice commands a lot easier. There's also physical decline and there's cognitive decline. I've had to deal with brain fog as part of the sleep deprivation of early parenting. So I know my ability to memorize things and my ability to type while I'm talking is nowhere near what I would have in an ideal world. It's great to be able to modify my computing environment to adapt to these changes and to the changes that I anticipate.

52:37 Describing Emacspeak

Linkarzu: Oh, and you mentioned Emacspeak. So what is it then? It's just accessibility option in Emacs that reads your screen or something?

Sacha: It can read a whole thing. It can read character by character to give you audio feedback. You can go by word or by sentence as you're navigating around the text. I don't have it set up in this one, but I think I have a different profile where I have it set up, because by default, when you launch it, it reads all of Emacs to you. It doesn't just say the text. It will also give you auditory icons. So for example, if something is bold, you can have it say it in a different voice. If something is italicized, you can have it say it in a higher pitch or something else. If there are icons, it can play sounds instead of those icons. So it gives people who are blind this much richer experience. I love the fact that Emacs has these things with all these different kinds of needs. I've used it. It's great. I found that when I was using it, I could listen to things at 300 words a minute or even higher, and I would still understand.

53:51 Linkarzu adjusts his electric sitting/standing desk

Linkarzu: I'm sorry. It's just my desk going down because I try to...

Sacha: I thought you were like genuflecting in front of Emacs is awesome.

Linkarzu: Yeah, I just try to, you know, adopt different positions throughout the day. There's a question. Oh yeah, for sure. You do it as well?

54:13 Parenting and fragmented time

Linkarzu: How long do you spend sitting? Like, do you spend sitting most of the day?

Sacha: Most of the time, actually, I have to go help out the kiddo, right? So that keeps me away from the computer, which is one of the reasons why I've had to learn how to deal with very fragmented time. Not much time sitting in front of the computer to focus on something. Everything that I want to do has to be something that I can do in 5, 10, 15 minutes, maybe 30 minutes. At the moment, she's fairly independent, but I can still be interrupted by somebody who needs breakfast or somebody who needs a hug and whatever. So I need to be able to capture a thought, get it out of the way and work on things in tiny chunks.

Linkarzu: I've seen my wife, how she handles things and I'm like, man... It's a lot of mental overhead. That's a whole other conversation. Men are the ones that make progress, build their professional careers, and wives usually take care of the kids. It's a huge sacrifice. What do you think? How do you feel about all that?

Sacha: I signed up for it totally knowing what I was getting into. I was like, okay, there's a lot involved in being the default parent, right? The primary person who patches up [owies]... But I think partly because of Org Mode and Emacs, it's been very helpful to me to be able to say, "Yeah, that's a great idea. I'm going to write that down in my phone or on my computer. Usually on my phone back in early parenting days, because I'm away from my computer, I'm at the playground or whatever else, right?

Sacha: So the fact that I can capture a note into Org Mode and then know that I can get back to it in several years when I have more free time or that Org Mode can keep track of the deadlines that might be a year from now, like when I need to renew my passport and just have that surface the reminder at the right time with the notes on exactly what I need to do and the links to wherever I need to go. I think that has been very, very helpful for me.

56:20 Capturing tasks from the phone with Orgzly Revived

Linkarzu: Good point that you brought up because I don't know quite a few days ago I just came up well the clanker came up with a method we could say of me just tapping it saying something to it and when I come to my computer the task is there in Neovim? Yes. Right? Yes. Because I forget I'm outside I'm like okay I have to remember this I have to I'm not going to remember it it's just going to go away so I do it on the phone shows up in Neovim and it's a huge benefit. How do you do it?

Sacha: For my phone, I often just put it into Orgzly Revived, sometimes with dictation, sometimes just typing in a few keywords to help me remember. A lot of times it's, you know, if I'm coming across Orgzly Revived.

Linkarzu: What is it?

Sacha: O-G-R-Z-L-Y.

Linkarzu: If you want to show it, I don't know.

Sacha: It's on my phone. Is it like an app?

Linkarzu: Yeah.

Sacha: So I use an Android phone. And now there are actually a gazillion apps that talk Org Mode and can synchronize with your files and whatever. I'm currently still just using Orgly Revived as an app on my phone with Syncthing. Syncthing being the free synchronization that I can use to just get my files back and forth. But there are lots of other alternatives, so you can find something that fits you well. I am very tempted to figure out, finally, how to use Emacs native, because there's an Emacs board for Android. Especially if I can get my speech synthesis and speech recognition working on it, I think that would be amazing to have this kind of conversation with Emacs along the way. And then on the computer, if I need to capture something quickly, ooh, I can show you this one. Let's see. Remind me to put together a quick description of my to-do workflow. And it will take that note and it will stick it into an inbox. Here I'm in live mode so my public tasks don't get mixed in with my private tasks. If I do an agenda it should just be limited to the public stuff. Anyway, so the Remind Me created the note for me. It includes the audio in case the speech recognition didn't get anything right. And it includes a screenshot so that in case I'm doing this from a different application because my keyboard shortcut is global, I can still see the context and go find that sort of stuff.

Linkarzu: Quite interesting, quite advanced, quite complex. It must have taken you months, years to set all of this up.

Sacha: As I said, I can only work in like 30 minutes or so. So this one, I think was a 10, 15 minute hack. A little bits of time. This link here to whatever I was looking at, you got that free from Org Mode. This thing here with the recording, I got that because I already wanted to save my recordings anyway. So it was just a matter of adding a link to the file name that I already had saved. This screenshot, you know, another five minutes because I already had Spectacle capturing the screenshot of both screens. So it's fairly simple. It will even work for things like, remind me next month to follow up with a linker to see whether he's switched to Emacs.

Linkarzu: I mean your entire Emacs config. Has it taken you years to adapt it?

Sacha: It just keeps growing, right? I have an idea. It takes me 5, 15, 10 minutes to put it in and then it just accretes. I can't make very big changes because If I try to work on something big and then I get interrupted, the old chunking effect makes me very grumpy. I have an unfinished task and it's like nagging at me. So it has to be always small chunks, but Emacs makes it super easy to work in those tiny, tiny chunks. So this one here, for example, it says, remind me next month, et cetera, et cetera. And it has scheduled it for next month.

Linkarzu: That's pretty cool. That's pretty cool.

Sacha: I'm not actually going to pressure you to switch to Emacs. You can keep using Neovim and just borrow all the interesting ideas.

Linkarzu: Org that NVim is there. I can adapt it to do this, you know. There's a question in chat. I ignore chat unless they bring the coin, okay? But there is one question that I will allow this peasant in. in our conversation. frazzor749 is asking, we were talking about window managers. What about EXWM when we were talking about Wayland and all that stuff?

Sacha: There are window managers written in Emacs Lisp and people who use EXWM really like it. There's actually even an EWM as well right now, I think. I remember playing around with it a couple of times. Maybe I should check it out again. The first time that I played around with it, my laptop was even older than this one and not as capable. So maybe now that I am on a 2018 laptop, it might work better for me. Because it is nice to be able to... It would be great to be able to just press C-x B and switch to another application just like I switched to other buffers.

Linkarzu: Yep, yep, yep, yep. And moving on to other topics.

1:01:55 Sacha Chua on AI and the Emacs community

Linkarzu: How do you feel about all of this new world that we're in, AI-related stuff? I've seen that it's evolving quite fast and software is changing. The way that we look at software is changing. It used to be something that only a small set of people could do in the past. Now, people like me or anyone else, even frazzor749, can buy solutions and have them up in minutes. Does that make you feel something? Does that make you feel sad, happy? How do you feel about all this?

Sacha: I love seeing the comments from people who were like, you know, I had a hard time getting started with Emacs before, but now I can ask an LLM to generate me something or explain to me, explain something to me and I can get it working. So that's great. But I also like the fact that the people who do not want any of this stuff to happen to their particular Emacs can get together and find each other and say, you know what, if Emacs adopts AI more than I'm comfortable with, I commit to figuring things out the human way and continue to build it without that. So I love the fact that there are choices and people can make a choice that fits them.

Linkarzu: Okay.

Sacha: It's very exciting to see the ideas that people come up with.

Linkarzu: Okay. And you also have the choice?

Sacha: Yeah. Sometimes it's hard to read the code because it's super long and like, you have that example from someone on your chat, right? And it's like, okay, you can generate a 3000 line module, but really you might only need 200 and that 200 is a lot easier to read. Maybe it was 300. Okay. I'm, you know, touching it right.

Linkarzu: No, he said 3000. He said 3000.

Sacha: No, no, no. That's like his final for going from 3000 to something like 200 to 300 lines. Because if you know what else is out there and how you can hook into it, then it doesn't have to build everything from scratch.

Linkarzu: And we also have Prot as an option because he does his coaching sessions. You can learn about Emacs with Prot. We're going to put his link somewhere in here. I always leave the link in all of my video descriptions and all that stuff. How do you feel about AI? What do you think is going to happen in the future? Have you ever thought about it? How do you see software?

Sacha: I have no idea what's going to happen in the near future. I know there's a lot of froth and a lot of like weird pressure from other people to use it or not use it or whatever. And I think the business world has sort of tied itself in knots. We're just going to have to see how all of that stuff works out. In terms of using it myself, I use a very limited set of functionalities. Just the things that I can understand, again, 5 to 15, 30 minutes at a time. I am not at the point where I can just trust the agent to run by itself and, you know, come back. tomorrow with results. I'm more like, okay, I'm trying to learn French. I don't need anything fancy. I just need to know how to make my paragraph less grammatically terrible. And the nice thing about large language models is that it tries to bring it towards that average, right? And it can explain things or at least there are a number of times that even with my beginner level, I can say, you know, that doesn't seem right. And then I can go and dig up the actual explanation and compare it against human examples and ask my tutor whom I meet twice a week and pay actual money to. But the fact that I can do this at 11 p.m. or whenever I'm free is helpful when it comes to getting that kind of instant feedback. And I use it for troubleshooting sometimes because I'm like, I don't know what this error message is. And doing the exact search is not going to get me the right answer. But how would I start to understand this? What questions would I ask? So, okay, that's sort of helpful there. And for proofs of concept where, you know, I do not know enough about FFmpeg or Matplotlib or Python's internals to do some of the things that I want to do off the top of my head. So I'm like, okay, I will see. If I tried myself and I'm not getting anywhere, then I can say, okay, generate me a thing. And then I can try to see, okay, how is it doing that? Why is it doing that? And build on that. I like to keep things within one or two screens that I can actually read.

Linkarzu: Okay, okay, okay. Yep, I started like that as well. I didn't trust it too much at the beginning, but it's been progressing and I think you just get more dependent on it, you know, and more and more and more and, you know, but it's gotten better. Do you use a specific model?

Sacha: I use Gemini when I feel like it. The usage levels are quite high in the free tier. Sometimes I'll use Claude as well. My daughter has a subscription to Claude. We pay for a subscription to Claude for my daughter because she likes generating interactive stories to help her learn French vocabulary.

Linkarzu: Okay, okay.

Sacha: Which is great because then it can phrase everything in Pokémon terms. So that's easier for her to pay attention to. And so when she's asleep or when she's watching Pokémon, then I can use it without stepping on her budget. Stepping on her usage, right?

1:08:03 Kids' obsessions: Harry Potter, Pokemon, Wings of Fire

Linkarzu: Is she into Harry Potter, your daughter, or not at all?

Sacha: Only briefly. Pokemon remains her current main interest. She is the sort of person who reads the entire wiki and stuffs all of the factoids into her brain.

Linkarzu: Oh, my daughter is in her Harry Potter face right now. My wife bought all the books. I don't know, it's seven books, I think. Right? And the condition is, once you read a book, we can watch the movie, right? She's written like four, I think, and they're huge books and I'm like, man, that's tough. But she's in that phase right now.

Sacha: Yeah. The novel series that my daughter is currently looping over is Wings of Fire. She's been into it before. So now we've checked out all the books from the library. I love the library. It saves me so much money. And so she's reading that. There are graphic novels as well. So it's great because then, you know, it makes it like graphic novels for the first seven or so books. And I've also checked out the graphic novels in French. I get to read them and learn things. And she's reading it. And because we're so familiar with the story, I like to learn about the things that my daughter is interested in. So for example, when she was into Rubik's Cubes, I learned how to cube too. And I played around with using Org Mode to help me learn cubing. And she's into Minecraft. We play Minecraft together. And now she's into Wings of Fire and we read that together too.

Linkarzu: Okay. Okay. Now you mentioned that you use Claude sometimes. How do you feel about it? Have you tried the latest Opus 5.5 one? And if you compare it to other models, do you feel a difference? Do you feel that it's like really smart or it's like, nah, what do you think?

Sacha: Well, let me give an example of something I was playing around with recently. So I mentioned that I use Noteful on my iPad to sketch. One of the things that I've always been curious about is what can I do with the stroke data since it's recorded it somewhere. I came across another person's repository where they had used a large language model, probably Claude even, to reverse engineer the format in order to create something where you give it your notebook you know your handwritten notebook and it will generate quizzes and summaries and etc etc and then put that back in the notebook so it looks handwritten so that you can do the quiz on the iPad with a pencil and all that and the repository had a description of the reverse engineered format so on my phone I said hey you know can you take a look at this repository and see if you can use the reverse engineered format in order to take the notebook and create an SVG using centerline strokes instead of fills. The way that the export usually works is you export a PDF, but when you get it into an SVG editor, it's all like paths with fills in them. But I want strokes so that if I want to animate it, I can animate it in the direction I was drawing. instead of the character just appearing. And it did that and I gave it some files and it actually showed me also some videos of it animating so that I could visually verify that it was doing what I wanted it to do. So theoretically, there are some Python scripts that I might try out later on. I like the fact that I can do that sort of thing from my phone to try things out. At the same time, also, it's fine for the things that I don't know much about. But for Emacs, it's like Pod said, this is the fun part. For him, it's like it's his video game, right? So for the stuff that I like to hack... I want to actually go do the digging around and come across the things that I wouldn't have even thought to ask for.

Linkarzu: And do you feel like Claude is smarter than other models? Or you don't feel that too much of a difference?

Sacha: I did more of a comparison back some time ago when we were deciding whether to go with a Gemini subscription or a Claude subscription from my daughter as an incentive for her keeping her grades up and doing stuff. We trust her to manage it reasonably well. We've had these conversations about AI usage and she's very proud of the fact that she doesn't use it for doing her homework even though apparently in grade five some of her classmates are already getting reminded by their teacher not to do that, right? Anyway, so we generated some samples of creative writing based on the prompts that she had and we did a blind comparison and she like clawed more. So that was her reason for doing that. For me, in terms of the small generation tasks that I trust the AI with or I ask the large language model to do, there hasn't been that much of a difference. I'm sure people doing fancy agentic workflows will have different experiences.

Linkarzu: Yeah, I've noticed how it, how smart it got and that's the reason why I was asking and it makes me excited but it makes me kind of worried as well at the same time. I don't want to be pessimistic but you know, I see how good it got in the past few months and it makes me think How better is it going to get? Like, what am I going to be needed for then, like, in a couple of months, a couple of years, you know? So, I don't know. I'm in that phase right now. And it's like, okay, it's exciting because I can do way more stuff. But, you know, what's going to be the point then, you know, in a couple of years, you know? So, I don't know. It's just me, baby, you know, thinking about it.

Sacha: There are a lot of people dealing with uncertainty and existential crises and I have no idea what that future is going to look like. Although to be fair, it's a kind of, you know, people in other industries that people in IT have kind of automated away or We've had to deal with that kind of existential crisis before. So it's our turn now, I guess. I'm semi-retired and professionally relevant, so I can step out here and just wait for the dust to settle, right?

Linkarzu: Yeah, you have it figured out already, I guess. Like the professor, he's 80, he's retired already. Like he can just go to Hawaii, drink his piña coladas and just enjoy life, you know. But, you know, we're still working and still, you know, trying to figure things out. Yeah, I don't know.

1:14:46 AI-generated code, slop PRs and the Lisp Curse in Emacs

Sacha: What's important to me is to help us figure these things out together. For example, I'm focused on the Emacs community and there are big debates about should we allow it? How should we help make sure that package maintainers aren't overloaded? They're not overwhelmed with a lot of Slop PR requests. It's great to have all these announcements of new packages, but if it's just entirely generated, then it tends to fall off and not get maintained. In the Emacs community, because it's so easy to build something for yourself, we've always had this challenge of making something that other people can use anyway. So there's an essay with the title, I think, The Lisk Curse, or if you search for those keywords, The Lisk Curse, you'll find it. It talks about the fact that because it's so powerful, it's hard for people to come together and decide on something. And with large language models and the ease of generating code, that's basically the same problem scaled up. Which is something that we're used to in the sense that many times something that's tailored to you, that's customized to fit you, it works really well for you, but it's hard to translate to somebody else. Just like if you're prompting a large language model to create an app for you, It might not necessarily be something that somebody else can just pick up and run with. And it might not necessarily be something that you're going to use for six months or a year. It might just be something that you use today and it gets your problem solved today and that's okay. For me, the fact that people are exchanging these ideas and they're asking what ifs and they can actually get to the point where there's code to help them test those what ifs and help them refine their ideas. That part is exciting and I'm curious to see what people do with it. And at the same time, the people who want to stay with the code that they can read and understand and you know when they read the code of other people even. If they read the code of other people, which is something I love doing, you get the sense of what other people are thinking about things. The kinds of needs that shape this code to be what it is. The little choices that they make in their variable names or the way that things fit together. I think that's also a wonderful thing that I don't want to lose if It's just generated really, really long libraries that are not doing things as beautifully as they could be. I'm glad that there are people who try things out and also disclose that they've used AI to generate things. And I'm also glad that there are people who are manually crafting things that they love.

Linkarzu: You get to know them really well, right? When you see the crowd, it's like, oh, I know this person. I know no one better than talking to the person, okay? How do you feel about maintainers on the Emacs side of things with all of the code that can be easily generated right now and having to deal with that? I don't know if you maintain any packages or not but I would assume you know that big package maintainers must be going through a really difficult phase right now because everyone is sending PRs, everyone has great ideas and they need to filter Go through all of that code and clean it up. How do you feel about all that? They need to triage all that, right? Do you have any thoughts on Emacs maintainers in all of this slop?

Sacha: I was a little amused by the exchange in Org Mode, where I think Jean-Louis was proposing something that was partially generated by a large language, or actually maybe entirely generated by a large language model. And it was there as a kind of an example. And after some back and forth, Ihor started using an LLM to review it and We're definitely experimenting with how to deal with this kind of thing where the changes might be harder to understand because the volume is higher, the logic is harder to talk through. But not being a maintainer of any very popular projects myself, I have no idea the kind of things that people are going through. I do know that it It is something that we want to be thoughtful about because maintainers are volunteers. We don't want people to burn out. We also don't want contributors to burn out. We want people to be able to experiment and communicate thoughtfully and kindly.

Linkarzu: Okay. Now, two more questions that I have for you and I'll let you go. The first one that I have is... Where is this thing? Hold on. Where is this thing? What did you think about the thumbnail that we came up with?

Sacha: You know, some people in the community were like, ah, what's up with that thumbnail? Linker too likes to have fun with his AI-generated thumbnails. It's so delicate. But my daughter would like to say that she's never seen me do the thing. Also, she feels that the AI makes my eyes too big and she's not used to seeing my brain on that side. Okay.

Linkarzu: Okay. That's good.

Sacha: So you got like a zero out of five.

Linkarzu: I'm not sure I've ever made that face. I mean, I tried a couple of times afterwards, but I think I just looked very confused. What are these guys doing? Yeah, like my channel is like really random. I don't know why people still follow it, but AI helps me with ideas that I have. Like, you know, I had this idea in mind and I was like, you know, I can bring those. Okay, that's enough with the thumbnail.

1:20:58 Advice for Emacs beginners: connect with people

Linkarzu: Now, the final thing before I let you go is what would you recommend someone New into Emacs. Like, what would you tell them? Hey, go and learn this. Go and read my blog post. What do you think? Someone just watching this video not knowing what Emacs is but they were captivated by the wild things that you do in Emacs and they're going to be like I want to be that Chad. I want to be the Giga Stacey. Because it's Giga Chad and Giga Stacey I think is the female version of it. So what would you say to them?

Sacha: I would say go connect with people. Now, it's very difficult sometimes to find an Emacs user in your physical location, but there are meetups and there's Reddit and there's like, you know, there's EmacsConf and there are virtual meetups, as I mentioned, there are mailing lists, there's IRC channels. It's because Emacs can be really overwhelming if you're learning it by yourself. And there are all sorts of things that you might not even know to ask for or explore because you don't even know it's possible. So for me, learning Emacs in the community has been really helpful. I feel like I've barely scratched the surface because I'm always being inspired by other people who are sharing the cool projects that they're working on or the ideas that they're building by themselves or with the systems. And definitely, large language models can help with some of it, but it's still limited to what you can ask. So if you can hook up with the blog posts or with the IRC channels and all these other ways to connect with the Emacs community, I think that makes Emacs learning a lot more fun and a lot more effective. As you mentioned, Prot does have a coaching service, so that might be an excellent way to start. If your budget doesn't extend to €10 an hour, then you can always try IRC or other places through the meetups. People often bring their questions there as well and learn from the kinds of cool things that people are sharing.

Linkarzu: Okay, amazing, Sacha.

Sacha: Which actually brings me to stuff that I want to pick your brain about before I let you go either. Okay. The Neovim community does YouTube really well, which is cool. But there's one Reddit post asking, hey, is there a Planet Emacs life equivalent for Vim? Basically an aggregator that brings together Vim blogs or what's going on in this conference stuff. I would like the Neovim community to be more vibrant and better connected I mean, not that you really need that help. You've got way more users than the Emacs committee and that's fine. But it'd be really interesting to see people, you know, sharing blog posts and sharing cool ideas. There's our new vim, but you know, there's got to be so much more that people can share with each other and bounce ideas off each other and have those kinds of conversations about.

Linkarzu: You have a really good point. This is why you do your blog post. Is that right? Like you try to aggregate all of the different Emacs related news, videos, articles, whatever, anything Emacs related, you put it in your blog post.

Sacha: Yeah, it's... It's kind of like having a water cooler, right? If you have a place where you can bump into other people. And that Emacs News there, which is the second link on this page title, that takes me just about an hour or two to put together, depending on how distracted I am by all the cool ideas that I come across. And I've done this on livestream so people can laugh at my, you know, like, ooh, they're shiny. And it's built on top of a fair bit of automation. I just upload links on Reddit. The calendar comes in automatically. The stuff on the blog post comes in automatically. I just categorize things so that people who are interested in a particular subject area don't have the way through 60 to 70 links. They can focus on one category if they want to. But it should not be impossible to do something like this for Vim. I'm sure that maybe, especially with Org and Vim and other things, maybe people will post more notes because literate programming is an excellent way to make things clear to yourself and to other people.

1:25:16 Why is the Neovim subreddit toxic while Emacs is friendly?

Linkarzu: Nate? It's like, I don't know, there's... A lot of crazy people on the Neovim subreddit. And I don't know if that's a particularity of Neovim users. We're all toxic and we just hate each other.

Sacha: Yeah, maybe you should just come over to the Emacs community, we have hot chocolate.

Linkarzu: Now, I have gone to the Emacs side of things. Apart from frazzor749, I think he's an Emacs user because he's abusive. That's in Spanish. I don't know how to translate it. He's mean. He's mean to me. But if you go to the... Emacs of Reddit, it's like rainbows and butterflies and everyone's like, oh, you know, and there's not a lot of hate and it's something that, you know, I always wonder why does that happen? Like, it's not moderators, you know, it's just people. Is it just because it's old people? Like the professor, he doesn't want to fight anymore. He's old enough. He's just, he retired already. He's just ready to pass to the next life.

Sacha: So what... Hypothesis number two, maybe your editor makes you grumpy.

Linkarzu: Right? Right? It could be.

Sacha: I don't know. When I talk to people, they say, you know, working on Emacs, tweaking my Emacs is fun. It's relaxing. It's what I do because I enjoy doing it. I don't know. I think for Emacs, because we're so used to... feeling like our customizations are actually very personal. They're us figuring out how to build a tool so they support us better. And we have no idea whether it'll work for somebody else, but if it's useful, here, have it. It's a gift. For me, the feeling of being in the Emacs community is, it just feels like we're sharing all these things that we've figured out for ourselves in the hopes that it might help somebody else. And it pays off often enough that, you know, I might share something and then several years later someone will come across the same blog post and say, oh yeah, you know, I took that idea, I built on top of it and now you can do mind maps in Emacs because yes, why not? And I was like, wow, that's amazing. So for us, there's always been a community of sharing and knowing that there's no guarantee it'll work for anyone else, but it's amazing if it does.

Linkarzu: Uh-huh. Or is there a cult and people are all connected and when someone is misbehaving, they get punished publicly? Like Prot in the thumbnail, it's like, it's time you get punished, my boy.

Sacha: I was trying to find that bashbunni video clip where she says, you know, something along the lines of, it's not a cult, but have you heard about our Lord and Savior Org Mode? It's fun and I've met some of the nicest people in the Emacs community and I love the fact that this little corner of the internet is about sharing what works for you and imagining what could be even better and being inspired by what other people are doing with their lives. So that part is really cool. I hope that you have or can develop something like that for Neovim as well. I think that, you know, you've definitely got the videos and the reacts going. It'll be interesting to see if blog posts could make things more searchable. And for you, you have a lot of text that comes out of your videos. You could certainly get started with that. For us, we also have, you know, code... Because it's a lot about personalization and configuration, right? So we have this long tradition of literate programming and sharing the snippets of your config with an explanation in it. And I'm curious to see what that could happen, what that could do with the Vim community as well.

Linkarzu: Yeah, you have a point. There's this .file thing that came up like some years ago, but I think it's just mainly an automated thing that pulls up GitHub repos. I don't think it has like an actual prison that is behind it, pulling up news and aggregating all the stuff. There needs to be a human that does this, that adds the touch and adds the love that you do on the Emacs side of things. I'm not willing to take that job. I don't know if someone on the Neovim community is willing to do it, because, yeah.

Sacha: It's not just about the plugins or the code, right? For me, what's really interesting are the workflows that people have around it. You can look at someone's keyboard shortcuts, but it's when they tell a story of how they're doing it or when they show a video, but then you're like, wait, wait, back up a little bit. How did you do that? thing, right? And a lot of the times we learn about our tools best when we're looking over the shoulder of somebody else who's using it and we're seeing the kinds of things that they might completely forget to mention because to them, they already take it for granted. So I love that kind of sharing that people have in meetups, at conferences, in video comments, in blog posts, where we're just sharing, okay, this is what I've figured out about how to use things. And if you have any other questions, often it's like, what font is that?

Linkarzu: What font is that? That's a common word. What color scheme is that?

Sacha: People share.

Linkarzu: Okay. All right, Sacha. Amazing.

1:31:02 Planning an Emacs and Neovim panel with Prot

Linkarzu: Do you have any other topics before we wrap it up or something else that you would like to discuss? Because I've been asking all the questions and you can ask whatever you want as well.

Sacha: I'm already thinking of several follow-up things that I want to explore before our next conversation. We'll probably have another conversation in the future.

Linkarzu: With Prot, right? We can have a conversation with Prot. I was thinking as well. about Neovim versus Emacs. Because I did that video, I think it was over a year ago. There were four guests, right? And the people in the comments were like, but you should have invited Prot. You should have invited Prot or the system crafters guy, you know? Now I can have eight guests. Imagine four on the Emacs side of things and four on the Neovim side of things. The powerful ones, you know? That would be...

Sacha: It's not even really Neovim versus Emacs who's got the best tool. I think it's more like, okay, you've got Neovim stuff. That's cool. And you've got Emacs stuff. That's cool. How can we inspire each other? How can we be like, oh, that's a great idea. I've got something similar. That's a little like this. I'm going to yoink your idea and smoosh it into this one. And then we're going to see what we can make this. And I think that kind of back and forth would be amazing. Even in preparation for this conversation, I've had a lot of fun tinkering with my video editing workflow, with the conversations, the live transcriptions, the animation of SVGs in Emacs, the reordering of group elements inside an SVG so that I don't have to use Inkscape to manually order things. I can just use Org Mode and shuffle items around in the list in order to get my SVG to animate in the order that I wanted to. Oh, and I have this thing now also now where I can give it a YouTube URL and it opens a transcript for that video so that I can clip things out of your most recent stuff directly from your YouTube channel without having to download it or run the transcription myself because YouTube has auto subs and chapters. Thank you. So yeah, I've had a lot of fun preparing for this conversation and I think As we get more people talking and exchanging ideas, we'll have even more ideas to explore.

Linkarzu: Yeah. I always do the versus thing, but it's not a versus. If you go and take a look at that old video, there was not like a debate, like, my tool is better than yours. It was like, ah, it was friendly. It was a pretty friendly conversation. So, yep.

Sacha: I want Neovim to thrive and all the other Vim variants and all the other editors that people come up with because people are always choosing these tools for their reasons and they're perfectly wonderful reasons. And I want to see what extent we can take it, right? How awesome can it get? And then of course, if there's a really awesome idea, chances are someone in Emacs is going to be like, oh yeah, I can do that in about 15 lines of Emacs.

Linkarzu: Oh yeah. Spicy takes. Spicy takes there.

Sacha: Who knows, right? And sometimes it might be that we'll call out to something. Besson Carey was telling me, and I'm going to see if I remember this correctly, because he was telling me this anecdote in French. which I only partially understand. So he was telling me that he was at a TupperVim community meeting. So they were sharing Vim tips and he was like, oh, that's a really nice table. How did you get it to display so nicely? And the guy hemmed and hawed and eventually admitted that he had actually shelled out the Emacs to run the code and evaluate it and then get the image, get the output back and then put it in Vim. It's totally possible to borrow ideas and use them back and forth, even to the extent of calling the other plugin in order to just get the stuff done.

Linkarzu: Yeah, I see that a lot. People are switching between two. Like, there's some... People that switch to Helix for some reason. I don't know if you've heard about Helix. It's fine, whatever. But I've seen that crossover a lot. People switch from Neovim to Emacs, then they go from Emacs to Neovim and they're like this. You know, and that cross pollination, is that how you say it? Helps, you know, both tools, right?

Sacha: and it's plain text and you can ship things back and forth. And if you are a large language model using person, you can just use AI to translate code back and forth to Knows, we'll see. And if you want to use Emacs Client or an embedded process or whatever else, that's also totally cool. Whatever gets a job done and whatever lets you explore that idea, right?

1:35:53 Do editors and terminals still matter with AI agents?

Linkarzu: Yep, yep, yep. One final thought that I have. What do you think about editors and terminals? Because people say like, okay, maybe I live in a bubble, you know, but on Twitter... Yeah, I think we live in a bubble. And that's what I get surrounded with. But people is like, why do you still use a terminal, right? Now it's all about agents. Why do you use an editor in this day and age, right? There's a lot of people that actually don't use them because they are full agentic now. What do you think? The future looks like for Emacs and Neovim and terminals, which, you know, Neovim needs a terminal, right? So it's like that's what gives its superpowers as well. Do you have any thoughts you want to share on that?

Sacha: I like the way that Emacs gives me kind of an interface toolkit if I want to edit videos as text or if I want to look at my agenda or if I want to make a buffer with buttons that I can click on. It gives me a bit more of that richness and flexibility that going with either a conversational chat agent interface doesn't or I would have to have the agent generate me a whole interface and then I would have to tell it, OK, but I want it to behave this way and then I wouldn't be able to integrate it as easily with the rest of my stuff. So I don't think, for me at least, that agents are quite there yet. I'll give you an example. So I'm organizing EmacsConf, right, and I need to keep track of the schedules that I've emailed speakers because that way I can tell if I've changed the schedule whether I need to email them again with a new schedule, right? Makes sense. And because I also do my email within Emacs, I can set it up so that when I send the email, not when I've composed the email because if I've composed the email using my mail merge but then I get distracted and I change my mind, it doesn't actually get sent yet, right? Only after I send the email will it go and update that specific talk's details in my Org Mode file with all of my conference talk information, naturally. and then that will be saved for the next time that I move the schedule around. Now I guess theoretically someone could have an agent that says okay I give you access to my email, I give you access to the conference schedule web system or whatever database and then I want you to update the database in case this happens but it It would be a lot more opaque to me. I wouldn't be able to say, oh yeah, I want to do that but I also want these other things to happen and I want the SVG to show up and I want the wiki to be changed. There's a lot of moving parts and it's a lot harder for me to think of how to get in there and change things in case there's a bug or in case I wanted to see what else is possible. So I like the fact that Emacs lets me build these interfaces using keyboard shortcuts and voice commands now and all these other things and it feels like it's all together and I don't have to keep reinventing the wheel.

Linkarzu: Yeah, yep. I do kind of something similar. This is the way that I schedule live streams now, you know? I have a snippet, Neovim. So I just type something here, live stream with a guest, open terminal, or if it's a solo live stream, that's going to add my snippets. And I just fill it up and I have a key map that I execute. It schedules the live stream, sends emails to the guests, if there are guests, you know?

Sacha: Yeah, I got that too.

Linkarzu: You have that? Yeah, yeah. So it's one of the things that I'm...

Sacha: Do you have it also update your YouTube stream description through API?

Linkarzu: Yeah, the title, the description is right here.

Sacha: Yeah, yeah, yeah, yeah. And then what else do I have in mine? Mine, I have it do the time zone conversions because I really suck at time zone conversions. I choose UTC and I tell guests, you know?

Linkarzu: UTC, it is.

Sacha: But I also like including the gazillion time zone translations in the description so that people don't have to do the UTC conversion themselves. So based on the timestamp for the event, I have this thing that allows me to pick up the... Time Zone translations because I use that for EmacsConf and then I just generalize it so I can use it for everything. And then that can go into the YouTube description. And then I have the same entry get turned into the blog post afterwards because I can publish that with a transcript and the screenshots as I showed you before.

Linkarzu: Okay. Automation. It's all about automation. It is.

Sacha: It absolutely is. Oh, and the thing that I have which also lets me copy the chat and then if I paste it in, then I can have it reformatted so that it looks nicer because otherwise when you paste it in, there's lots of spaces and stuff. But that's a fairly easy text transformation thing. So you should be able to do something like that just fine.

1:41:04 Speech synthesis in Emacs: whispering slide hints

Linkarzu: Let me show you something cool as well. heisenbug, can you please send us a speech to text command in chat?

Sacha: Oh, yeah, I saw that one.

Linkarzu: You should be able to hear it as well. You've seen it?

Sacha: Yeah, I've heard that before in your other videos, which is actually... So one time I was giving an in-person presentation with Emacs, well, about Emacs at one of the demo camps, back when demo camp was a thing. And because I wasn't entirely sure about my ability to remember what my next slide was going to be about, I had Emacs do the speech synthesis of a hint for my next slide in the back, you know, in my earbuds, earphones back then. And someone was like, is Emacs telling you what to say? Because speech synthesis is actually, you know, it's another channel that you can use to get information. So that's very cool. And I have been tempted to come up with something similar because I sometimes forget to check chat. But it's possible, for example, to have it say, okay, say it out to me first and then maybe I'll hit a keyboard shortcut and then it will say it again on the main channel that will go out in the stream.

Linkarzu: So it's safe. Yeah, yeah. It becomes a mess because I have it limited to members now. Only members can send the say command. When I was in the early testing phase, I enabled it for everyone. And guess what? The bots found it and they started sending say commands like it's going to happen, you know, and it's just going to run out of control.

Sacha: The other reason why you can have that, right? So you have the chat and you have the TTS so that you know that something has happened in the chat, but then you can trigger it to play in the channel when you want to. And possibly with a completion interface, you can select which utterance you want to have at the right time. So if people are having questions, you know that the question is there, but you can pick which question you want to focus on first, or you can wait for the natural pause in the conversation in order to help. Yeah, that's a good idea.

Linkarzu: That's a good idea. It makes sense.

Sacha: Yeah, right. So this kind of like back and forth brainstorming, it's totally possible to implement it in either way. I would end up implementing it in Emacs, of course, because then it can hook into all of my other stuff. But you can certainly implement it in whatever it is that you're using to listen to the TTS. Is that SocialStream Ninja maybe?

Linkarzu: SocialStream. Yep, yep, yep. And I send it to Gemini because

Sacha: Yeah, yeah.

Linkarzu: It sends it to Gemini. That's why it sounds accurate. I think Gemini is a pretty good one, uh, for that.

Sacha: Yeah, it's pretty good. Yeah, for local, for local speech to text, I've been using Kokoro, uh, which...

Linkarzu: But it sounds a little bit robotic, right? Yep, yep.

Sacha: Yeah. But yeah, Gemini is pretty good and there's so many different options now. It's fantastic. And it does give you the other channel. Back a long time ago, in fourth year university, so 2003 or 2002, I was monitoring IRC. I had a lot of fun hanging out in IRC. And so I set up my Emacspeak so that if somebody mentioned me in the channel, it would say something so that I could then go and study. But I had this like thing of distraction. Like, you know, if someone wanted to talk to me specifically, I could hear about it. And likewise, having it announce things like, oh yeah, the compilation is done, meant that during the nights where I was staying up late and kind of just catching little micro-naps while waiting for my code to finish, I could just have that micro-nap and then wake up when the ding or the announcement went off.

Linkarzu: Oh, yeah. Like I say, automation. Once you try automating stuff like Emacs new them, I think that's why we love the tools so much because they just allow you to do whatever you want to do. There's no limits. No, you can do that. Up to you, up to whatever you want to do, right? Yeah.

Sacha: Yeah. And the nice thing about this, even if you're just smoothing things over a little at a time, it's very tempting to fall down the rabbit hole, right? And you spend like the next two hours tweaking something. This is my life, right? But it is also possible to try to be slightly disciplined about it and say, OK, I'm going to just modify one thing. and I'm going to write one function or whatever, make this one little bit better. And then the next time you do it, you do another little bit. And so there's that XKCD automation kind of grid of when it makes sense to automate something. And I find myself automating things that really aren't technically justified by how often I do it. But because all those little bits of code add up and they They become useful in a combinatorial way. It's not just linearly adding up. Each little bit of code becomes a piece I can use somewhere else for a purpose that's completely unexpected at that moment. It becomes so powerful.

Linkarzu: Yeah, it does. If I need to prepare for a live stream, there's a lot of applications that you need to open. You need to open OBS. I need to open Chrome where the conversation between the two of us is happening. I need to open social stream. I need to open a lot of like 10 or more than 10 applications. So I automated that. Even YouTube Studio is open. Like all of it, because it's annoying, but it's... Yeah, yeah.

Sacha: I have a prepare to go live. It does it automatically for me too. It brings up the live streaming dashboard. It double checks all these other things. And then it copies the description over in case I'm doing a spontaneous live stream. And then I can verify that and then I can say, okay, let's go live.

Linkarzu: All right, Sacha. Amazing conversation. Thank you very much. We're going to see if the editing workflow works. We're going to see a clip of this later today. Hopefully. We're going to see who gets it out first. That's a race.

Sacha: Oh, I'm allowed to clip yours?

Linkarzu: Yeah. You can clip it. It's fine. It's completely fine.

Sacha: All right.

Linkarzu: You're going to win. Emacs.

Sacha: I already have my real-time transcript.

Linkarzu: You already won. Yeah.

Sacha: I don't know. I trust your editing chops, but I love being able to pull things out. And I do want to make sure that all the cool things that people can build on will be available as text. So I will go and edit the transcript and then you can use that too.

Linkarzu: Okay. Amazing. Sacha, thank you very much. Hope you have a wonderful day. Thanks chat as well. Talk to you later.

Sacha: All right. Okay. Bye.

Related:

• Clip: Emacs voice control - describing my setup during Linkarzu's livestream
• Upcoming chat with linkarzu about using Emacs for 25 years
• Emacs Carnival Oct 2026: Exploring keys and voice input in Emacs

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

Intro

I usually stick with some favorite font for a while, then, for some reason, the bug bites: some new activity, different hardware or work, and I want to change the default font.

I have this old file with content like this:

(set-face-attribute 'default nil :family "3270 Nerd Font Mono")
(set-face-attribute 'default nil :family "GoMono Nerd Font")
(set-face-attribute 'default nil :family "Hack Nerd Font Mono")
(set-face-attribute 'default nil :family "Iosevka Nerd Font Mono")
(set-face-attribute 'default nil :family "JetBrainsMono Nerd Font")
;; ... and a bunch more

What I do (shame on me) is put the cursor at the end of a line, C-x C-e, switch back to the buffer or tab I was working on, look around for a while, switch back to the file, move down one line, C-x C-e again... You get the idea. It works, but it's clunky, and changing the size means editing the line and adding :height to it.

I wanted a way to scrub through my font list and increase or decrease the font height using only the arrow keys, while I check live what feels right.

That's a perfect job for a transient menu, which has shipped with Emacs since version 28, written by the one and only Jonas Bernoulli, author of nothing less than Magit.

This post is a walkthrough of how you can implement such functionality yourself, and hopefully a guide along your Elisp learning journey.

TL;DR: jump straight to the full source, put it in your init file, edit the font list, and run M-x font-cycle.

Font Candidates

First, we build a list of font families:

(defvar font-cycle-families
  '("3270 Nerd Font Mono"
	"GoMono Nerd Font"
	"Hack Nerd Font Mono"
	"Hurmit Nerd Font Mono"
	"Inconsolata LGC Nerd Font"
	"Iosevka Nerd Font Mono"
	"IosevkaTerm Nerd Font Mono"
	"JetBrainsMono Nerd Font"
	"Lekton Nerd Font Mono"
	"M+CodeLat50 Nerd Font"
	"Maple Mono NF"
	"MartianMono Nerd Font"
	"SauceCodePro Nerd Font"
	"UbuntuMono Nerd Font Mono"
	"VictorMono Nerd Font Mono"
	"ZedMono Nerd Font Mono")
  "Font families to cycle through with `font-cycle'.")

If you don't know the exact family name of a font you have installed, and how it is "perceived" by Emacs, you can use M-x describe-font with completion, or M-: (font-family-list).

If a family on that list is not installed (a typo, another machine, a font you uninstalled), set-face-attribute won't complain. Emacs just falls back to some other font, and you end up judging the wrong thing. So, before cycling, we keep only the families Emacs can actually find:

(defun font-cycle--installed ()
  "Return the members of `font-cycle-families' installed on this system."
  (seq-filter (lambda (family) (find-font (font-spec :family family)))
			  font-cycle-families))

Left and Right (fonts) Cycling

Cycling is an index and a mod. The mod is what makes it wrap around: going right from the last font takes you to the first one, and going left from the first takes you to the last.

(defvar font-cycle--index 0
  "Position of the current font in the installed families.")

(defun font-cycle--select (index)
  "Use the installed family at INDEX, wrapping around both ends."
  (let ((fonts (font-cycle--installed)))
	(unless fonts
	  (user-error "None of `font-cycle-families' is installed"))
	(setq font-cycle--index (mod index (length fonts)))
	(set-face-attribute 'default nil
						:family (nth font-cycle--index fonts))))

(defun font-cycle-next ()
  "Switch to the next font."
  (interactive)
  (font-cycle--select (1+ font-cycle--index)))

(defun font-cycle-previous ()
  "Switch to the previous font."
  (interactive)
  (font-cycle--select (1- font-cycle--index)))

Note that mod in Elisp follows the sign of the divisor, so (mod -1 16) is 15, not -1. This is what we want for going left.

Up and Down (height) Cycling

For the size, we change the :height of the default face. Its unit is 1/10 of a point, so a step of 10 is one point:

(defun font-cycle--resize (delta)
  "Change the default face height by DELTA (1/10 pt)."
  (set-face-attribute 'default nil
					  :height (+ (face-attribute 'default :height) delta)))

(defun font-cycle-bigger ()
  "Increase the font size by 1pt."
  (interactive)
  (font-cycle--resize 10))

(defun font-cycle-smaller ()
  "Decrease the font size by 1pt."
  (interactive)
  (font-cycle--resize -10))

Keeping the Winner

When I finally find a combination I like, I don't want to remember and retype it. So one more command builds the exact line for my init file and puts it in the kill ring for later yanking:

(defun font-cycle--form ()
  "Return the `set-face-attribute' call for the current font."
  (format "(set-face-attribute 'default nil :family %S :height %d)"
		  (face-attribute 'default :family)
		  (face-attribute 'default :height)))

(defun font-cycle-copy ()
  "Copy the current font setting as Elisp to the kill ring."
  (interactive)
  (kill-new (font-cycle--form))
  (message "Copied: %s" (current-kill 0)))

Then it's just a C-y in init.el.

The Transient Menu

Now let's glue everything together. Each suffix marked with :transient t runs its command and keeps the menu open, so you can press the arrows as many times as you want. y and q don't have it, so they close the menu.

(transient-define-prefix font-cycle ()
  "Cycle through `font-cycle-families' and adjust the font size."
  [:description font-cycle--description
   ["Font"
	("<right>" "next" font-cycle-next        :transient t)
	("<left>" "previous" font-cycle-previous :transient t)]
   ["Size"
	("<up>" "bigger" font-cycle-bigger       :transient t)
	("<down>" "smaller" font-cycle-smaller   :transient t)]
   ["Done"
	("y" "copy as elisp" font-cycle-copy)
	("q" "quit" transient-quit-one)]])

The :description of the outer group is a function, and transient calls it again every time the menu is redrawn. That gives us a header that always tells which font is on screen, its size, and where we are in the list:

(defun font-cycle--description ()
  "Header showing the current font, its size and position in the list."
  (format "%s  %dpt  [%d/%d]"
		  (propertize (face-attribute 'default :family) 'face 'bold)
		  (/ (face-attribute 'default :height) 10)
		  (1+ font-cycle--index)
		  (length (font-cycle--installed))))

Run M-x font-cycle and you get something like this at the bottom of the frame:

IosevkaTerm Nerd Font Mono  16pt  [7/16]
Font             Size            Done
 <right> next     <up>   bigger   y copy as elisp
 <left>  previous <down> smaller  q quit

Since the menu lives at the bottom, everything above it is your real work: the buffers you were editing, your theme, your splits. Tap right, look, tap right again. If you like it, bump it up a point or two. When you're done, y and paste.

If you want it one key away:

(keymap-global-set "C-c f" #'font-cycle)

Full Source

;;; font-cycle.el --- Test-drive fonts with a transient menu  -*- lexical-binding: t; -*-

(require 'transient)

(defvar font-cycle-families
  '("3270 Nerd Font Mono"
	"GoMono Nerd Font"
	"Hack Nerd Font Mono"
	"Hurmit Nerd Font Mono"
	"Inconsolata LGC Nerd Font"
	"Iosevka Nerd Font Mono"
	"IosevkaTerm Nerd Font Mono"
	"JetBrainsMono Nerd Font"
	"Lekton Nerd Font Mono"
	"M+CodeLat50 Nerd Font"
	"Maple Mono NF"
	"MartianMono Nerd Font"
	"SauceCodePro Nerd Font"
	"UbuntuMono Nerd Font Mono"
	"VictorMono Nerd Font Mono"
	"ZedMono Nerd Font Mono")
  "Font families to cycle through with `font-cycle'.")

(defvar font-cycle--index 0
  "Position of the current font in the installed families.")

(defun font-cycle--installed ()
  "Return the members of `font-cycle-families' installed on this system."
  (seq-filter (lambda (family) (find-font (font-spec :family family)))
			  font-cycle-families))

(defun font-cycle--select (index)
  "Use the installed family at INDEX, wrapping around both ends."
  (let ((fonts (font-cycle--installed)))
	(unless fonts
	  (user-error "None of `font-cycle-families' is installed"))
	(setq font-cycle--index (mod index (length fonts)))
	(set-face-attribute 'default nil
						:family (nth font-cycle--index fonts))))

(defun font-cycle-next ()
  "Switch to the next font."
  (interactive)
  (font-cycle--select (1+ font-cycle--index)))

(defun font-cycle-previous ()
  "Switch to the previous font."
  (interactive)
  (font-cycle--select (1- font-cycle--index)))

(defun font-cycle--resize (delta)
  "Change the default face height by DELTA (1/10 pt)."
  (set-face-attribute 'default nil
					  :height (+ (face-attribute 'default :height) delta)))

(defun font-cycle-bigger ()
  "Increase the font size by 1pt."
  (interactive)
  (font-cycle--resize 10))

(defun font-cycle-smaller ()
  "Decrease the font size by 1pt."
  (interactive)
  (font-cycle--resize -10))

(defun font-cycle--form ()
  "Return the `set-face-attribute' call for the current font."
  (format "(set-face-attribute 'default nil :family %S :height %d)"
		  (face-attribute 'default :family)
		  (face-attribute 'default :height)))

(defun font-cycle-copy ()
  "Copy the current font setting as Elisp to the kill ring."
  (interactive)
  (kill-new (font-cycle--form))
  (message "Copied: %s" (current-kill 0)))

(defun font-cycle--description ()
  "Header showing the current font, its size and position in the list."
  (format "%s  %dpt  [%d/%d]"
		  (propertize (face-attribute 'default :family) 'face 'bold)
		  (/ (face-attribute 'default :height) 10)
		  (1+ font-cycle--index)
		  (length (font-cycle--installed))))

(transient-define-prefix font-cycle ()
  "Cycle through `font-cycle-families' and adjust the font size."
  [:description font-cycle--description
   ["Font"
	("<right>" "next" font-cycle-next        :transient t)
	("<left>" "previous" font-cycle-previous :transient t)]
   ["Size"
	("<up>" "bigger" font-cycle-bigger       :transient t)
	("<down>" "smaller" font-cycle-smaller   :transient t)]
   ["Done"
	("y" "copy as elisp" font-cycle-copy)
	("q" "quit" transient-quit-one)]])

(provide 'font-cycle)
;;; font-cycle.el ends here

What Could be Improved

A few extras, if you want to practice some Elisp:

• Replace the index and mod with Emacs' built-in ring.el.
• Show the visible columns and lines in the header, so you know how much fits on screen with each font and size.
• Start cycling from the font you are currently using.
• Add a key that restores the font and size you had before opening the menu.
• Cycle themes, or a second list for the variable-pitch face, the same way.
• Turn it into a publishable package: defcustoms, an autoload, proper headers, and a clean checkdoc and byte-compile.

Honorable Mentions

Font picking seems to be in the air lately. If you'd rather use something ready-made, or just want to see other takes on the idea, check these out:

• show-font, by Protesilaos, on GNU ELPA: previews installed fonts in a dedicated buffer, and show-font-tabulated lists every font rendered in its own typeface.
• flick, "a quick and simple font picker", by Vegas Harmon, recently shared on r/emacs.
• This r/emacs comment, from a recent discussion on the same subject.

Wrapping Up

There's nothing specifically clever here: a list, an index, a mod, and a transient menu holding it all together.

I hope this educational post helps you with the basics of using transient, and maybe teaches you something new about Emacs Lisp along the way.

As for me, I'm currently on font 7 of 16. Ask me again next month.

I first tried mise while setting up Arch Linux on my Dell XPS 13. I was bringing over my Doom Emacs configuration, which used asdf.el, and considering how mise would fit into the same environment.

Colleagues had already spoken well of it. What interested me was the possibility of simplifying runtime integration in both Fish and Emacs. If that worked on the Dell, I was considering the same change on my Mac.

The useful test was inside the editor. I set up separate directories for Ruby 3.4 and 3.3, opened their Ruby files in Doom, and checked the version from each buffer. Each one used the Ruby selected for its directory. I also confirmed that Doom could find Node and npm, and that the Elixir tools were available.

That gave me a working setup on Arch before moving my main Mac environment away from asdf. The Mac work then extended into Fish configuration and the tools Emacs launches. The migration described here took place in October 2026; the Mac checks used mise 2026.10.21.

Keeping project version files

The starting point on the Mac was a set of projects with existing version files. Replacing the manager did not require changing every project’s Ruby or converting all those files to a new format.

Mise reads .tool-versions, the format I was already using with asdf. For ecosystem-specific files such as .ruby-version and .nvmrc, I enabled the corresponding tools in the global settings:

[settings]
idiomatic_version_file_enable_tools = ["ruby", "node"]
experimental = true

The experimental setting is used by the installed mise.el, which checks it before enabling the integration.

My personal defaults now live in ~/.config/mise/config.toml. Its current tool selections include changes made during the wider cleanup:

[tools]
elixir = "1.20.2-otp-29"
go = "1.27"
ruby = "4.0.9"
rust = "1.99.1"

Those are personal defaults. A project’s files can select another version. During the migration checks in the blog repository, mise current ruby reported 3.4.6. The project’s .tool-versions selected that version even though its .ruby-version said 3.4.5.

The configuration rules determine how global and project files combine. I checked the effective selection rather than assuming that finding a familiar version file was enough. mise config ls lists the configuration files being read, and mise current ruby reports the selected Ruby.

I manage my dotfiles with GNU Stow. During the transition, the package still named asdf retained .tool-versions, .default-gems and .default-mix-commands. I later moved those files into the mise package and recreated their Stow links. The move left the effective runtime selections unchanged. That was configuration housekeeping, separate from moving or installing runtimes.

The default-installation files were retained, but I have not validated that a fresh Ruby or Elixir installation consumes them automatically.

Letting Fish activate mise

On Arch, the first mise doctor check reported that mise was not activated. After setting up Fish activation, it reported no problem. Installing the executable had been one step; arranging the shell environment was another.

On the Mac, mise is installed through Homebrew. I did not need to add an activation line to my own config.fish: this installation supplies /opt/homebrew/share/fish/vendor_conf.d/mise-activate.fish:

if [ "$MISE_FISH_AUTO_ACTIVATE" != "0" ]
  /opt/homebrew/opt/mise/bin/mise activate fish | source
end

The Fish setup documentation describes this package-provided activation. I kept that mechanism instead of adding another copy to my personal configuration.

The surrounding Fish changes made the command paths explicit. Personal paths moved into conf.d/00-environment.fish, which normalizes the inherited PATH, removes duplicates and filters known obsolete entries, including the old asdf shims. Asdf and older installations were cleaned up as part of that work.

The prompt also needed to follow the new manager. My old override parsed .tool-versions itself. Its replacement asks mise current once per render and displays the languages relevant to the directory. Ruby, Node and Elixir were joined by Rust, detected through files such as Cargo.toml. The prompt now uses mise’s selection rather than maintaining its own version-file parser.

Rustup remains in this setup: the mise Rust entry links to the existing ~/.cargo/bin directory. I added Rust to the same prompt segment rather than adding another standalone version check.

The wider Fish review also removed the old Oh My Fish Emacs plugin and kept the command helpers I use as autoloaded functions. That removed an emacs --version call from shell initialization. I did not measure a before-and-after startup time for it.

The environment inside Doom

The Doom change had two parts. I replaced the asdf.el package declaration with the recipe for mise.el in packages.el:

(package! mise :recipe (:host github :repo "eki3z/mise.el"))

In config.org, I replaced the asdf-enable setup with:

(use-package! mise
  :config
  (global-mise-mode +1))

On Arch, after synchronizing Doom, I confirmed that the mode was active and that Emacs could find the Ruby shim. I checked Ruby LSP and ElixirLS in that setup.

The installed revision of mise.el makes the mechanism visible. It calls mise env --json, merges the result into a buffer-local process-environment, and derives a buffer-local exec-path from the resulting PATH.

Emacs uses exec-path to find a program named without an absolute path. The process it starts inherits process-environment, including the PATH used to find its own child commands. The Emacs process reference describes both roles. That is why checking Ruby in a terminal alone could not validate what a formatter or language server launched by Emacs used.

The package uses inheritenv around selected commands, including shell-command-to-string, so they can carry the editing buffer’s environment into temporary buffers.

Doom has its own environment snapshot as well. In this revision, doom sync regenerates an existing snapshot; doom sync --env also creates one if absent. The Emacs command doom/reload-env only loads the saved file into the running session. On Arch, doom doctor continued to warn that my PATH had changed even while the runtime checks worked. I did not establish the cause of that warning.

On the Mac, my Ruby formatter configuration also follows the project: RuboCop when a .rubocop.yml is present, otherwise Standard. RuboCop uses bundle exec when there is a Gemfile. Both commands clear inherited Bundler-related variables before starting, and Standard uses the gems available to the selected Ruby. The full configuration contains the details; the important connection here is that a formatter needs the project’s environment as well as its configuration file.

Following the development tools

Some settings outside the runtime manager still named the old locations. My Arduino configuration was one of them:

 (defvar bounga/arduino-language-server
-  (expand-file-name "~/go/bin/arduino-language-server"))
+  (executable-find "arduino-language-server"))

The defvar initializer does not repeat the lookup each time I open an Arduino buffer. Resolving it to a mise shim gives that saved value a stable path while the executable lives under a particular Go installation. Checking the running Emacs confirmed the shim path, and the server answered its help command.

An installation problem with arduino-language-server and dockfmt led me to check Go. Mise had Go 1.27.3 installed, but it was inactive in the directory where I was working, so ordinary commands still found Homebrew’s Go 1.26.6. mise exec go@1.27.3 -- go version used the intended installation, and both tools built with it in a temporary directory. I then selected Go globally and installed them.

mise install does not record a version selection; mise use records one and installs the runtime if needed. I did not reproduce the original installation error, so the inactive Go is an observed problem, not a demonstrated cause of that failure.

This setup puts Go-installed executables in the selected Go version’s bin directory through GOBIN. It changes where the tools live. After adding an executable there, mise reshim makes it available through the shim directory.

That mattered for dockerfmt, which Doom actually uses for Dockerfiles. I had a copy installed with Homebrew, and Emacs kept finding it after I installed dockerfmt with the mise Go. After mise reshim, executable-find resolved to the mise shim. The earlier dockfmt build concerned a different formatter. Doom’s Docker configuration uses dockerfmt, although its doctor check still looks for dockfmt.

Gems outside the checkout

I made a separate storage change during the cleanup: removing the global Bundler path setting that sent gems into vendor/bundle. Projects using the same Ruby installation can now share installed gems.

Mise selects Ruby and, in this setup, its RubyGems directory. Each project’s Gemfile and lockfile still select its dependencies. With Ruby 3.4.6, Gem.dir matches Bundler.bundle_path under both Bundler 2.3.17 for the blog and 4.0.17 for ctf_tracker.

That follows the Bundler policy, not a mise feature. The configuration reference specifies Gem.dir as the default before Bundler 5, and a repository-relative .bundle directory starting with Bundler 5. A project can override path.

Seven active projects passed dependency and principal-library load checks against the shared directories, with their Gemfiles, lockfiles and Ruby selection files unchanged. After cleanup, ctf_tracker also passed its 86 examples. The global automatic-installation and cleanup settings were removed, along with a production exclusion that excluded no dependencies in those projects. My .gemrc now only disables documentation and backtraces, with its Stow link preserved.

The 45 removed vendor/bundle trees had an allocated size of about 10.46 GiB in the retained du -sk inventories. Gems were also installed in the shared directories, so this is not a measured net saving. With those trees removed from the checkouts, I re-enabled LSP file watchers. After restarting Emacs, a large Rails project opened without a warning or noticeable slowness, an observation limited to that project.

The two Ruby buffers on Arch were an early check that per-directory selection could work inside the editor. On the Mac, getting there also meant replacing old paths and checking the tools launched by the editor. The project dependency files could stay as they were while I changed the runtime manager and the environment around them.

I recently wrote about revisiting my Doom configuration. I also got Emacs Everywhere working on my Mac: select text in a browser field, edit it in an Emacs frame, then send the result back.

A macOS setup shared in the project’s issue tracker uses Hammerspoon. I used Apple’s built-in Shortcuts app for the launcher and keyboard binding. My successful test was a GitHub comment field in Safari: the edited text returned to the field, without submitting the comment.

This is my tested Doom setup with Homebrew Emacs Plus 31, specifically Emacs 31.0.91. The launcher was small; getting it to find my running server and giving Emacs the right permission took more attention.

Enable the Doom module

In ~/.config/doom/init.el, enable everywhere under :app in the existing doom! block. Then synchronize Doom and restart Emacs:

~/.config/emacs/bin/doom sync

Emacs must already be running with its server active. Use M-x server-start if needed. This launcher does not start Emacs for you. The Doom module documentation describes the integration; in the version I tested, doom +everywhere calls emacsclient --eval '(emacs-everywhere)'.

Build the shortcut

Open Shortcuts, create a shortcut named Emacs Everywhere, and add a Run Shell Script action. Choose bash, leave the action’s input variable unset, and keep Run as Administrator off. With no input, the Pass Input setting does not matter.

Paste this script, adapting the absolute Doom path on the last line:

export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8
export EMACS_SOCKET_NAME="$(/usr/bin/getconf DARWIN_USER_TEMP_DIR)emacs$(/usr/bin/id -u)/server"

/Users/nico/.config/emacs/bin/doom +everywhere

The locale exports addressed a warning I encountered with en_FR.UTF-8. The socket export addressed a more confusing failure: the command worked in Terminal, but Shortcuts reported that emacsclient could not find the socket even though my server was running.

getconf DARWIN_USER_TEMP_DIR obtains my account’s temporary directory; id -u supplies its numeric user ID. Together they locate the default macOS socket without hardcoding a /var/folders/... path. EMACS_SOCKET_NAME tells the client which socket to use. If you customize server-name or server-socket-dir, adapt the expression.

I reproduced the lookup failure with a different TMPDIR and confirmed that the explicit socket fixed it. I did not inspect Shortcuts’ own environment, so that test does not establish its exact difference from Terminal.

Open the shortcut’s Details panel (ⓘ), choose Add Keyboard Shortcut, and press Control+Option+Command+E (⌃⌥⌘E). This combination worked in my setup; check for conflicts in yours. Apple’s keyboard shortcut instructions describe the same binding mechanism.

My macOS interface is in French. “Exécuter le script Shell” is Run Shell Script, and “Détails” is Details. The shortcut receives Quick Action input, but the shell action has no input variable: Emacs Everywhere handles the selected text itself.

Allow Emacs to control the source application

In System Settings → Privacy & Security → Accessibility, add and enable the Emacs application you actually run. This is the macOS permission for controlling other applications.

Allow Emacs to control other applications in Privacy & Security → Accessibility. The screenshot shows the enabled entry in my French UI.

An enabled entry was not enough in my case. I removed it, added the current Homebrew application again, and fully restarted Emacs. The tested app was /opt/homebrew/Cellar/emacs-plus@31/31.0.91/Emacs.app.

Before that, I saw errors with codes -25211 and -1719, meaning that osascript was not allowed assistive access. Re-adding Emacs resolved the permission problem; I did not establish why the earlier entry failed.

A Homebrew upgrade may require granting this permission again. On my Mac, /Applications/Emacs.app already links through /opt/homebrew/opt/emacs-plus@31/Emacs.app, but Finder resolves it to the versioned application when I add it. I would not rely on that symlink to preserve permission. I upgrade Emacs infrequently and chose to re-add it when necessary.

Select the text before launching

This was the missing step in my first attempt: select the source text. Putting the caret in the field was not enough. Without a selection, my installation imported the existing clipboard contents, including a path I had copied earlier.

For a first test:

1. Click inside an editable text field in Safari and enter some text.
2. Press Command+A inside that field to select its contents, then ⌃⌥⌘E. I did not need a separate Command+C.
3. Actually change the text in the Emacs frame, then finish with C-c C-c. The edited text should return to the original field.

Use C-c C-k to cancel without pasting back. In the installed version, an unchanged buffer is also treated as an aborted session, so opening and immediately closing it does not test the return path.

If the frame title contains an AppleScript error

I also encountered this where the application or window name should have appeared:

script error -1758. Couldn't get error text because of error -1700.

The installed package compiled its helper scripts with osacompile -r scpt:128 -t osas, producing legacy resource-fork scripts. osadecompile rejected those files with errOSADataFormatObsolete (-1758). Newly compiled data-fork scripts were readable. Rewriting the existing file’s data fork alone did not repair it: the obsolete resource fork remained. Replacing the file did.

The GitHub source checked on 1 November 2026 still uses that compilation command. Check your installed version before adding this workaround; it is not a prerequisite for every installation.

I keep this in an emacs-lisp source block with :tangle yes in ~/.config/doom/config.org, which generates config.el. If you use a literate configuration too, edit the Org source rather than the generated file.

(after! emacs-everywhere
  ;; macOS rejects the legacy resource-fork AppleScripts generated upstream.
  (defun +everywhere-modern-applescript-a (fn &rest args)
    (let ((default-directory emacs-everywhere--dir))
      (apply fn args)
      (dolist (script '("app-name" "window-title" "window-geometry"))
        (unless (zerop (call-process "osadecompile" nil nil nil script))
          (let ((compiled (make-temp-file "everywhere-")))
            (unwind-protect
                (progn
                  (unless (zerop (call-process "osacompile" nil
                                              "*everywhere compilation*" nil
                                              "-d" "-o" compiled
                                              (concat script ".applescript")))
                    (error "Could not compile Emacs Everywhere script: %s" script))
                  (delete-file script)
                  (rename-file compiled script))
              (when (file-exists-p compiled)
                (delete-file compiled))))))))
  (advice-add 'emacs-everywhere--ensure-oscascript-compiled :around
              #'+everywhere-modern-applescript-a))

The wrapper runs the package’s compilation function from its actual directory, checks each helper with osadecompile, and replaces unreadable files with freshly compiled data-fork versions. It also covers later regeneration. The private function name is upstream’s spelling, including oscascript; this advice may need adapting after a package update.

Forced regeneration and decompilation of all three repaired helpers worked in my tests. After fixing Accessibility permission, application and window queries worked too.

The useful check was the complete round trip in Safari. Once I selected the field’s contents before launching, I could edit them in Emacs and return them with C-c C-c. That is the sequence I would test first after changing this setup.

Three years ago, I wrote about marking the active window (update here ) so that it’s easy to pick it out from the other, inactive windows. I did that by making the mode line of the active window a distinct color instead of the slightly different shade of gray from the other windows. That’s worked out really well for me and I’ve never looked back.

Now Ray Zeitler over at Ray on Emacs takes another look at the problem and found a really nice solution. It’s a bit more in your face than mine so if you’re looking for something that makes the active window really stand out, you should take a look at his post. The TL;DR is that instead of changing the active window, he changes the background color of all the other windows.

Zeitler found his solution on a 10 year old Stack Exchange post so it’s pretty certain to work no matter what version of Emacs you’re using. The code is very simple and you can simply copy it to your init.el if you’re interested.

As I said, this solution seems a little aggressive to me so I doubt I’ll be implementing it but others may disagree. One thing for sure, it’s going to make your active window stand out. It’s a small enough change that you can try it out—say by copying it to your scratch buffer and executing it—to see if it’s something you’d like.

Now you can use emacs.news to get to Emacs News. That should save some clicking/typing. It redirects to my blog category at the moment, so the URL doesn't show emacs.news after you get there, but I've added it to the note at the top of that category page to help people find out about the shortcut.

Thanks to @xenodium for the nudge!

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

I stumbled across Andros Fenollosa's blog a while ago while thinking about doing more of my web browsing with EWW. He has written a post where he defines a standard for websites that read in the terminal he calls Termweb. It's well thought through and makes a lot of sense.

Eww isn't always a terminal browser, although it can be very useful in a TTY on a server to read up on the documentation while also using Emacs as a terminal multiplexer with config files you edit in another window and eshell, shell or ansi-term in a third window within the TTY. When I am in a graphical Wayland seesion, I use EWW in a GUI Emacsclient frame which means I can get different fonts and pictures as well as just text which you would get in EWW in Emacs in a terminal. (Of course, Lynx can show pictures in a graphical terminal as well through sixel and it is probably possible to hack EWW to use sixel like Lynx or use the abilities of newer terminals like Alacritty and Kitty to show pictures, but GUI Emacs has a few advantages more around keybindings, toolbars and the modeline as well as just pictures and fonts which is why most people prefer it when in a graphical session over terminal Emacs.)

I use the Emacs package org-static-blog to make my blog from org files. I also made a function to push changes to Codeberg pages via git. Org-static-blog already follows most of Fenollosa's advice. I additionally made a CSS stylesheet for graphical browsers when I started using it. I set a dark background, text that would contrast, and a few settings for the heading, footer and code blocks to stand out while still staying within a mostly monochromatic look. I think a coherent style, ie less CSS applied to more tags, IDs and classes, is better than tweaking everything individually.

Org-static-blog already makes HTML that renders well in a text-based browser and I chose to have my header on top, not on the side, when I made the CSS to make it look as similar as possible in a text-based browser as it looks in a graphical browser. Today I had a look at it again in EWW and I realised that the header and footer (or preamble and postamble as org-static-blog calls it) blends to much into the rest of the content of the page when read in a text based browser, so I added a horizontal line after the header and before the footer to separate it out. It looks good in EWW, but a bit unnecessary in a graphical browser. The obvious solution was to tweak the CSS to not show hr-tags inside the preamble and postamble. Then the header and footer look like they used to on graphical browsers, but they look better than before on text based browsers. After looking further at the header and footer, I felt that it did actually look quite stylish with the hr visible in my graphical browser as well, so I removed the extra CSS to remove it again.

My goal isn't to make my blog look good in text based browsers or graphical browsers, but both. Using a simple structure and following most of the rules by Andros Fenollosa helps to achieve both goals at once. If you have not had a look at your own site in EWW or Lynx and you have a bit of time to tweak some HTML or CSS, I recommend reading Fenollosa's post and have a go at tweaking things to follow most of his advice. Every reader you have that use EWW or a terminal text browser will thank you for making your site more readable.

This is my contribution to the October 2026 edition of the Emacs Blog Carnival. The theme is “Where and how will you be using emacs in the next year, two years, five years?”.

To step back and siuatate what we are talking about: Last year, I described Emacs as an Emancipatory Computing System: Emacs is a (1) uniform UI, (2) a transparent+accessible program and (3) a collaborative “community”. For me, these three attributes constitute the attractive and worthwhile aspects of Emacs. The fact that we got here is not a natural consequence of technical decisions. In fact, I’d argue that left to anarchy, Emacs would naturally devolve, but it is only due to the concious and intelligent mantainance of the core that the entropy of a system like Emacs can be counterbalanced.

Presently, I can see all these points being under threat in the coming years:

1. The uniform UI, meaning text-based UI that can be navigated and manupulated with the same commands, or at least custom commands that ensure intuitive consistency (i.e. C-k might not kill a physical line in a special-mode-derived buffer, but k still “kills” a logical entry) has been suffering for the past few years with custom UIs like transient and I remain weary of what the new Canvas functionality in the upcoming Emacs 32 release will spur people to implement. With the exception of edge-cases like games (which just like with the built-in games in Emacs are more demonstrations than actual features) all feature that were to use a Canvas image for user input will have to re-implement navigation and input in a intuitive way while dealing with the issue that “inuitive” means different thing to differnt people, depending on what subset of navigation and manipulation keybindings you are used to.

2. The transparency of Emacs has also been strained in the past few years: Initiatives such as Tree-Sitter in the core make it more difficult to make quick-paced changes to a language (which is the price you pay for improved and faster parsing) and even if you do change and re-build the grammar it is to my knowledge not possible to hot-swap a grammar without restarting the Emacs process since the grammar is packaged as shared objects.

   Outside of the core there are some projects that again that also try to speed up Emacs by implementing functionality outside of Emacs. One such example is lsp-bridge or Emacs application framework where the main logic of the program is written in a seperate Python programs.

   Of course it has always been the case that Emacs, as a kind of shell, integrated the surrounding system and invites the user to invoke shell commands both to interface with the outside system but also to manipulate the data within Emacs. I’d argue the difference with the previous examples is that we are not talking about already-existing generic and abstract tooling of our system like tr or make, but bespoke software that morally constitutes the same program but doesn’t enjoy the transparancy of both reading and changing the source code of the program as is the case with a traditional Elisp script.

3. Regarding collaborative community, it is worth pointing out that this is not necessarily just the online community consisnting mostly of a few dozen to perhaps a few hundred people. It might as well be a network of friends or colleges where knowledge and worked is shared. In fact I have more hope for the latter, as the former is strained both by the conflict of pro-LLM vs anti-LLM people (leaving many by the wayside) but also the annoyance of figures in the public space that are clearly motivated by the need to constantly self-advertise.

   Specifically regarding LLMs, I think it is conservative to say that while LLMs can deal with the works on humans, it feels off for humans to deal with the output of an LLM. Their priorities, style and attention is plainly atypical for humans as at least currently it seems they share less of a need for abstraction and conciseness (which makes sense to me, as the current economic model of AI services is to sell tokens). This is all fine for a no-coder who generates scripts to implement features they desire, but for shared code where you cannot expect that no human won’t want to read and modify it themselves it becomes tricky – one option is not to care, but not caring about others is the detriment of a community.

So as for myself, and my relation to Emacs, it is of course difficult for me to imagine computing without it. In fact I get annoyed by a lot of other software, especially web services and mobile applications, due to my expectations. At the same time, I am aware that the compfort of Emacs has held me back from trying out software that lacked good support within Emacs — on some level I would be better off ignorant. Especially nowadays I find it more difficult than ever to predict the future of computing. I can anticipate that at my day-job (context: I am a PhD student in PL research working with Rocq) I will be continuting to use Emacs along with Proof General for the forseable future. But on a much larger and high-level scheme, the question of how we use computers in general and what role traditioanl software will play remains open to me.

(As an aside: The (software) complexity crisis has been worsening outside of specific, mostly autarchic circles (Emacs, while not immute, is has arguably stood it’s ground better) and the solution has never been to write more code faster — but let us also not forget that specifically with the LLM situation, code generation isn’t and shouldn’t be the end-game, instead I still belive that it is a marketing approach to sell the usage of generative AI in situation that can be well trained, so as to fund the continuted research and development — while also making a lot of money (the two are the cynical flipsides of each-other). Nevertheless I am entierly willing to concede that we might be dealing with a non-backwards compatible paradigm shift on how we compute, and that if we overcome the “LLM-generating-code” phase we could live in a future where the CPU becomes the co-processor to a LLM-centric user interface where something like Emacs wouldn’t be relevant anymore.)

If a space will continue to exist where something like Emacs is an adequate and useful tool to interface with computers, I am confinent that Emacs will continue to exist. But beyond that I hope that as both local communities and the global community we can come together in a shared understanding of what it is that we value and ensure that we do not undermine it or better yet forster them.

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

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

This is a spontaneous live stream. I plan to develop at least one new theme for my ‘ef-themes’ package which will be in the spirit of Halloween. Depending on my progress, I will do two themes, actually.

I will keep the chat open, in case there are any questions related to this or anything else—I always answer everything.

The ef-halloween-dark prototype

I made some more tweaks and published the dark theme. There is more to do, but this is a good start. The light theme needs more work. Maybe during another live stream.

commit 3a9898e23da62d14b57faeae1af9ae05bb3c59f3
Author: Protesilaos <info@protesilaos.com>
Date:   Sat Oct 31 21:07:01 2026 +0200

  Add PROTOTYPE of ef-halloween-dark
  
  I did most of this during the live stream earlier today:
  <https://protesilaos.com/codelog/2026-10-31-emacs-live-ef-themes-halloween/>.

 ef-halloween-dark-theme.el | 242 +++++++++++++++++++++++++++++++++++++++++++++
 ef-themes.el               |   1 +
 2 files changed, 243 insertions(+)

The ef-halloween-light prototype

And this is from the day after.

commit dd0c2ee019e79d5541e1a3e563cd27c8a744c1ae
Author: Protesilaos <info@protesilaos.com>
Date:   Sun Nov 1 07:51:01 2026 +0200

  Add ef-halloween-light PROTOTYPE

 contrasts.org               |  36 +++++++
 ef-halloween-light-theme.el | 242 ++++++++++++++++++++++++++++++++++++++++++++
 ef-themes.el                |   1 +
 3 files changed, 279 insertions(+)

About the ef-themes

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

Starting with version 2.0.0, the ef-themes are built on top of the modus-themes. This means that all customisation options of the Modus themes apply to the Ef themes. Same for all Modus commands that load a theme. Enable ef-themes-take-over-modus-themes-mode to set up this arrangement (or enable modus-themes-include-derivatives-mode instead to blend Ef and Modus into one collection).

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

🔷 Consider making a donation.

I designed the basis of this theme during a live stream earlier today: https://protesilaos.com/codelog/2026-10-31-emacs-live-ef-themes-halloween/. Then I followed it up with refinements to colour values and palette mappings. The light counterpart of this theme will be the subject of further development work, maybe tomorrow or next week.

When I include “light” or “dark” in the theme’s name, it means that I have envisaged it as part of a pair. Most themes are not designed as pairs though, as certain colours cannot work in both cases.

Always click to enlarge the image for best results.

UPDATE 2026-11-02 09:42 +0200: Added ef-halloween-light as well.

ef-halloween-dark

ef-halloween-light

Coming in version 2.3.0 (next stable release)

I may still tweak it further, but the character is already set. It captures the style I had in mind and I am happy with the result.

Remember that since version 2.0.0, the ef-themes are built on top of my modus-themes. This means that they are highly customisable, support a wide range of packages and face groups, and are extensively tested down to the finest details.

Enjoy!

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

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

🔷 Consider making a donation.

My Emacs printed this after starting:

Doom loaded 286 packages across 71 modules in 1.713s

Another machine running Arch, apparently less powerful, started Emacs in under a second. I wondered whether macOS was responsible.

I had no controlled comparison between the machines. Different builds, packages and caches could all matter. But I did have a configuration I could inspect, and it turned out to contain work I was asking Emacs to do before I needed it.

The startup investigation became part of a wider review of my Doom configuration. I keep its source in config.org; config.el is generated from it. Reading the prose beside each customization made the review more useful: I could compare what I said I wanted with what the installed code actually did.

The checks described below used Emacs 31.0.91. The source links point to the installed package revisions, rather than assuming a newer checkout would behave the same way.

What Doom’s startup message measures

The first useful finding was in Doom’s own reporting code. Its package count comes from this expression:

(- (length load-path) (length (get 'load-path 'initial-value)))

That counts added search-path entries. It does not mean that 286 packages had been fully loaded. The time is Doom’s doom-init-time, measured from Emacs’s before-init-time, rather than an external stopwatch covering the whole application launch. The implementation makes both definitions explicit.

All times below use Doom’s timer. Temporary graphical instances ran my configuration with instrumentation in a temporary directory; my main session stayed open. Four dedicated reference starts reported 1.489, 1.397, 1.303 and 1.264 seconds, in that order. Another start of the original configuration, recorded while setting up the functional check, reported 1.618 seconds. These repeats did not reproduce the initial 1.713-second observation; I did not establish why that launch was slower.

Native compilation was available. The recorded reference starts had no garbage collections during the measured interval, and zero recorded GC time. Doom already defers collection during interactive startup, so raising a GC threshold again would not address the work I was seeing.

To locate that work, I timed load, require and process calls in separate instrumented runs. Those timings add overhead, so I used them to identify candidates, keeping the simpler reference runs for the startup comparisons.

Loading before I needed it

One require stood out: claude-code-ide, the package connecting Claude Code to Emacs. One instrumented run attributed about 467 ms to it, including its dependencies.

The package entry point requires its MCP integration. Following that into the handlers reaches diagnostics, which in turn attempts to load Flycheck. My timings showed those loads happening during startup. The time attributed to claude-code-ide already included the nested work; adding each dependency’s time to it would count the same work more than once.

I wanted the integration available from my leader menu. I did not need it loaded while Emacs was opening an unrelated buffer.

The durable change was one line:

 (use-package! claude-code-ide
+  :defer t
   :init

With :defer t, use-package skips adding the package to its implicit :load list, so the declaration no longer requires it at startup. That does not, by itself, create a way to load it later. Here, all nine commands I had bound had autoloads, including the menu command. Calling one could load the library containing its definition. The :defer handler distinguishes this from a numeric :defer, which schedules a load after an idle delay.

I kept the keybindings and my Ghostel backend selection in :init. They need to exist before the package loads. The call to claude-code-ide-emacs-tools-setup stayed in :config, to register the Emacs tools after loading.

That arrangement needed checking in a fresh instance. A package already loaded in my main session could hide a missing autoload. The check confirmed that the library was absent at startup, all nine bindings were available, and invoking the menu loaded the package. The Emacs MCP tools were registered and the backend was still Ghostel. This did not exercise a complete conversation with the Claude CLI.

The startup measurements were encouraging:

The menu probes failed their functional assertions while the check was being developed. Their startup times still belong in the record: doom-init-time was set before those assertions ran. The later successful check establishes the behavior described above; a short startup time on its own would not establish that the integration still worked.

These are local observations from the review on 30 October 2026, with a small number of trials and no controlled cold-cache protocol. The table is not a promise that this edit always saves the difference between the fastest and slowest entries. It was enough evidence to keep the change, alongside the functional check.

The cost has also moved: the first use of the integration now has loading work to do. I did not measure that first-use latency separately.

Mise was another visible source of startup work, with 16 to 23 synchronous calls in the instrumented runs. Disabling it on its own produced one measurement of 1.267 seconds, within the dedicated reference range. Combining that with deferred Claude loading produced 0.781 seconds, also within the range reached by the deferral alone. Neither single trial established a repeatable benefit from disabling mise. I kept it enabled; only Claude’s loading was durably deferred in this startup experiment.

My configuration could now start in under a second on this Mac. That answered the practical question that sent me looking, even though the comparison with Arch remained uncontrolled.

The mode my hooks were missing

Startup had an obvious number attached to it. Some other customizations needed a different check: opening the kind of buffer I actually use.

In 2020, I wrote about binding M-RET to insert an Elixir pipe. I still want that shortcut. The function moves to the end of the line, inserts a new line and adds |> . But my customization targeted elixir-mode, while my enabled Doom module also uses elixir-ts-mode.

The current hook covers both:

(add-hook! '(elixir-mode-hook elixir-ts-mode-hook)
  (local-set-key
   (kbd "M-RET")
   #'bounga/insert-elixir-pipe-operator))

I checked it in an Elixir Tree-sitter buffer by invoking the binding: foo became foo followed by a newline and |> . The Elixir docset was also available there. On the Ruby side, checks in both ruby-mode and ruby-ts-mode confirmed the Ruby/Rails docsets and subword-mode; M-f stopped after My in MyLongClass.

Finding the hook names in the file would not have told me that. The customization can look perfectly familiar while missing the buffer where I expect to use it.

I also removed an explicit elixir-format hook before saving. My Doom configuration enables (format +onsave +lsp). The installed format module enables Apheleia on first-file use, and Apheleia maps both Elixir modes to mix-format, with Doom also supporting formatting through an available LSP formatter. The old hook was a separate formatting path that I no longer needed.

In an isolated directory with Elixir 1.20.2 and OTP 29, saving a buffer containing foo( 1,2 ) through Apheleia produced foo(1, 2) in both modes, in the buffer and on disk. No LSP server was involved, so this exercised Apheleia’s mix-format path.

A smaller naming error showed the same need to inspect the actual integration. I had written after! tramp-mode. Doom’s after! waits for a feature to load; the relevant feature is tramp. Changing it to after! tramp made the remote-path customization run in the targeted check. A familiar mode name was the wrong name for that job.

Letting an explicit mail choice stand

The mail changes deserve more care because I had already published my automatic signing and encryption setup. That article described the policy I wanted, but the implementation needed correction.

The old send hook chose between signing and signing plus encryption without first checking for an existing MML security instruction. It could replace a choice I had made explicitly while composing the message.

The current policy is:

The hook now looks for an existing secure tag in the message body before applying its default. Tests reproduce the earlier replacement of explicit signing, encryption and combined instructions, then confirm that the new hook preserves each one.

Reading Emacs’s own message helpers exposed another duplication. The body of my recipient parser matched message-all-recipients. My availability predicate followed the built-in message-all-epg-keys-available-p, including its epg-list-keys check. Giving those functions my own namespace had not given me different behavior.

Emacs also provides message-sign-encrypt-if-all-keys-available, but it does nothing when the key check fails. My policy includes signing in that case. I kept my own hook for that fallback and for preserving an explicit choice, replaced the parser with message-all-recipients, and switched the key check to mml-secure-find-usable-keys for encryption.

Having a key in a search result is insufficient. The MML implementation checks the relevant user ID and encryption capability, excluding expired or revoked candidates and disabled keys. An empty recipient list now fails my predicate as well.

This still does not establish that a key belongs to the person I mean, or replace the trust policy used when encrypting. Availability, usability and trust are separate questions. The hook requests an action; it cannot guarantee that signing or encryption will succeed when the message is sent.

The checks used simulated keys, covering To, Cc and Bcc, missing keys and unusable candidates. Across the two targeted suites, ten of fifteen tests failed against the earlier functions; all fifteen passed against the current definitions extracted from config.org. No real keyring was read and no mail was sent. The suites test the decisions in my code; they do not exercise an end-to-end encrypted exchange.

Deciding when to stop

The terminal setting needed no replacement. I removed the old vterm-shell assignment after moving to Ghostel. I did not replace it with an explicit ghostel-shell: its default reads SHELL, with /bin/sh as a fallback, and selects the shell I want.

I also made the fullscreen request explicit with fullboth instead of toggling it. I had not reproduced a fullscreen failure; the edit made the requested state explicit. It would be misleading to count it alongside the mail bug as one more thing that had been broken.

The distinction matters to how I read the resulting diff. Some lines fix observed behavior. Others follow a change in what I run, such as replacing vterm with Ghostel, or state a preference more clearly. Doom was doing useful work, including deferring GC and arranging formatting, that I needed to understand before adding more.

I can explain why Claude waits until first use, and I have checks for the editing and mail behavior I mean to keep. Those checks are what I want to rerun when the next package update makes a familiar customization worth revisiting.

When I'm "on the road," Vakana¹ becomes my human interface to Emacs.

I use Vakana because its presence on my Android device affords me these three conveniences:

• Portability
• Speech recognition
• Export options that include:
  • Org
  • Markdown
  • HTML
  • PDF
  • Slides

My computer is portable, and it does have a microphone. But its ability to recognize speech is poor despite multiple training sessions.² As a workaround, I'd dictate an email message on my cellphone, save it as a draft, and then access it from my computer.

As speech interfaces, my Android email clients are clunky. But the real issue with them is that they distract me with unread messages. It's like working in the office on a Monday morning where chatty coworkers talk about how well their team played, or the latest attempt at a ceasefire, or the ever-increasing price of … everything. I needed a tool devoted to ideation. So I tried Vakana.

After a one-time setup with a "blog notes" thread, I simply create a new note and start dictating right away. It's like working late on a Friday evening with only unobtrusive air handlers as coworkers.

Dictation isn't perfect -- I resist the urge to edit except in cases where I misspeak and want to choose a different word or phrase. I focus primarily on capturing ideas; creating content is secondary.

When I'm ready, I'll export either to HTML or Org. Either way, all the thread's notes are combined into a single file. The HTML export produces a single HTML file with bead images included with an SVG tag. The Org export creates a ZIP file with several Org files, one for each note, plus SVG files. Then I'll attach the file to an email message, which I save as draft and open on my computer.

With the exception of Org export, this has nothing to do with Emacs.

When I wonder how I might operate Emacs with voice, I vaguely envision "voice-bindings" -- a software layer that converts a spoken command such as "Visit File" into its associated function. The subsequent input at the Find file prompt would be managed with a voice-controlled dired package, perhaps called diredv. And, by-the-way, it doesn't need to be a monotonic voice; it can be a melody where pitch might fill in for the value of a prefix argument. Rhythm might denote yet another aspect of a command or input. I laugh when I think of what might happen to someone with hiccups.³

Pursuit of this is not on my agenda.

I imagine that evolution of enhanced Emacs input would be driven by our community's most brilliant contributors. I'm thinking of the ones who use elaborate hardware devices tailored to their anatomy and workflow. Their devices resemble split keyboards. Sometimes modifier keys are positioned under the thumbs to minimize pinkie strain. You might've seen examples if you read r/emacs.⁴ The evolution from that might be gloves used in conjunction with a virtual keyboard.

Personally, I distrust specialized hardware. I've had many peripherals become obsolete due to the lack of an OS-compatible driver. As well, I don't over-customize Emacs. I think it's important that I can use an Emacs -Q invocation if necessary.

I'm sure that the FOSS community would ensure that drivers for a specialized Emacs input device would be free, even if only as source code. However, the real impediment would be getting employers to allow such specialized and low-level code to be installed on their systems. And I can't imagine anyone investing in a solution that can't be used for most of the day.

¹ Learn about Vakana here.

² The speech recognition training probably requires a registered, logged in account, which I refuse to create.

³ This reminds me of the motion-activated radio on board the Heart of Gold. You don't need to get up to change the channels or mute it. On the other hand, you have to sit awfully still if you don't want to change it inadvertently. Obviously the engineer who came up with that idea wasn't too fond of dancing.

⁴ The Emacs subreddit can be found here: https://www.reddit.com/r/emacs/

• This is my contribution to the October 2026 Emacs Carnival.

• One might jokingly refer to "The Future of Human Interface for Emacs" with the acronym "FUHIE," self-deprecatingly pronounced "Phooey."

I like forums. Debates, questions, answers, opinions, etc. That feeling of an asynchronous community, where answers are thought through and content lasts, is what makes the internet an interesting place. That is why I like reading them and taking part in them. But I had never designed or built one. In my spare time I started sketching one, and I ended up building my humble headless, federated forum, with simple, modern technologies and open standards.

And I learned a lot along the way. A forum looks simple, but it hides the classic problems of any server. Who can do what? How do you tell a moderator from a regular user? What happens when you have to ban someone? How do you stop someone from stealing an account? Roles, permissions, bans and security. I had to solve them one by one, and you don't learn that by reading.

Let me tell you how I made Tyrtulia.

A forum with no interface

The server only offers a solid, documented API. It is REST with hypermedia: the client only knows one route, GET /, and discovers everything else by following links. Underneath there are some very boring standards:

• RFC 9110: HTTP semantics, with ETag and If-Match so edits don't overwrite each other.
• RFC 9457: errors.
• RFC 7396: partial updates with PATCH.
• RFC 6570: URL templates.
• RFC 4287: Atom feeds.
• RFC 9562: UUIDv7 identifiers.
• JSON Schema: validation.
• Server-Sent Events: real-time events.

There is no web interface, no forms, no advanced authentication systems, no file handling (images, attachments, etc.), and nothing that isn't strictly needed to read and write messages.

That is why it is so light. It uses between 60 and 70 MB of RAM and about 50 MB of disk. It only needs Python and SQLite to run.

An API that discovers itself

How does a client know what it can do? The server tells it with links. Look at the same request, GET /, made by a guest (simplified):

{
    "name": "Forum of example.org",
    "_links": {
        "self": {"href": "/", "method": "GET"},
        "latest": {"href": "/threads", "method": "GET"},
        "search": {"href": "/search{?q,author,in}", "method": "GET", "templated": true},
        "login": {"href": "/sessions", "method": "POST", "schema": "/schemas/session"}
    }
}

And now by alice, logged in:

{
    "name": "Forum of example.org",
    "_links": {
        "self": {"href": "/", "method": "GET"},
        "latest": {"href": "/threads", "method": "GET"},
        "search": {"href": "/search{?q,author,in}", "method": "GET", "templated": true},
        "createThread": {"href": "/threads", "method": "POST", "schema": "/schemas/thread"},
        "notifications": {"href": "/notifications", "method": "GET"},
        "events": {"href": "/events", "method": "GET", "type": "text/event-stream"}
    }
}

If I change a route tomorrow, no client breaks, because none of them knew it in advance. They just follow the links the server gives them.

Why not use one that already exists?

I know there are very complete free software forums:

• Discourse: the most popular one today.
• Flarum: PHP with MySQL.
• NodeBB: Node.js, with MongoDB, Redis or PostgreSQL. It stands out for real time with WebSockets.

Or the good old classic: phpBB.

They are all fantastic, but they are designed to be used from a web browser. They also have an ambitious scope. That is ideal for large communities, but too much for a small, light forum.

That said, Tyrtulia doesn't give up on the browser: it can be indexed by search engines and anyone can read it on the web.

No passwords

No OAuth, no OpenID, no sign-up forms. There are two ways to authenticate:

• Your Unix user: the client talks to the forum through a Unix socket. The operating system tells the forum which user is on the other side. No sign-up, no login. Your user is your account.
• SSH key: the client connects over HTTP and the forum sends it a challenge. The client signs it with your private SSH key and the forum verifies it with your public key.

There is no registration over HTTP. If you have a Unix user on the server, you already have an account: it is created the first time you connect through the socket. From there you can add your SSH keys to log in from outside. If you don't have a user on the machine, the administrator creates an account for you with your public key from the command line. On a tilde, having a Unix user is already the invitation.

Easy to use, secure, and no passwords to steal.

What changes compared to BBJ

The idea isn't mine. I was inspired by BBJ, a bulletin board for the terminal built for small communities or clubs (tildes, pubnixes, club servers, etc.). I took its spirit and brought it to my own ground. Still, there are important differences.

First, the foundations.

Then, the features I missed.

What they share is a small server built on SQLite and several text clients against a documented API.

Clients

A headless forum needs clients, no way around it.

Tyrtulia TUI

Tyrtulia TUI is the terminal client, built with Textual.

tyrtulia.el

If you know me a little, you know this package was a must: tyrtulia.el.

Tyrtulia Web

Tyrtulia Web is more a mirror of the content than a client. Its goal is to let search engines index the forum and let anyone read it from a browser.

It has an unstyled theme and another one that mimics my website.

Federation

You can connect to one forum or set up several. Federation happens in the clients: servers don't talk to each other or copy messages between them. Each forum is independent, with its own users, rules and moderators.

Instead of splitting them into tabs or accounts, the clients mix the threads of all of them into a single list.

Of course, you can only write in the forums where you have an account. In the rest you can only read.

I think it's a pretty cool feature, because it keeps the API code much simpler and lets you explore other forums at zero cost.

Try it

It has been fun to design and build. Of course there are more complete forums, more powerful federation systems, and even decentralized systems that leave Tyrtulia in the dust (Aether, Nostr...). But its niche is very specific: a light, closed-access, federated, indexable, secure forum with text clients. For everything else, there are better things out there.

If you feel like trying it, the installation guide is in the Tyrtulia repository.

I look forward to your feedback.

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-b5c8c6aa@andros.dev to leave a comment. The subject will be ignored.

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

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

This is a spontaneous live stream that will start in ~35 minutes. I am going to work on my denote package for Emacs. The plan is to review some functionality and improve certain edge cases where things can go wrong. This is the sort of work that improves the quality of a package: it does not introduce anything with a “wow” factor, but it contributes to a nicer day-to-day experience.

I will keep the chat open, in case there are any questions related to this or anything else—I always answer everything.

About Denote

Denote is a simple note-taking tool for Emacs. It is based on the idea that notes should follow a predictable and descriptive file-naming scheme. The file name must offer a clear indication of what the note is about, without reference to any other metadata. Denote basically streamlines the creation of such files while providing facilities to link between them.

Denote’s file-naming scheme is not limited to “notes”. It can be used for all types of file, including those that are not editable in Emacs, such as videos. Naming files in a consistent way makes their filtering and retrieval considerably easier. Denote provides relevant facilities to rename files, regardless of file type.

[ Further down on this list I include more of my Denote-related packages. ]

• Package name (GNU ELPA): denote
• Official manual: https://protesilaos.com/emacs/denote
• Change log: https://protesilaos.com/emacs/denote-changelog
• Git repositories:
  • GitHub: https://github.com/protesilaos/denote
  • GitLab: https://gitlab.com/protesilaos/denote
• Video demo: https://protesilaos.com/codelog/2022-06-18-denote-demo/
• Backronyms: Denote Everything Neatly; Omit The Excesses. Don’t Ever Note Only The Epiphenomenal.

🔷 Consider making a donation.

In https://emacs.stackexchange.com/a/36240/47342, CodyChan provides a few options "to better distinguish between focused window." But the one I like best is highlight-selected-window, which, rather than highlighting the selected window, changes the background color of all the unselected windows. The effect is that the active window stands out in comparison to the others.

The especially neat thing about this solution is that when the minibuffer is active, the background of all the windows is altered. So it's obvious even when Emacs is expecting input -- something I often miss.

I've changed the color of the buffer-face-set background from "#111" (sienna4) to "antiquewhite2" because I still need to read the content of inactive windows. The original color is too dark.

I've also adopted flash-active-buffer, which sets the background color of the active window temporarily. I changed the color to palegreen just because. I use s-? as a keybinding. It's a bit awkward, but it's as if I use "?" to ask, "Where am I?" The function highlight-selected-window works so well that I don't think I'll need flash-active-buffer.

The color names that Emacs understands are stored in color-name-rgb-alist.

See also https://www.color-hex.com/color-names.html, but note that Emacs does not support every color name listed here.