Cupcakes

Poetry (non-Emacs related)

Ever found yourself wanting to add a new AI provider to ollama-buddy? (probably not I would guess 🙂), only to realise you’d need to write an entire Elisp module? Or perhaps you’re running a local inference server that speaks the OpenAI API, but can’t be bothered with the ceremony of creating a dedicated provider file?

Fair question. That’s exactly why I built ollama-buddy-provider-create — a single function that lets you register any LLM provider in seconds, whether it’s a cloud API or your own local server.

The traditional approach required a separate .el file for each provider — OpenAI, Claude, Gemini, you name it. Each with its own defcustom variables, configuration boilerplate, and maintenance overhead. It worked, but it felt a bit… heavy-handed for simple use cases.

What if you just wanted to quickly add support for that new local LM Studio instance running on port 1234? Or point ollama-buddy at your company’s internal AI gateway? Previously, you’d be looking at copying an existing provider file and modifying dozens of lines. Now? One function call.

The magic (yes, of the elisp kind!) happens in ollama-buddy-provider.el, which provides a generic provider registration system. Instead of requiring separate Elisp files, you can register any provider with a single call:

(ollama-buddy-provider-create
 :name "My Local Server"
 :api-type 'openai
 :endpoint "http://localhost:1234/v1/chat"
 :models-endpoint "http://localhost:1234/v1/models"
 :api-key "your-key-here"
 :prefix "l:")

Three API types are supported out of the box:

• openai (default) — Any OpenAI-compatible chat/completions API
• claude — Anthropic Claude Messages API
• gemini — Google Gemini generateContent API

The system handles all the underlying HTTP requests, error mapping, and session management automatically. Your provider just needs to specify which API flavour it speaks.

Adding a local LM Studio instance:

(ollama-buddy-provider-create
 :name "LM Studio"
 :api-type 'openai
 :endpoint "http://localhost:1234/v1/chat/completions"
 :models-endpoint "http://localhost:1234/v1/models"
 :api-key "not-needed" ; LM Studio often doesn't require auth
 :model-prefix "l:")

Connecting to OpenRouter (400+ models through one API):

(ollama-buddy-provider-create
 :name "OpenRouter"
 :api-type 'openai
 :endpoint "https://openrouter.ai/api/v1/chat/completions"
 :models-endpoint "https://openrouter.ai/api/v1/models"
 :api-key "your-openrouter-key"
 :model-prefix "r:")

After registration, your new provider appears in the status line and becomes available through the standard model selection interface. The model-prefix (like l: for local or r: for OpenRouter) lets you quickly identify which provider a model belongs to.

The provider system leverages ollama-buddy’s shared infrastructure in ollama-buddy-remote.el, which extracts common functionality like request handling, error mapping, and response processing. This means your custom provider gets the same robust error handling as the built-in ones:

• Proper HTTP status code mapping (rate limits, timeouts, authentication errors)
• Async request support for non-blocking UI
• Automatic model listing and caching
• Integration with the existing session and conversation system

When you call ollama-buddy-provider-create, it registers your provider with the core system, making it available to all the usual entry points: the transient menu, model selection, and conversation buffers.

This approach is perfect for:

• Local inference servers (LM Studio, llama.cpp, vLLM, Ollama’s own OpenAI-compat layer)
• Company/internal AI gateways
• Quick experiments with new APIs

The beauty ojf this system is that it makes ollama-buddy genuinely extensible without requiring deep knowledge of its internals. Want to add support for that new AI service that launched yesterday? You can probably do it in five lines of configuration rather than fifty.

Next up I think this will be the big one, adding tooling for those external providers!!!

That didn’t take long. After yesterday’s post on adapting Bozhidar Batsov’s delete-surrounding-pair function to handle Org markup, Batsov is back with a post on surround.el, a port of surround.vim from Michael Kleehammer. The point of delete-surrounding-pair was to (sort of) emulate Vim’s surround plugin. Now with support.el, there’s no longer a need for delete-surrounding-pair.

Surround does everything delete-surrounding-pair did and a lot more. You can delete surrounding pairs, add pairs, change pairs, mark or kill the content between the pairs, or even kill the text and the surrounding pair. It really is a splendid package and I’ve already added it to my configuration and deleted my adaption of delete-surrounding-pair.

Surround will check if the pair you’re operating on has different opening and closing characters and do the right thing automatically. The other nice thing is that there aren’t a lot of key sequences to remember. Once you pick a prefix that you’ll remember the (single) action keys are mnemonic and easy to remember. In any event, which-key pops up a reminder.

I installed it with the recommended prefix of Meta+’ but keep wanting to invoke it with Hyper+’ so I’ll probably change it but, regardless, I’m already enjoying using it.

Take a look at Batsov’s post or the Github repository for all the details. Batsov’s post has some recommendations on when you should use it and Kleehammer’s repository has information on shortcuts and auto mode, which you should read. This is a really useful package and I recommend that everyone take a look at it.

A hands-on look at using acp2ollama to connect ACP agents to Emacs packages that speak the Ollama API — with results ranging from 'works great' to 'probably don't bother.'

The other day I wrote about Bozhidar Batsov’s post on deleting paired delimiters in Emacs and mentioned that he included a bit of Elisp that—sort of—duplicated the behavior of Vim’s surround.vim. The idea is that if you are in a delimited expression and invoke the function, it will ask what delimiter you want to delete and will delete the closest enclosing pair. That obviously has some shortcomings such as not recognizing if one of the delimiters is in, say, a string. Still it’s handy code that does the right thing in most cases.

The code was interesting but I thought I didn’t need it because delete-pair already handled all the cases I was concerned with. As I was writing about Batsov’s post, I had something like =some text= and realized that I didn’t want it displayed in monospace after all. Since delete-pair was on my mind, I tried it but of course it didn’t work because = isn’t a delimiter that delete-pair recognizes so I deleted them by hand.

Later, I realized that I could simply add the Org markup pairs I was interested in to Batsov’s code so I did that and added it to my init.el. It worked perfectly and now I have an easy way of deleting Org markup .

It’s worth noting that Org mode gives you a way to do the opposite too: if you highlight some text and call org-empasize (Ctrl+c Ctrl+x Ctrl+f) it will add the Org markup you choose to the highlighted text.

Note

After I wrote this post, I found out about surround.el. More about that tomorrow.

A small #Emacs #OrgMode quality-of-life tweak. I often need to replace an org heading's title while preserving the original text in the body. The problem is that pressing enter on a heading inserts a line above the properties drawer, which breaks things.

Here's a function that moves the heading title into the body (below the properties drawer and metadata), and binds it to S-RET:

(defun my-org-demote-title-to-body ()
  "Move the current heading's title into the body, below the metadata.
  Point returns to the heading for editing."
  (interactive)
  (org-back-to-heading t)
  (let* ((element (org-element-at-point))
         (title (org-element-property :raw-value element)))
    (org-edit-headline "")
    (save-excursion
      (org-end-of-meta-data t)
      (insert title "\n"))
    (org-beginning-of-line)))

(defun my-org-shift-return ()
  "On a heading, demote title to body. In a table, copy down."
  (interactive)
  (cond
   ((org-at-heading-p) (my-org-demote-title-to-body))
   ((org-at-table-p) (org-table-copy-down 1))
   (t (org-return))))
  (define-key org-mode-map (kbd "S-<return>") #'my-org-shift-return)

It’s been a while since the last super-save release. The last time I wrote about it was back in 2018, when I boldly proclaimed:

It seems that now super-save is beyond perfect, so don’t expect the next release any time soon!

Famous last words. There was a 0.4 release in 2023 (adding a predicate system, buffer exclusions, silent saving, and trailing whitespace cleanup), but I never got around to writing about it. The package has been rock solid for years and I just didn’t pay it much attention – it quietly did its job, which is kind of the whole point of an auto-save package.

A Bit of History

The idea behind super-save goes all the way back to a blog post I wrote in 2012 about auto-saving buffers on buffer and window switches. I had been using IntelliJ IDEA for Java development and loved that it would save your files automatically whenever the editor lost focus. No manual C-x C-s, no thinking about it. I wanted the same behavior in Emacs.

Back then, the implementation was crude – defadvice on switch-to-buffer, other-window, and the windmove commands. That code lived in Emacs Prelude for a few years before I extracted it into a standalone package in 2015. super-save was born.

What Prompted This Release

Yesterday I stumbled upon buffer-guardian.el, a package with very similar goals to super-save. Its README has a comparison with super-save that highlighted some valid points – mainly that super-save was still relying on advising specific commands for buffer-switch detection, while newer Emacs hooks like window-buffer-change-functions and window-selection-change-functions could do the job more reliably.

The thing is, those hooks didn’t exist when super-save was created, and I didn’t rush to adopt them while Emacs 27 was still new and I wanted to support older Emacsen. But it’s 2026 now – Emacs 27.1 is ancient history. Time to modernize!

What’s New in 0.5

This is the biggest super-save release in years! Here are the highlights:

Modern buffer/window switch detection

Buffer and window switches are now detected via window-buffer-change-functions and window-selection-change-functions, controlled by the new super-save-when-buffer-switched option (enabled by default). This catches all buffer switches – keyboard commands, mouse clicks, custom functions – unlike the old approach of advising individual (yet central) commands.

Modern focus handling

Frame focus loss is now detected via after-focus-change-function instead of the obsolete focus-out-hook, controlled by super-save-when-focus-lost (also enabled by default).

Soft-deprecated trigger system

With the new hooks in place, both super-save-triggers and super-save-hook-triggers now default to nil. You can still use them for edge cases, but for the vast majority of users, the built-in hooks cover everything.

org-src and edit-indirect support

super-save now knows how to save org-src edit buffers (via org-edit-src-save) and edit-indirect buffers (via edit-indirect--commit). Both are enabled by default and controlled by super-save-handle-org-src and super-save-handle-edit-indirect.

Safer predicates

Two new default predicates prevent data loss: verify-visited-file-modtime avoids overwriting files modified outside Emacs, and a directory existence check prevents errors when a file’s parent directory has been removed. Predicate evaluation is also wrapped in condition-case now, so a broken custom predicate logs a warning instead of silently disabling all auto-saving.

Emacs 27.1 required

This allowed cleaning up the code and relying on modern APIs.

Upgrading

For most users, upgrading is seamless – the new defaults just work. If you had a custom super-save-triggers list for buffer-switching commands, you can probably remove it entirely:

;; Before: manually listing every command that switches buffers
(setq super-save-triggers
      '(switch-to-buffer other-window windmove-up windmove-down
        windmove-left windmove-right next-buffer previous-buffer))

;; After: the window-system hooks catch all of these automatically
;; Just delete the above and use the defaults!

If you need to add triggers for commands that don’t involve a buffer switch (like ace-window), super-save-triggers is still available for that.

A clean 0.5 setup looks something like this:

(use-package super-save
  :ensure t
  :config
  ;; Save buffers automatically when Emacs is idle
  (setq super-save-auto-save-when-idle t)
  ;; Don't display "Wrote file..." messages in the echo area
  (setq super-save-silent t)
  ;; Disable the built-in auto-save (backup files) since super-save handles it
  (setq auto-save-default nil)
  (super-save-mode +1))

It’s also worth noting that Emacs 26.1 introduced auto-save-visited-mode, which saves file-visiting buffers to their actual files after an idle delay. This overlaps with super-save-auto-save-when-idle, so if you prefer using the built-in for idle saves, you can combine the two:

(use-package super-save
  :ensure t
  :config
  ;; Don't display "Wrote file..." messages in the echo area
  (setq super-save-silent t)
  ;; Disable the built-in auto-save (backup files)
  (setq auto-save-default nil)
  (super-save-mode +1))

;; Let the built-in auto-save-visited-mode handle idle saves
(auto-save-visited-mode +1)

Burst-Driven Development Strikes Again

Most of my Emacs packages are a fine example of what I like to call burst-driven development – long periods of stability punctuated by short intense bursts of activity. I hadn’t touched super-save in years, then spent a few hours modernizing the internals, adding a test suite, improving the documentation, and cutting a release. It was fun to revisit the package after all this time and bring it up to 2026 standards.

If you’ve been using super-save, update to 0.5 and enjoy the improvements. If you haven’t tried it yet – give it a shot. Your poor fingers might thanks for you this, as pressing C-x C-s non-stop is hard work!

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

Everyone knows I love finding whatever Emacs tricks and dodges I can to help writers. I wrote an article a while back about the benefits of writing in one-sentence-per-line (OSPL) style. No need to re-hash the whole article, but suffice to say this style can help you organize and transpose sentences, get a quick visual cue for sentence length and complexity, as well as clearer version control diffs, etc.

Transitioning over to this style from the standard paragraph-per-line style can be a little disorienting at first, especially if your longer soft-wrapped sentences are starting to ramble into two or three lines. This where hl-line-mode in Emacs can be a big help. Most text editors have a highlighting feature to help you focus on the current working line, and Emacs is no different. In this article, we’ll take a look at the built-in highlighting mode in Emacs and all the hows and whys you need to know.

Before we get into it, I will mention that if you are a power writer, and want to join the elite of Emacs users, you should check out my downloadable DRM-free eBooks here:

• Emacs For Writers
• Git For Writers

Let’s dig into hl-line-mode now.

(global-hl-line-mode 1)

M-x global-hl-line-mode

The post Writing gloriously long sentences in Emacs with line highlighting appeared first on Chris Maiorana.

Today, I was going to work on a python project for half an hour at the end of my work day. I tried to find a good python module to use to work with RSS and Atom feeds. I found one and installed it in my virtual environment and pasted in some example code in a buffer in Emacs. I wanted to run the code in the python shell with Emacs' handy C-c C-c keyboard shortcut. So I opened the shell with C-c C-p and then hit C-c C-c, but I got an error that the shell did not understand the import on line 1 where I was importing the module I just installed in my virtualenv. I realised the shell ran from outside the virtualenv. I had not looked into this before, but found there were various packages people recommended to fix this. I tried one that looked interesting, but it did not work. Maybe because I was on my work laptop with Windows at the time. I tried a few things, but soon gave up.

I then discovered .dir-locals.el was a possible solution. It gives buffer-local values to variables inside the folder it is placed for the mode that you configure through an alist. The first suggestion I found was to use a variable that did not work at all. I wasted a lot of time trying to get it to work. When I was close to giving up, I discovered that I could use the usual python-shell-interpreter variable in the .dir-locals.el file and it worked. I then thought that the solution I had found would not work on my own machines that run GNU/Linux since the python.exe-file neither exists nor the folder it is in in virtual environments on my preferred platform. A .dir-locals.el-file checked in with git is not a particularly cross-platform solution. I thought I could make a function in my config that would check which platform I was on, whether I was in a project or not and whether a directory with the name venv exists (I tend to use that name) and then just set the variable to the correct path based on that.

When I got home, after dinner, I made that function. I love how well-documented Emacs is. It makes doing things like this really easy. I just looked up function names starting with project and found something useful after reading up on a few. A bit of evaluation in different buffers with C-x C-e to check if things worked the way I thought and a bit of tweaking when it turned out that cddr did not return the same as nth 2 (cddr returned a list with a string, but nth 2 returned a string) and then I ended up with this function:

(defun emo-python-virtualenv ()
  "Sets the python interpreter to python in the venv if in a project and a venv exists."
  (when (project-current)
    (let ((pythonpath (concat
                       (nth 2 (project-current)) (if (eq system-type 'gnu/linux)
                                                     "venv/bin/python"
                                                   "venv/Scripts/python.exe"))))
      (when (file-exists-p pythonpath)
        (setq-local python-shell-interpreter pythonpath)))))

To put it to work every time I open a python file, I also needed to add it to python-mode-hook like this in my configuration for Python mode:

(add-hook 'python-mode-hook 'emo-python-virtualenv)

When I now try to import packages that only exists in a venv into the python shell, it works if I loaded the shell from a file within the same project as the venv with the package, but not from a file from outside that project. If I load the shell from a file within a project without a venv, I get the system's Python and its available packages. No need for outdated packages that doesn't work or directory-local variables that are platform dependent. This should work on Windows as well. (I haven't tested it yet, but I will tomorrow.) It's easy and fun to fix things like this in Emacs, and I learned some Elisp and a bit about Python virtual environments in the process. It would be convenient if things like these worked out of the box, but that would demand a bit more code since my function works on the basis of me using the name venv for every venv which other people might not.

A recurrent theme here at Irreal is that Emacs is for everyone, not just programmers. Every time I find an example of this I try to write about it. It’s a point that Protesilaos Stavrou made in his recent FOSS @ Oxford talk.

Now, in a lovely piece of serendipity, we have Randy Ridenour providing a real world example. Ridenour is a Philosophy professor and, as he himself says, is by no means a programmer. Still, as Prot suggested, he has learned enough to automate some of his Emacs tasks. He started by copying other people’s code but tried to understand what it did.

Now he needs to convert quiz questions from one format to another for the learning management system that his university uses—see his post for the details. This amounts to running a series of regular expression replacements, which he did by hand for a while. Then he realized—as I always find myself doing—that he could just write a bit of Elisp to automate the process.

Ridenour isn’t a programmer and he isn’t a young turk who grew up with all this technology. He’s old enough to have a married daughter so while he may or may not qualify for the Irreal Geezer Club, he is obviously well along in his career. And yet he finds it easy to learn enough Elisp to reduce the friction in his workflow. His colleagues are probably still grumbling about how hard it is to deal with the quizzes but he’s turned all those problems over to Emacs.

If you maintain a tree-sitter major mode that has a REPL (comint) companion, you’ve probably wondered: can the REPL input get the same syntax highlighting and indentation as source buffers? The answer is yes – and the infrastructure has been in Emacs since 29.1. It’s just not widely known yet.

I ran into this while working on neocaml, my tree-sitter major mode for OCaml. The OCaml REPL buffer used simple regex-based font-lock-keywords for input, which was definitely a step backward from the rich highlighting in source buffers.

Initially I didn’t even bother to research using tree-sitter font-lock in comint, as assumed that would be something quite complicated. Turns out the fix was surprisingly easy.

Font-Lock: comint-fontify-input-mode

Emacs 29.1 introduced comint-fontify-input-mode, a minor mode that fontifies input regions in comint buffers through an indirect buffer. The idea is simple:

1. You tell comint which major mode to use for input via comint-indirect-setup-function.
2. Comint creates an indirect buffer and runs that mode in it.
3. When fontifying, comint splits the buffer into output and input regions. Output gets the comint buffer’s own font-lock; input is fontified in the indirect buffer using the full major mode – including tree-sitter.

Here’s all it took for neocaml’s REPL:

(define-derived-mode neocaml-repl-mode comint-mode "OCaml-REPL"
  ;; ... existing setup ...

  ;; Tree-sitter fontification for REPL input
  (setq-local comint-indirect-setup-function #'neocaml-mode)
  (comint-fontify-input-mode))

That’s it. REPL input now gets the exact same tree-sitter font-lock as .ml buffers. The existing font-lock-keywords for output (error messages, warnings, val/type results) keep working as before – they only apply to output regions.

Important: comint-fontify-input-mode is incompatible with comint-use-prompt-regexp – the two features can’t be active at the same time. Most modern comint-derived modes don’t set comint-use-prompt-regexp to t, so this usually isn’t an issue.

Who’s Already Doing This

Two built-in modes use this approach:

• shell.el sets up sh-mode in the indirect buffer (enabled by default via shell-fontify-input-enable)
• ielm.el sets up emacs-lisp-mode (enabled by default via ielm-fontify-input-enable)

On the third-party side, inf-lua and ts-repl both use this pattern with tree-sitter modes. And now there’s also neocaml, of course. :-)

Indentation: comint-indent-input-line-default

Comint also provides indentation delegation via comint-indent-input-line-default and comint-indent-input-region-default. When you set these as indent-line-function and indent-region-function, pressing TAB on an input line delegates indentation to the indirect buffer’s indent-line-function – which will be treesit-indent if the indirect buffer runs a tree-sitter mode.

(setq-local indent-line-function #'comint-indent-input-line-default)
(setq-local indent-region-function #'comint-indent-input-region-default)

shell.el already does this. For your own REPL modes, you can add these two lines alongside the font-lock setup.

The Caveat

Here’s where things get tricky. Tree-sitter parsers are shared between indirect and base buffers (this is by design – see bug#59693). When treesit-indent runs in the indirect buffer, the parser it uses sees the entire comint buffer – prompts, output, previous commands, everything. The parse tree will be full of errors from non-code content.

Font-lock handles this gracefully because comint-fontify-input-mode only applies fontification results to input regions, so garbled parses of output regions are harmless. But indentation is different – treesit-indent looks at the node context around point, and a broken parse tree can confuse it.

In practice, it works better than you’d expect.¹ For simple multi-line expressions, the local tree-sitter nodes at the cursor position are often correct enough for reasonable indentation. But for deeply nested multi-line input, the results can be off.

Because of this, I chose not to enable indentation delegation by default in neocaml’s REPL. Instead, it’s documented as an opt-in configuration for adventurous users.

The Recipe

If you maintain a tree-sitter mode with a comint REPL, here’s the minimal pattern:

(define-derived-mode my-repl-mode comint-mode "My-REPL"
  ;; ... your existing setup ...

  ;; Font-lock: full tree-sitter highlighting for input
  (setq-local comint-indirect-setup-function #'my-ts-mode)
  (comint-fontify-input-mode)

  ;; Indentation: delegate to tree-sitter (experimental)
  (setq-local indent-line-function #'comint-indent-input-line-default)
  (setq-local indent-region-function #'comint-indent-input-region-default))

Consider making these features opt-in via defcustoms, especially the indentation part. And remember that your existing font-lock-keywords for output highlighting (errors, warnings, result values) will continue working – they don’t conflict with comint-fontify-input-mode.

The End

That’s it. Two overlooked comint features, a few lines of setup, and your REPL goes from basic regex highlighting to full tree-sitter support.

Keep hacking!

In my recent article on removing paired delimiters, I mentioned that I kind of miss Vim’s surround.vim experience in Emacs. Well, it turns out someone has done something about it – surround.el brings the core ideas of surround.vim to native Emacs, without requiring Evil mode.

surround.vim (and similar plugins like mini.surround in Neovim) are some of my favorite Vim packages. The idea is so simple and so useful that it feels like it should be a built-in. So I’m happy to see someone took the time to port that beautiful idea to Emacs.

The Core Ideas of surround.vim

For those who haven’t used surround.vim, the concept is straightforward. You have a small set of operations for working with surrounding characters – the delimiters that wrap some piece of text:

• Delete surrounding pair: ds( removes the parentheses around point
• Change surrounding pair: cs(" changes parens to quotes
• Add surrounding pair: ys + motion + character wraps text with a delimiter

That’s basically it. Three operations, consistent keybindings, works everywhere regardless of file type. The beauty is in the uniformity – you don’t need different commands for different delimiters, and you don’t need to think about which mode you’re in.

surround.el in Practice

surround.el is available on MELPA and the setup is minimal:

(use-package surround
  :ensure t
  :bind-keymap ("M-'" . surround-keymap))

You bind a single keystroke (M-' in this example) to surround-keymap, and that gives you access to all the operations through a second keystroke. Here are the commands available in the keymap:

There are also shortcuts for individual characters – pressing an opening delimiter (like () after the prefix does a mark-inner, while pressing the closing delimiter (like )) does a mark-outer.

A Short Walkthrough

Let’s see how this works in practice. Starting with the word Hello (with point somewhere on it):

Surround – M-' s " wraps the symbol at point with quotes:

Hello  →  "Hello"

Change – M-' c " ( changes the surrounding quotes to parens:

"Hello"  →  (Hello)

Mark inner – M-' i ( selects just the text inside the parens:

(|Hello|)    ;; "Hello" is selected

Mark outer – M-' o ( (or M-' )) selects the parens too:

|( Hello)|   ;; "(Hello)" is selected

Delete – M-' d ( removes the surrounding parens:

(Hello)  →  Hello

Kill – M-' k ( kills the text inside the pair (leaving the delimiters gone too), while M-' K ( kills everything including the delimiters.

Inner vs. Outer

Like surround.vim, surround.el distinguishes between “inner” (just the content between delimiters) and “outer” (content plus the delimiters themselves). The i and k commands operate on inner text, o and K on outer.

There’s also an “auto” mode – the default for i and k – that behaves as inner when you type an opening character and outer when you type a closing character. So M-' ( marks inner, M-' ) marks outer. Handy shortcut if your fingers remember it (I’m still building the muscle memory).

One caveat: auto mode can’t distinguish inner from outer for symmetric pairs like quotes (", '), since the opening and closing character are the same. In those cases it defaults to inner.

How It Differs from Vim

The biggest difference is in how you surround text. In Vim, surround.vim uses motions – ysiw( means “surround inner word with parens.” In Emacs, surround.el operates on the active region or the symbol at point. So the typical workflow is: select something, then M-' s (.

This actually pairs beautifully with expreg (which I wrote about recently). Use expreg to incrementally select exactly the text you want, then M-' s to wrap it. It’s a different rhythm than Vim’s motion-based approach, but once you get used to it, it feels natural.

The other operations (d, c, k, i, o) work similarly to their Vim counterparts – you invoke the command and then specify which delimiter you’re targeting.

When to Use It

surround.el fills a specific niche:

• Using electric-pair-mode? Then surround.el is an excellent complement. electric-pair-mode handles auto-pairing when you type delimiters, but offers nothing for removing, changing, or wrapping existing text with delimiters. surround.el fills exactly that gap.

• Using smartparens? You probably don’t need surround.el – smartparens already has sp-unwrap-sexp, sp-rewrap-sexp, and friends. The overlap is significant, and adding another package on top would just be confusing.

• Using paredit? Same story for Lisp code – paredit has you covered with paredit-splice-sexp, paredit-wrap-round, and so on. But if you want the surround experience in non-Lisp buffers, surround.el is a good pick.

My current setup is paredit for Lisps, electric-pair-mode for everything else, and I’m adding surround.el to complement the latter. Early days, but it feels right.

Wrapping Up

If you’ve ever wondered whether some Vim feature you miss exists in Emacs – the answer is always yes. It’s Emacs. Of course someone has written a package for it. Probably several, in fact… Admittedly, I discovered surround.el only when I had decided to port surround.vim to Emacs myself. :D

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

The buffer-guardian Emacs package provides buffer-guardian-mode, a global mode that automatically saves buffers without requiring manual intervention.

By default, buffer-guardian-mode saves file-visiting buffers when:

• Switching to another buffer.
• Switching to another window or frame.
• The window configuration changes (e.g., window splits).
• The minibuffer is opened.
• Emacs loses focus.

In addition to regular file-visiting buffers, buffer-guardian-mode also handles specialized editing buffers used for inline code blocks, such as org-src (for Org mode) and edit-indirect (commonly used for Markdown source code blocks). These temporary buffers are linked to an underlying parent buffer. Automatically saving them ensures that modifications made within these isolated code environments are correctly propagated back to the original Org or Markdown file.

If this package enhances your workflow, please show your support by starring buffer-guardian on GitHub to help more users discover its benefits.

Other features that are disabled by default:

• Save the buffer even if a window change results in the same buffer being selected. (Variable: buffer-guardian-save-on-same-buffer-window-change)
• Save all file-visiting buffers periodically at a specific interval. (Variable: buffer-guardian-save-all-buffers-interval)
• Save all file-visiting buffers after a period of user inactivity. (Variable: buffer-guardian-save-all-buffers-idle)
• Prevent auto-saving remote files. (Variable: buffer-guardian-inhibit-saving-remote-files)
• Prevent saving files that do not exist on disk. (Variable: buffer-guardian-inhibit-saving-nonexistent-files)
• Set a maximum buffer size limit for auto-saving. (Variable: buffer-guardian-max-buffer-size)
• Ignore buffers whose names match specific regular expressions. (Variable: buffer-guardian-exclude-regexps)
• Use custom predicate functions to determine if a buffer should be saved. (Variable: buffer-guardian-predicate-functions)

(Buffer Guardian runs in the background without interrupting the workflow. For example, the package safely aborts the auto-save process if the file is read-only, if the file’s parent directory does not exist, or if the file was modified externally. Additionally, it gracefully catches and logs errors if a third-party hook attempts to request user input, ensuring that the editor never freezes during an automatic background save.)

Installation

Installation from MELPA

To install buffer-guardian from MELPA:

1. If you haven’t already done so, add MELPA repository to your Emacs configuration.
2. Add the following code to your Emacs init file to install buffer-guardian from MELPA:

(use-package buffer-guardian
  :custom
  ;; When non-nil, include remote files in the auto-save process
  (buffer-guardian-inhibit-saving-remote-files t)

  ;; When non-nil, buffers visiting nonexistent files are not saved
  (buffer-guardian-inhibit-saving-nonexistent-files nil)

  ;; Save the buffer even if the window change results in the same buffer
  (buffer-guardian-save-on-same-buffer-window-change t)

  ;; Non-nil to enable verbose mode to log when a buffer is automatically saved
  (buffer-guardian-verbose nil)

  ;; Save all buffers after N seconds of user idle time. (Disabled by default)
  ;; (buffer-guardian-save-all-buffers-idle 30)

  :hook
  (after-init . buffer-guardian-mode))

Alternative installation: Doom Emacs

Here is how to install buffer-guardian on Doom Emacs:

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

(package! buffer-guardian
  :recipe
  (:host github :repo "jamescherti/buffer-guardian.el"))

1. Add to ~/.doom.d/config.el:

(after! buffer-guardian
  ;; When non-nil, include remote files in the auto-save process
  (setq buffer-guardian-inhibit-saving-remote-files t)

  ;; When non-nil, buffers visiting nonexistent files are not saved
  (setq buffer-guardian-inhibit-saving-nonexistent-files nil)

  ;; Save the buffer even if the window change results in the same buffer
  (setq buffer-guardian-save-on-same-buffer-window-change t)

  ;; Non-nil to enable verbose mode to log when a buffer is automatically saved
  (setq buffer-guardian-verbose nil)

  ;; Save all buffers after N seconds of user idle time. (Disabled by default)
  ;; (setq buffer-guardian-save-all-buffers-idle 30)

  (buffer-guardian-mode 1))

1. Run the doom sync command:

doom sync

Configuration

You can customize buffer-guardian to fit your workflow. Below are the main customization variables:

Triggers

• buffer-guardian-save-on-focus-loss (Default: t): Save when the Emacs frame loses focus.
• buffer-guardian-save-on-minibuffer-setup (Default: t): Save when the minibuffer opens.
• buffer-guardian-save-on-buffer-switch (Default: t): Save when window-buffer-change-functions runs.
• buffer-guardian-save-on-window-selection-change (Default: t): Save when window-selection-change-functions runs.
• buffer-guardian-save-on-window-configuration-change (Default: t): Save when window-configuration-change-hook runs.
• buffer-guardian-save-on-same-buffer-window-change (Default: nil): Save the buffer even if the window change results in the same buffer.

Timers

• buffer-guardian-save-all-buffers-interval (Default: nil): Save all buffers periodically every N seconds.
• buffer-guardian-save-all-buffers-idle (Default: nil): Save all buffers after N seconds of user idle time.

Exclusions and Filters

• buffer-guardian-inhibit-saving-remote-files (Default: t): Prevent auto-saving remote files.
• buffer-guardian-inhibit-saving-nonexistent-files (Default: t): Prevent saving files that do not exist on disk.
• buffer-guardian-exclude-regexps (Default: nil): A list of regular expressions for file names to ignore.
• buffer-guardian-max-buffer-size (Default: nil): Maximum buffer size (in characters) to save. Set to 0 or nil to disable.
• buffer-guardian-predicate-functions (Default: nil): List of predicate functions to determine if a buffer should be saved.

Specialized Buffers (Inline Code Blocks)

• buffer-guardian-handle-org-src (Default: t): Enable automatic saving for org-src buffers.
• buffer-guardian-handle-edit-indirect (Default: t): Enable automatic saving for edit-indirect buffers.

Advanced

• buffer-guardian-save-all-buffers-trigger-hooks: A list of hooks that trigger saving all modified buffers. Defaults to nil.
• buffer-guardian-save-trigger-functions: A list of functions to advise. A :before advice will save the current buffer before these functions execute.
• buffer-guardian-verbose (Default: nil): Enable logging messages when a buffer is saved.

Author and License

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

Copyright (C) 2026 James Cherti

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

Links

• buffer-guardian.el @GitHub

Other Emacs packages by the same author:

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

Security reminder: If you use kubernetes-el, don't update for now, and you might want to check your installation if you updated it recently. The repo was compromised. (Analysis, Reddit discussion, lobste.rs) If you use Emacs 31, please consider enabling package-review-policy.

There were a number of lively conversations around Emacs Solo (142 comments on HN), Emacs and Vim in the age of AI (52 comments on Reddit, 138 on HN), and agent-shell 0.47 (62 on Reddit). Also, Prot has posted the video and text of his talk Computing in freedom with GNU Emacs (YouTube 42:40, Video with Q&A, more links in the community section).

• Upcoming events (iCal file, Org):
  • M-x Research: TBA https://m-x-research.github.io/ Wed Mar 18 0900 America/Vancouver - 1100 America/Chicago - 1200 America/Toronto - 1600 Etc/GMT - 1700 Europe/Berlin - 2130 Asia/Kolkata – Thu Mar 19 0000 Asia/Singapore
  • EmacsSF (in person): coffee.el in SF https://www.meetup.com/emacs-sf/events/313776893/ Sat Mar 21 1100 America/Los_Angeles
  • Emacs Berlin: Emacs-Berlin Hybrid Meetup https://emacs-berlin.org/ Wed Mar 25 1100 America/Vancouver - 1300 America/Chicago - 1400 America/Toronto - 1800 Etc/GMT - 1900 Europe/Berlin - 2330 Asia/Kolkata – Thu Mar 26 0200 Asia/Singapore
  • Emacs APAC: Emacs APAC meetup (virtual) https://emacs-apac.gitlab.io/announcements/ Sat Mar 28 0130 America/Vancouver - 0330 America/Chicago - 0430 America/Toronto - 0830 Etc/GMT - 0930 Europe/Berlin - 1400 Asia/Kolkata - 1630 Asia/Singapore
• Emacs configuration:
  • Making Emacs Your Own « Here's The Beef (@BeefGriller@dice.camp)
  • Emacs Redux: use-short-answers: The Modern Way to Tame yes-or-no Prompts (Irreal)
  • Two Years of Emacs Solo: 35 Modules, Zero External Packages, and a Full Refactor (Reddit, HN, lobste.rs)
  • minimal-emacs.d Release 1.4.0​ (Reddit)
  • Brainiac v1.2 released — Kemal's Braindump (Codeberg, Reddit) - note-taking and task-management-centered Emacs config
• Emacs Lisp:
  • futur 1.2 (Reddit) futur-abort, futur-funcall, futur-p, preliminary support for running Elisp code in subprocesses and sandbox
• Appearance:
  • Emacs Redux: Taming Font-Lock with font-lock-ignore
  • Emacs Redux: Buffer-Local Face Remapping with face-remap-add-relative
  • Customizing Font-Lock in the Age of Tree-sitter (Reddit)
  • andros/comet.el: Cursor comet trail effect for Emacs - comet.el - Andros's repositories (@andros@activity.andros.dev)
• Navigation:
  • Nifty little modal editing implementation - selected.el, special keymap when region is active
  • Emacs Redux: isearch-lazy-count: Built-in Search Match Counting
  • kramo/scroll-beyond.el: An Emacs package to enable scrolling the point beyond window bounds - Codeberg.org (@kramo@chaos.social)
  • vmargb/arrow.el: Elisp implementation of arrow.nvim per-project and file-local bookmarks · GitHub (Reddit)
• Dired:
  • Chris Maiorana: The Emacs Way: Moving and Renaming Files
• Writing:
  • Re: markdown-ts-mode maturation for Emacs 31 - Rahul Martim Juliato - roadmap for markdown-ts, help wanted
  • lorniu/gt.el: Translator via engines such as Google, Bing, deepL, StarDict and Youdao, also support LLMs like ChatGPT, DeepSeek and so on. · GitHub (@kf@sonomu.club)
• Org Mode:
  • Thaodan/org-note-auto-save: Auto-save org-note buffer - Codeberg.org (@thaodan@mastodon.social)
  • niqc/org-dynamic-templates: Package for define template folder for org files - Codeberg.org (Reddit)
  • Sacha Chua: Emacs Lisp and NodeJS: Getting the bolded words from a section of a Google Document
  • mjamagon/arrow-lang: Arrow DSL for emacs · GitHub (Reddit) - dataflow pipeline language for Org Babel
  • Sacha Chua: Org Mode: Export HTML, copy files, and serve the results via simple-httpd so that media files work
  • Building a cli app to query org with clime v0.3 (Reddit)
• Coding:
  • Mike Olson - Beta: Emacs Multi-LSP support for Python and Typescript frameworks - looking for Emacs users to try it out (@mwolson.org, @mikeozen)
  • Emacs Redux: Code Formatting in Emacs (Irreal)
  • Emacs Redux: Removing Paired Delimiters in Emacs (Irreal)
  • Einar Mostad: Fix error with Cider Clojure REPL in Emacs on Guix
  • [EMACS LAB #2] Do zero a uma IDE para programar em C (parte 2) (01:17:59)
  • Philip Kaludercic: Emacs after Magit
  • Rebasing in Magit (@lobsters@mastodon.social)
  • Перебазирование в Magit / Хабр (@habr@zhub.link)
  • Release v0.4.0 · bbatsov/neocaml · GitHub - bugfix (@batsov.net)
• Shells:
  • rwc9u/emacs-libgterm: Terminal emulator for Emacs using libghostty-vt (Ghostty's terminal engine) · GitHub (Reddit)
  • cashmeredev/kitty-graphics.el: Display images in terminal Emacs (emacs -nw) via the Kitty graphics protocol
• Multimedia:
  • Sacha Chua: Comparing pronunciation recordings across time
  • Sacha Chua: Small steps towards using OpenAI-compatible text-to-speech services with speechd-el or emacspeak
• Fun:
  • Solo-RPG-mode for Emacs - TTRPG-Hangout.com (Github, @enfors@ttrpg-hangout.social)
  • vkazanov/elcity: A simple SimCity clone in Emacs Lisp · GitHub (Reddit)
• AI:
  • Emacs and Vim in the Age of AI (Reddit, HN, lobste.rs)
  • Using Terminal Coding Agents from Emacs
  • Randy Ridenour: Convert Claude Quizzes to Emacs Org Mode (@randyridenour@zirk.us)
  • agent-shell 0.47 updates (Reddit)- claude-code-acp renamed, bootstrapping and resuming
  • James Dyer: Ollama Buddy - In-Buffer LLM Streaming
  • 038 Ollama Buddy - Tool Calling and modifying files with an ediff session #emacs #ollama (02:12)
• Community:
  • Fortnightly Tips, Tricks, and Questions — 2026-03-10 / week 10
  • Protesilaos Stavrou: Computing in freedom with GNU Emacs (YouTube 42:40, Reddit, lobste.rs, Irreal, Video with Q&A, other post)
  • Emacs Carnival March 2026: Mistakes and Misconceptions
    • Emacs Carnival de Marzo - Confusiones y prejuicios | Texaco blog (@texaco@defcon.social)
    • Emacs carnival: Mistakes and misconceptions (@ericsfraga@fediscience.org)
    • noa ks: You don't not need the mouse
  • Eric MacAdie: 2026-02 Austin Emacs Meetup
  • Low Tech High Life: Emacs magia y liberación · Inicio (Spotify, @alvarmaciel@mastodon.social)
  • Humanities in the Machine - Blain Smith - mentions RMS, GNU, and Emacs
• Other:
  • Chris Maiorana: The Emacs Way: Create Directories
  • Indexing Info Manuals — Alex Carney (@alcarney@mastodon.social)
  • Emacs Internal #03: Tagged Union, Tagged Pointer, and Poor Man's Inheritance | The Cloudlet (Reddit, HN, lobste.rs)
  • reka: A window manager inside of Emacs for the Wayland world (Reddit) - mentioned in Separating the Wayland Compositor and Window Manager
  • chaoswork/appine: using a dynamic module that allows you to embed native macOS views (WebKit, PDFKit etc.) directly inside Emacs windows (Reddit)
  • My little Emacs OTG setup (Reddit)
  • Emacs running on my iPad. - using ish
• Emacs development:
  • emacs-devel: long discussion about deprecated code, warnings, and compat release schedule
  • Merge remote-tracking branch 'origin/scratch/error-API'
  • Add new function 'ensure-proper-list' (bug#80598)
  • Add references to "User Lisp" Info node where applicable
  • etags-regen: Don't try to generate tags during completion, by default
  • * etc/NEWS: Announce 'package-vc-install-from-checkout' obsoletion
  • Add 'xref-mouse-mode' minor mode
  • ; Add missing documentation for new 'cus-edit' bindings
  • (smerge-refine-regions): Refactor a bit and work between buffers
  • Improve the error API
• New packages:
  • buffer-guardian: Automatically Save Buffers Without Manual Intervention (MELPA)
  • ekg-agent: Agent tools for ekg (MELPA)
  • ekg-denote: Denote integration for ekg (MELPA)
  • markdown-table-wrap: Word-wrap GFM pipe tables to fit window width (MELPA)
  • stan-ts-mode: Major mode for editing Stan files (MELPA)

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

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

A perennial problem for Emacs users are the yes/no prompts that require answering “yes” or “no” instead of just “y” or “n”. The usual solution—adopted by almost everyone—is to alias yes-or-no-p to y-or-n-p. Sometime around Emacs 28 or 29 the new variable use-short-answers was introduced as another way of solving the problem.

The last time I wrote about solving the yes-or-no-p problem, I said,

I’ve had my original aliasing code for at least 17 years and see no reason to change it. When use-short-answers was first introduced, I thought I should adopt it but I never did and as far as I can see, it doesn’t make any difference.

That statement was wrong in two ways. First, as related by Bozhidar Batsov, the alias trick doesn’t always work with native compilation because the call to yes-or-no-p may have been compiled before the alias is made. For that reason, use-short-answers is the better solution because it always work.

The second way it was wrong is that when I went to add use-short-answers to my init.el, I discovered that I had already done so, probably back in Emacs 29.

Yet another neocaml issue taught me something I didn’t know about Emacs. Someone requested that the docs show how to customize font-lock faces per mode rather than globally. The suggested approach used face-remap-add-relative – a function I’d never heard of, despite 20+ years of daily Emacs use. Time to dig in.

The Problem

Let’s say you want type names in OCaml buffers to be displayed in a different color than in, say, Python buffers. The naive approach is to use custom-set-faces or set-face-attribute:

(set-face-attribute 'font-lock-type-face nil :foreground "DarkGreen")

This works, but it’s a global change – every buffer that uses font-lock-type-face will now show types in dark green.

When Global is Fine

To be fair, global face customization is perfectly valid in several scenarios:

• Your theme doesn’t cover certain faces. Many themes only style a subset of the faces that various packages define. If a face looks wrong or unstyled, a global set-face-attribute or custom-set-faces is the quickest fix.

• Your theme makes choices you disagree with. I recently ran into this with the Catppuccin theme – the styling of font-lock-variable-name-face didn’t match how I expected it to look, so I filed a PR. It got closed because different modes interpret that face inconsistently (definitions in Elisp, references in C), making a universal fix impractical for the theme. That’s exactly the kind of situation where you’d want to override the face yourself.

• You want consistent styling everywhere. If you just want all comments to be italic, or all strings to use a specific color regardless of mode, global is the way to go. No need to complicate things with per-buffer remapping.

When Global Isn’t Enough

The problem comes when you bounce between several languages (and let’s be honest, most of us do) and you want different visual treatment depending on the mode. Not all modes use the built-in font-lock faces consistently, and for some – especially markup languages – there’s a lot of room for improvisation in how faces get applied. A global change to font-lock-keyword-face might look great in your Python buffers but terrible in your Org files.

That’s where buffer-local face remapping comes in.

Enter face-remap-add-relative

face-remap-add-relative has been around since Emacs 23 (it lives in face-remap.el), and it does exactly what the name suggests – it remaps a face relative to its current definition, and only in the current buffer. The change is buffer-local, so it won’t leak into other buffers.

Here’s the basic usage:

(face-remap-add-relative 'font-lock-type-face :foreground "DarkGreen")

To apply this automatically in a specific mode, hook it up:

(defun my-ocaml-faces ()
  "Customize faces for OCaml buffers."
  (face-remap-add-relative 'font-lock-type-face :foreground "DarkGreen")
  (face-remap-add-relative 'font-lock-function-name-face :weight 'bold))

(add-hook 'neocaml-mode-hook #'my-ocaml-faces)

Now OCaml buffers get their own face tweaks while everything else stays untouched. You can do the same for any mode – just swap the hook and adjust the faces to taste.

The Magic “Cookie”

face-remap-add-relative returns a cookie – a token you’ll need if you want to undo the remapping later. If you’re just setting things up in a mode hook and leaving them, you can ignore the cookie. But if you want to toggle the remapping on and off, you’ll need to hold onto it:

(defvar-local my-type-face-cookie nil
  "Cookie for type face remapping.")

(defun my-toggle-type-face ()
  "Toggle custom type face in current buffer."
  (interactive)
  (if my-type-face-cookie
      (progn
        (face-remap-remove-relative my-type-face-cookie)
        (setq my-type-face-cookie nil)
        (message "Type face remapping removed"))
    (setq my-type-face-cookie
          (face-remap-add-relative 'font-lock-type-face
                                   :foreground "DarkGreen"))
    (message "Type face remapping applied")))

Note the use of defvar-local – since face remapping is buffer-local, your cookie variable should be too.

A cleaner approach is to wrap this in a minor mode:

(defvar-local my-type-remap-cookie nil)

(define-minor-mode my-type-remap-mode
  "Minor mode to remap type face in current buffer."
  :lighter " TypeRemap"
  (if my-type-remap-mode
      (setq my-type-remap-cookie
            (face-remap-add-relative 'font-lock-type-face
                                     :foreground "DarkGreen"))
    (when my-type-remap-cookie
      (face-remap-remove-relative my-type-remap-cookie)
      (setq my-type-remap-cookie nil))))

Related Functionality

A few more things worth knowing in this area:

• face-remap-set-base – sets the base remapping for a face in the current buffer. Unlike face-remap-add-relative (which layers on top of the existing face), this replaces the face definition entirely for that buffer. Use this when you want to completely override a face rather than tweak it.

• buffer-face-mode / buffer-face-set – a built-in minor mode that remaps the default face in the current buffer. This is what powers M-x buffer-face-set and is handy if you want a different base font in specific buffers (say, a proportional font for prose and a monospace font for code).

• text-scale-adjust (C-x C-= / C-x C--) – the familiar text scaling commands actually use face-remap-add-relative under the hood to remap the default face. So if you’ve ever zoomed text in a single buffer, you’ve been using face remapping without knowing it.

• face-remapping-alist – the buffer-local variable where all of this state is stored. You generally shouldn’t manipulate it directly (that’s what the functions above are for), but it’s useful for debugging – check its value in a buffer to see what remappings are active.

Wrapping Up

I have to admit – I’m a bit embarrassed that face-remap-add-relative has been sitting in Emacs since version 23 and I’d never once used it. Probably because I never felt the need for per-mode face customizations – but I can certainly see why others would, especially when working across languages with very different syntax highlighting conventions.

Working on neocaml has been a gold mine of learning (and relearning). I’m happy to keep sharing the things I discover along the way. Keep hacking!

Bozhidar Batsov has a nice post on delete-pair. It’s almost a case of the Baader-Meinhoff Phenomenon. Five months ago—before I wrote about it—I’d never heard of delete-pair and now it’s popping up on Batsov’s blog. Batsov, himself, doesn’t remember hearing about it before either.

For those who came in late, delete-pair does just what it says on the tin: delete the delimiter at point and its matching closing sibling. It’s actually quite flexible and usable in surprising ways as you can see from the_cecep’s original post that inspired mine.

The delete-pair command came to Batsov’s attention because it interacted poorly with his Neocaml package. That turned out to be because delete-pair makes assumptions that might not hold for languages with unusual syntax.

Batsov’s post is mostly a summary of what he found from researching the deletions of pairs in Emacs. For Lisp languages, all you need is paredit which has multiple ways of removing a delimiter pair. Probably the easiest is paredit-splice-sexp.

There’s also smartparens that also has several ways of removing a delimiter pair and has the advantage of working in all languages, not just Lisps. Batsov finds it too heavyweight for his needs but lots of folks swear by it.

Finally, there’s the builtin electric-pair-mode, which keeps delimiters balanced, pairs nicely with delete-pair, and is probably all most people need.

Take a look at Batsov’s post for more details and for a bit of Elisp that recreates Vim’s vim-surround. I was glad to see his post because I was right on the verge of forgetting delete-pair even though I’ve assigned it a keyboard shortcut.

Continuing my Prelude modernization effort (see the previous post for context), another long-standing third-party dependency I was happy to drop was anzu.

The Problem

When you’re searching with C-s in Emacs, you can see the current match highlighted, but you have no idea how many total matches exist in the buffer or which one you’re currently on. Are there 3 matches or 300? You just don’t know.

The Old Way

For years, I used the anzu package (an Emacs port of anzu.vim) to display match counts in the mode-line. It worked well, but it was yet another third-party dependency to maintain – and one that eventually ended up in the Emacs orphanage, which is never a great sign for long-term maintenance.

The New Way

Emacs 27 introduced isearch-lazy-count:

(setopt isearch-lazy-count t)

With this enabled, your search prompt shows something like (3/47) – meaning you’re on the 3rd match out of 47 total. Simple, built-in, and requires no external packages.

Unlike anzu, which showed counts in the mode-line, isearch-lazy-count displays them right in the minibuffer alongside the search string, which is arguably a better location since your eyes are already there while searching.

Customizing the Format

Two variables control how the count is displayed:

;; Prefix format (default: "%s/%s ")
;; Shows before the search string in the minibuffer
(setopt lazy-count-prefix-format "(%s/%s) ")

;; Suffix format (default: nil)
;; Shows after the search string
(setopt lazy-count-suffix-format nil)

If you prefer the count at the end of the prompt (closer to how anzu felt), you can swap them:

(setopt lazy-count-prefix-format nil)
(setopt lazy-count-suffix-format " [%s/%s]")

Good to Know

The count works with all isearch variants – regular search, regex search (C-M-s), and word search. It also shows counts during query-replace (M-%) and query-replace-regexp (C-M-%), which is very handy for knowing how many replacements you’re about to make.

The counting is “lazy” in the sense that it piggybacks on the lazy highlighting mechanism (lazy-highlight-mode), so it doesn’t add significant overhead. In very large buffers, you might notice a brief delay before the count appears, controlled by lazy-highlight-initial-delay. One thing to keep in mind – if you’ve disabled lazy highlighting for performance reasons, you’ll need to re-enable it, as the count depends on it.

If you haven’t read it already, check out my earlier article You Have No Idea How Powerful Isearch Is for a deep dive into what isearch can do. isearch-lazy-count pairs nicely with all the features covered there.

Between use-short-answers and isearch-lazy-count, that’s two third-party packages I was able to drop from Prelude just by using built-in functionality. Keep hacking!

I recently started a long overdue update of Emacs Prelude, rebasing it on Emacs 29 as the minimum supported version. This has been a great excuse to revisit a bunch of old configuration patterns and replace them with their modern built-in equivalents. One of the first things I updated was the classic yes-or-no-p hack.

The Problem

By default, Emacs asks you to type out the full word yes or no for certain prompts – things like killing a modified buffer or deleting a file. The idea is that this extra friction prevents you from accidentally confirming something destructive, but in practice most people find it annoying and want to just hit y or n.

The Old Way

For decades, the standard solution was one of these:

(fset 'yes-or-no-p 'y-or-n-p)

;; or equivalently:
(defalias 'yes-or-no-p 'y-or-n-p)

This worked by literally replacing the yes-or-no-p function with y-or-n-p at runtime. Hacky, but effective – until native compilation came along in Emacs 28 and broke it. Native compilation can hardcode calls to C primitives, which means fset/defalias sometimes has no effect on yes-or-no-p calls that were already compiled. You’d set it up, and some prompts would still ask for yes or no. Not fun.

The New Way

Emacs 28 introduced the use-short-answers variable:

(setopt use-short-answers t)

That’s it. Clean, discoverable, native-compilation-safe, and officially supported. It makes yes-or-no-p delegate to y-or-n-p internally, so it works correctly regardless of compilation strategy.

If you’re maintaining a config that needs to support older Emacs versions as well, you can do:

(if (boundp 'use-short-answers)
    (setopt use-short-answers t)
  (fset 'yes-or-no-p 'y-or-n-p))

A Word of Caution

The Emacs maintainers intentionally designed yes-or-no-p to slow you down for destructive operations. Enabling use-short-answers removes that friction entirely. In practice, I’ve never accidentally confirmed something I shouldn’t have with a quick y, but it’s worth knowing the tradeoff you’re making.

A Few More Things

If you’re using GUI Emacs, you might also want to disable dialog boxes for a consistent experience:

(setopt use-dialog-box nil)

It’s also worth knowing that the related variable read-answer-short controls the same behavior for multi-choice prompts (the ones using read-answer internally). Setting use-short-answers affects both yes-or-no-p and read-answer.

This is one of those small quality-of-life improvements that Emacs has been accumulating in recent versions. Updating Prelude has been a nice reminder of how many rough edges have been smoothed over. Keep hacking!

In Org Mode, when you use "Export to HTML - As HTML file and open", the resulting HTML file is loaded using a file:// URL. This means you can't load any media files. In my post about pronunciation practice, I wanted to test the playback without waiting for my 11ty-based static site generator to churn through the files.

simple-httpd lets you run a web server from Emacs. By default, the httpd-root is ~/public_html and httpd-port is 8085, but you can configure it to be somewhere else. Here I set it up to create a new temporary directory, and to delete that directory afterwards.

(use-package simple-httpd
  :config
  (setq httpd-root (make-temp-file "httpd" t))
  :hook
  (httpd-stop . my-simple-httpd-remove-temporary-root)
  (kill-emacs . httpd-stop))

(defun my-simple-httpd-remove-temporary-root ()
  "Remove `httpd-root' only if it's a temporary directory."
  (when (file-in-directory-p httpd-root temporary-file-directory)
    (delete-directory httpd-root t)))

The following code exports your Org buffer or subtree to a file in that directory, copies all the referenced local files (if they're newer) and updates the links in the HTML, and then serves it via simple-httpd. Note that it just overwrites everything without confirmation, so if you refer to files with the same name, only the last one will be kept.

(with-eval-after-load 'ox
  (org-export-define-derived-backend 'my-html-served 'html
    :menu-entry
    '(?s "Export to HTML and Serve"
         ((?b "Buffer"  my-org-serve--buffer)
          (?s "Subtree" my-org-serve--subtree)))))

(defun my-org-serve--buffer (&optional async _subtreep visible-only body-only ext-plist)
  (my-org-export-and-serve nil))

(defun my-org-serve--subtree (&optional async _subtreep visible-only body-only ext-plist)
  (my-org-export-and-serve t))

;; Based on org-11ty--copy-files-and-replace-links
;; Might be a good idea to use something DOM-based instead
(defun my-html-copy-files-and-replace-links (info &optional destination-dir)
  (let ((file-regexp "\\(?:src\\|href\\|poster\\)=\"\\(\\(file:\\)?.*?\\)\"")
        (destination-dir (or destination-dir (file-name-directory (plist-get info :file-path))))
        file-all-urls file-name beg
        new-file file-re
        unescaped)
    (unless (file-directory-p destination-dir)
      (make-directory destination-dir t))
    (unless (file-directory-p destination-dir)
      (error "%s is not a directory." destination-dir))
    (save-excursion
      (goto-char (point-min))
      (while (re-search-forward file-regexp nil t)
        (setq file-name (or (match-string 1) (match-string 2)))
        (unless (or (string-match "^#" file-name)
                    (get-text-property 0 'changed file-name))
          (setq file-name
                (replace-regexp-in-string
                 "\\?.+" ""
                 (save-match-data (if (string-match "^file:" file-name)
                                      (substring file-name 7)
                                    file-name))))
          (setq unescaped
                (replace-regexp-in-string
                 "%23" "#"
                 file-name))
          (setq new-file (concat
                          (if info (plist-get info :permalink) "")
                          (file-name-nondirectory unescaped)))
          (unless (org-url-p file-name)
            (let ((new-file-name (expand-file-name (file-name-nondirectory unescaped)
                                                   destination-dir)))
              (condition-case err
                  (when (or (not (file-exists-p new-file-name))
                            (file-newer-than-file-p unescaped new-file-name))
                    (copy-file unescaped new-file-name t))
                (error nil))
              (when (file-exists-p new-file-name)
                (save-excursion
                  (goto-char (point-min))
                  (setq file-re (concat "\\(?: src=\"\\| href=\"\\| poster=\"\\)\\(\\(?:file://\\)?" (regexp-quote file-name) "\\)"))
                  (while (re-search-forward file-re nil t)
                    (replace-match
                     (propertize
                      (save-match-data (replace-regexp-in-string "#" "%23" new-file))
                      'changed t)
                     t t nil 1)))))))))))

(defun my-org-export-and-serve (&optional subtreep)
  "Export current org buffer (or subtree if SUBTREEP) to HTML and serve via simple-httpd."
  (interactive "P")
  (require 'simple-httpd)
  (httpd-stop)
  (unless httpd-root (error "Set `httpd-root'."))
  (unless (file-directory-p httpd-root)
    (make-directory httpd-root t))
  (unless (file-directory-p httpd-root)
    (error "%s is not a directory." httpd-root))
  (let* ((out-file (expand-file-name (concat (file-name-base (buffer-file-name)) ".html")
                                     httpd-root))
         (html-file (org-export-to-file 'my-html-served out-file nil subtreep)))
    ;; Copy all the files and rewrite all the links
    (with-temp-file out-file
      (insert-file-contents out-file)
      (my-html-copy-files-and-replace-links
       `(:permalink "/") httpd-root))
    (httpd-start)
    (browse-url (format "http://localhost:%d/%s"
                        httpd-port
                        (file-name-nondirectory html-file)))))

Now I can use C-c C-e (org-export-dispatch), select the subtree with C-s, and use s s to export a subtree to a webserver and have all the media files work. This took 0.46 seconds for my post on pronunciation practice and automatically opens the page in a browser window. In comparison, my 11ty static site generator took 5.18 seconds for a subset of my site (1630 files copied, 214 files generated), and I haven't yet hooked up monitoring it to Emacs, so I have to take an extra step to open the page in the browser when I think it's finished. I think exporting to HTML and serving it with simple-httpd will be much easier for simple cases like this, and then I can export to 11ty once I'm done with the basic checks.

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

Just a quick post today to note that Protesilaos Stavrou (Prot) has published the video from his FOSS @ Oxford talk that I wrote about yesterday. Actually, he says that it’s a modified version of that talk so I don’t know if a video of the actual talk will appear or not.

In any event, the video tracked very well with the transcript that I wrote about in yesterday’s post. The video is a little easier to follow because you can see the changes to the text that he makes during his talk. If you’re the type of person that gets more out of a video than reading a transcript, be sure to take a look. The video is fairly long at 42 minutes, 40 seconds long so you’ll have to put some time aside for it but it’s definitely worth your while.

I stopped using Magit with Emacs a few months ago. Initially this was just because Magit added a new dependency cond-let that was conflicting the upstream development of a macro by the same name, but I had already taken issue with the number of dependencies such as llama, and generally do not enjoy Transient-based user interfaces, so I ended up sticking with the descision.

First things first: The absence of Magit in my regular arsenal is noticeable and slightly annoying. There are things I have gotten so used to doing via Magit, that I had to look up how I could do them without. And it is about this experience that I want to write about here.

The first and most immediate difference is that when I have to perform some Git-action, I don’t call magit-status (which I had bound to C-c g instead of the default global binding C-x g). Instead I mostly use shell-command (M-!), or more specifically my “fork” shell-command+ that I had extended to always run certain commands asynchronously, such as git or even defer to the respective VC-mode commands. So M-! git diff RET actually calls vc-diff, instead of just spitting the output into “*Async Shell Command*” (even if in this specific case I’d usually invoke C-x v D (vc-root-diff)). Having the bash-completion package installed also helps to find the right flags for git subcommands.

In other operations I can now use VC-mode more effectively. As of Emacs 31, a number of useful features have been added (mostly by the now new Emacs maintainer Sean Whitton) such as the ability to edit previous commit messages by pressing e in the “*vc-changes-log*” buffer, which extends the previous capabilities to just amend an existing commit message more effectively. See etc/NEWS for more details.

But there are useful features in Magit that are actually composite commands. The ones I found missing the most were spinning of branches (creating a new branch and reverting the previous branch to the upstream position) and easy fixups of previous commits. When researching online, an idea I came up upon was to add git alii to my configuration. I have to admit that I was disinclined to do so, again not so much for necessarily technical reasons, but mostly because I associate the usage of a git alias with people who insist on saving time by writing git c instead of git commit (or worse yet, they add a shell alias gc). Instead, I recalled that any subcommand git foo checks if an executable git-foo is in PATH and can defer to that instead. So I wrote scripts for the most common use-cases that I ran into

• git spinoff NEW-BRANCH-NAME, create a new branch NEW-BRANCH-NAME with the commits between HEAD and the upstream state of the current branch, and then reset the current branch to the upstream state.

• git update, is basically just a shorthand for git pull --autostash --rebase.

• git fixup COMMIT, tries to amend the changes in the staging area onto a COMMIT, and then rebase all subsequent commits onto the modified changes.

These are really basic scripts that I just invoke using M-!, no further magic involved.

Some Git commands require user input, which in a terminal would start a TUI editor like vi or GNU nano. As I am executing commands using M-!, this is an issue, since I am not emulating a proper terminal, and do not intend to do so. Magit handles this using the with-editor package, which I have been thinking about using as well, but for now I just set

(setenv "EDITOR" "ed")

in my init.el and have been running with it since. It is not ideal, but slightly funny, and 99% of the time all I have to do is write wq anyway.

All in all this was an interesting exercise, and for now it works well enough. I know I am more in the “integrating development environment” school of Emacs, so some of my practices might appears strange, but I hope some might also be intrigued. Finally, I have to clarify that this post is about how I work with Git, and is not a hit-piece on Magit or anyone working on Magit — the issues I take with Magit are due to my own preferences and requirements, and not normative statements on how everyone should use Git with Emacs.

The other day someone filed an issue against my neocaml package, reporting surprising behavior with delete-pair. My first reaction was – wait, delete-pair? I’ve been using Emacs for over 20 years and I wasn’t sure I had ever used this command. Time for some investigation!

What is delete-pair?

delete-pair is a built-in Emacs command (defined in lisp/emacs-lisp/lisp.el) that deletes a pair of matching characters – typically parentheses, brackets, braces, or quotes. You place point on an opening delimiter, invoke delete-pair, and it removes both the opening and closing delimiter.

Given that it lives in lisp.el, it was clearly designed with Lisp editing in mind originally. And it was probably quite handy back in the day – before paredit came along and made delete-pair largely redundant for Lisp hackers.

Here’s a simple example. Given the following code (with point on the opening parenthesis):

(print_endline "hello")

Running M-x delete-pair gives you:

print_endline "hello"

Simple and useful! Yet delete-pair has no default keybinding, which probably explains why so few people know about it. If you want to use it regularly, you’ll need to bind it yourself:

(global-set-key (kbd "M-s-d") #'delete-pair)

Pick whatever keybinding works for you, of course. There’s no universally agreed upon binding for this one.

The Gotcha

The issue that was reported boiled down to delete-pair not always finding the correct matching delimiter. It uses forward-sexp under the hood to find the matching closer, which means its accuracy depends entirely on the buffer’s syntax table and the major mode’s parsing capabilities. For languages with complex or unusual syntax, this can sometimes lead to the wrong delimiter being removed – not great when you’re trying to be surgical about your edits.

Alternatives for Pair Management

If you work with paired delimiters frequently, delete-pair is just one tool in a rich ecosystem. Here’s a quick overview of the alternatives:

paredit

paredit is the gold standard for structured editing of Lisp code. I’ve been a heavy paredit user for as long as I can remember – if you write any Lisp-family language, it’s indispensable. paredit gives you paredit-splice-sexp (bound to M-s by default), which removes the surrounding delimiters while keeping the contents intact. There’s also paredit-raise-sexp (M-r), which replaces the enclosing sexp with the sexp at point – another way to get rid of delimiters. And of course, paredit prevents you from creating unbalanced expressions in the first place, which is a huge win.

Once you’ve got paredit in your muscle memory, you’ll never think about delete-pair again (as I clearly haven’t).

Let’s see these commands in action. In the examples below, | marks the position of point.

paredit-splice-sexp (M-s) – removes the surrounding delimiters:

;; Before (point anywhere inside the inner parens):
(foo (bar| baz) quux)

;; After M-s:
(foo bar| baz quux)

paredit-raise-sexp (M-r) – replaces the enclosing sexp with the sexp at point:

;; Before:
(foo (bar| baz) quux)

;; After M-r:
(foo bar| quux)

Notice the difference: splice keeps all the siblings, raise keeps only the sexp at point and discards everything else inside the enclosing delimiters.

smartparens

smartparens is the most feature-rich option and works across all languages, not just Lisps. For unwrapping pairs, it offers a whole family of commands:

• sp-unwrap-sexp – removes the enclosing pair delimiters, keeping the content
• sp-backward-unwrap-sexp – same, but operating backward
• sp-splice-sexp (M-D) – removes delimiters and integrates content into the parent expression
• sp-splice-sexp-killing-backward / sp-splice-sexp-killing-forward – splice while killing content in one direction

Here’s how the key ones look in practice:

sp-unwrap-sexp – removes the next pair’s delimiters:

# Before (point on the opening bracket):
result = calculate(|[x, y, z])

# After sp-unwrap-sexp:
result = calculate(|x, y, z)

sp-splice-sexp (M-D) – works like paredit’s splice, removes the innermost enclosing pair:

# Before (point anywhere inside the parens):
result = calculate(x + |y)

# After M-D:
result = calculate x + |y

sp-splice-sexp-killing-backward – splices, but also kills everything before point:

# Before:
result = [first, second, |third, fourth]

# After sp-splice-sexp-killing-backward:
result = |third, fourth

I used smartparens for a while for non-Lisp languages, but eventually found it a bit heavy for my needs.

electric-pair-mode

electric-pair-mode is the built-in option (since Emacs 24.1) that automatically inserts matching delimiters when you type an opening one. It’s lightweight, requires zero configuration, and works surprisingly well for most use cases. I’ve been using it as my go-to solution for non-Lisp languages for a while now.

The one thing electric-pair-mode doesn’t offer is any way to unwrap/remove paired delimiters. The closest it gets is deleting both delimiters when you backspace between an adjacent empty pair (e.g., (|) – pressing backspace removes both parens). But that’s it – there’s no unwrap command. That’s where delete-pair comes in handy as a complement.

A Note on Vim’s surround.vim

Having played with Vim and its various surround.vim-like plugins over the years, I have to admit – I kind of miss that experience in Emacs, at least for removing paired delimiters. surround.vim makes it dead simple: ds( deletes surrounding parens, ds" deletes surrounding quotes. It works uniformly across all file types and feels very natural.

In Emacs, the story is more fragmented – paredit handles it beautifully for Lisps, smartparens does it for everything but is a heavyweight dependency, and electric-pair-mode just… doesn’t do it at all. delete-pair is the closest thing to a universal built-in solution, but its lack of a default keybinding and its reliance on forward-sexp make it a bit rough around the edges.

If you’re using electric-pair-mode and want a simple surround.vim-style “delete surrounding pair” command without pulling in a big package, here’s a little hack that does the trick:

(defun delete-surrounding-pair (char)
  "Delete the nearest surrounding pair of CHAR.
CHAR should be an opening delimiter like (, [, {, or \".
Works by searching backward for the opener and forward for the closer."
  (interactive "cDelete surrounding pair: ")
  (let* ((pairs '((?\( . ?\))
                  (?\[ . ?\])
                  (?{ . ?})
                  (?\" . ?\")
                  (?\' . ?\')
                  (?\` . ?\`)))
         (closer (or (alist-get char pairs)
                     (error "Unknown pair character: %c" char))))
    (save-excursion
      (let ((orig (point)))
        ;; Find and delete the opener
        (when (search-backward (char-to-string char) nil t)
          (delete-char 1)
          ;; Find and delete the closer (adjust for removed char)
          (goto-char (1- orig))
          (when (search-forward (char-to-string closer) nil t)
            (delete-char -1)))))))

(global-set-key (kbd "M-s-d") #'delete-surrounding-pair)

Now you can hit M-s-d ( to delete surrounding parens, M-s-d " for quotes, etc. It’s deliberately naive – no syntax awareness, no nesting support – so it won’t play well with delimiters inside strings or comments (it’ll happily match a paren in a comment if that’s what it finds first). But for quick, straightforward edits it gets the job done.

TIP: If you’re looking for something closer to the surround.vim experience in Emacs (without going full smartparens), check out surround.el. It’s a lightweight package (available on MELPA) that provides surround.vim-style operations – deleting, changing, and adding surrounding pairs – all through a single keymap. It supports both “inner” and “outer” text selection modes and works uniformly across file types, which makes it a nice middle ground between delete-pair and smartparens.

When to Use What

My current setup is:

• Lisp languages (Emacs Lisp, Clojure, Common Lisp, etc.): paredit, no contest.
• Everything else: electric-pair-mode for auto-pairing (I rarely need to unwrap something outside of Lisps)

I think surround.el will pair well with electric-pair-mode, but I discovered it only recently and I’ve yet to try it out in practice.

If you want a more powerful structural editing experience across all languages, smartparens is hard to beat. It’s just more than I personally need outside of Lisp.

Wrapping Up

One of the greatest aspects of Emacs is that we get to learn (or relearn) something about it every other day. Even after decades of daily use, there are always more commands lurking in the corners, patiently waiting to be discovered.

Now, if you’ll excuse me, I’m going to immediately forget about delete-pair again. Keep hacking!

Update: A reader pointed me to this Reddit thread with more tips on using delete-pair (including using it to change surrounding delimiters, surround.vim-style). Worth a read if you want to get more mileage out of it.

Protesilaos Stavrou (Prot) recently gave a talk to the FOSS @ Oxford event on the power of Emacs and why he uses it. The video for the talk is not yet available but he does have the transcript that he used for delivering the presentation.

It was a nice talk that explained why Prot believes Emacs is a tool that everyone using a computer should be familiar with and make use of. The TL;DR is that Emacs is extensible and can integrate all the (text-based) tasks you need to perform on your computer. If, as a trivial example, you develop a color and font style that is pleasing to you, you need only implement it once: Emacs will use it for whatever tasks you like. Non trivially, you can arrange for various tasks to communicate with each other and share information if they need to.

Prot stresses a point that Irreal has often made: You don’t have to be a programmer to make good use of Emacs. Writers, teachers, liberal arts academics, and many others can and do leverage Emacs to make their work easier. Of course, if you know a bit of Elisp it’s even better because you can extend Emacs to do whatever you need. Prot himself is not a programmer but he taught himself Elisp and is now a significant contributor to Emacs.

The takeaway from Prot’s talk is that Emacs is all about freedom. Freedom to make whatever changes you like, freedom to explore the source code and see how Emacs does things, and freedom to share with others and learn from them.

Take a look at the transcript or wait for the video if you prefer visual presentations. In either case, it’s well worth your time.

In the last article in the series, we talked about deleting files, which is scary and sad. In this article, I’m happy to change topics into creation territory as we learn how to create directories in the UNIXy way and the Emacs way.

Which way is better? I leave that up to you, but you should know both, because context matters, and there be times when you need one because the other one might not be available.

Remember, in your computer everything is a file, even directories are files that point to other files.

So let’s get into it.

Also, be sure to check out my DRM-free eBooks for your open source enjoyment (OSE):

• Emacs For Writers
• Git For Writers

mkdir new_directory
mkdir -p path/to/nested/directory

The post The Emacs Way: Create Directories appeared first on Chris Maiorana.

(subed-record-extract-all-approximately-matching-phrases
   sentences
   "/home/sacha/sync/recordings/2026-02-20-raphael.json"
   "/home/sacha/proj/french/analysis/virelangues/2026-02-20-raphael-script.vtt")

(my-lang-summarize-segments
 sentences
 '(("/home/sacha/proj/french/analysis/virelangues/2026-02-20-raphael-script.vtt" . "Feb 20")
 ;("~/sync/recordings/processed/2026-02-20-raphael-tongue-twisters.vtt" . "Feb 20")
        ("~/sync/recordings/processed/2026-02-22-virelangues-single.vtt" . "Feb 22")
        ("~/proj/french/recordings/2026-02-26-virelangues-script.vtt" . "Feb 26")
        ("~/proj/french/recordings/2026-02-27-virelangues-script.vtt" . "Feb 27")
        ("~/proj/french/recordings/2026-03-03-virelangues.vtt" . "Mar 3")
        ("/home/sacha/sync/recordings/processed/2026-03-03-raphael-reference-script.vtt" . "Mar 3")
        ("~/proj/french/analysis/virelangues/2026-03-06-raphael-script.vtt" . "Mar 6")
        ("~/proj/french/analysis/virelangues/2026-03-12-virelangues-script.vtt" . "Mar 12"))
 "clip"
 #'my-lang-subed-record-get-last-attempt
 #'my-lang-subed-record-cell-info
 t
 )

(my-subed-record-analyze-file-with-azure
 (subed-record-keep-last
  (subed-record-filter-skips
   (subed-parse-file
    "/home/sacha/proj/french/analysis/virelangues/2026-03-13-raphael-script.vtt")))
 "~/proj/french/analysis/virelangues-2026-03-13/2026-03-13-clip")

(defun my-lang-subed-record-cell-info (item file-index file sub)
  (let* ((sound-file (expand-file-name (format "%s-%s-%d.opus"
                                               prefix
                                               (my-transform-html-slugify item)
                                               (1+ file-index))))
         (score (car (split-string
                      (or
                       (subed-record-get-directive "#+SCORE" (elt sub 4)) "")
                      ";")))
         (note (replace-regexp-in-string
                (concat "^" (regexp-quote (cdr file))
                        "\\(: \\)?")
                ""
                (or (subed-record-get-directive "#+NOTE" (elt sub 4)) ""))))
    (when (or always-create (not (file-exists-p sound-file)))
      (subed-record-extract-audio-for-current-subtitle-to-file sound-file sub))
    (org-link-make-string
     (concat "audio:" sound-file "?icon=t"
             (format "&source=%s&source-start=%s" (car file) (elt sub 1))
             (format "&title=%s"
                     (url-hexify-string
                      (if (string= note "")
                          (cdr file)
                        (concat (cdr file) ": " note)))))
     (concat
      "▶️"
      (if score (format " %s" score) "")
      (if (string= note "") "" "*")))))

(defun my-lang-subed-record-get-last-attempt (item file)
  "Return the last subtitle matching ITEM in FILE."
  (car
   (last
    (seq-remove
     (lambda (o) (string-match "#\\+SKIP" (or (elt o 4) "")))
     (learn-lang-subed-record-collect-matching-subtitles
      item
      (list file)
      nil
      nil
      'my-subed-simplify)))))

(defun my-lang-summarize-segments (items files prefix attempt-fn cell-fn &optional always-create)
  (cons
   (append
    (seq-map 'cdr files)
    (list "Text"))
   (seq-map
    (lambda (item)
      (append
       (seq-map-indexed
        (lambda (file file-index)
          (let* ((sub (funcall attempt-fn item file)))
            (if sub
                (funcall cell-fn item file-index file sub)
              "")))
        files)
       (list item)))
    items)))

(defun my-subed-record-analyze-file-with-azure (subtitles prefix &optional always-create)
  (cons
   '("Gt" "Kk" "Az" "Me" "ID" "Comments" "All" "Acc" "Flu" "Comp" "Conf")
   (seq-map-indexed
    (lambda (sub i)
      (let ((sound-file (expand-file-name (format "%s-%02d.opus"
                                                  prefix
                                                  (1+ i))))
            (tts-services
             '(("gtts" . learn-lang-tts-gtts-say)
               ("kokoro" . learn-lang-tts-kokoro-fastapi-say)
               ("azure" . learn-lang-tts-azure-say)))
            tts-files
            (note (subed-record-get-directive "#+NOTE" (elt sub 4))))
        (when (or always-create (not (file-exists-p sound-file)))
          (subed-record-extract-audio-for-current-subtitle-to-file sound-file sub))
        (setq
         tts-files
         (mapcar
          (lambda (row)
            (let ((reference (format "%s-%s-%02d.opus" prefix (car row) (1+ i) )))
              (when (or always-create (not (file-exists-p reference)))
                (funcall (cdr row)
                         (subed-record-simplify (elt sub 3))
                         'sync
                         reference))
              (org-link-make-string
               (concat "audio:" reference "?icon=t&note=" (url-hexify-string (car row)))
               "👂🏼")))
          tts-services))
        (append
         tts-files
         (list
          (org-link-make-string
           (concat "audio:" sound-file "?icon=t"
                   (format "&source-start=%s" (elt sub 1))
                   (if (and note (not (string= note "")))
                       (format "&title=%s"
                               (url-hexify-string note))
                     ""))
           "▶️")
          (format "%d" (1+ i))
          (or note ""))
         (learn-lang-azure-subed-record-parse (elt sub 4))
         (list
          (elt sub 3)))))
    subtitles)))

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

Raw link: https://www.youtube.com/watch?v=M6ZHDJeG-dI

This is a holistic introduction to Emacs: how useful it is and how it champions free software. It is a modified version of the talk I did for the “FLOSS @ Oxford” event, organised by people at the University of Oxford. This is the page I wrote about that event: https://protesilaos.com/codelog/2026-03-12-my-emacs-talk-floss-oxford/.

Table of Contents

1. This is a holistic introduction to Emacs
2. Emacs as a capable text editor
3. Support for Unicode
4. Include several fonts on the same page
5. Emacs can display graphics alongside text
6. Emacs is an extensible text editor
7. Extending Emacs creates a community
8. The extensibility of Emacs happens live
9. My view without the “presentation mode”
10. Emacs puts you in control of your computing
11. Your control extends to all workflows
12. For an integrated computing environment
13. Many apps do not combine nicely
14. Emacs makes your workflow consistent
15. Integrated computing in practice
16. Emacs makes integration easier
17. Integration gives you emergent properties
18. This is plain text that works like a slideshow
19. Consistency facilitates productivity
20. Consistency remove the cognitive burden
21. The consistency of Emacs in action
22. Use Emacs Lisp to configure everything
23. Learning Emacs Lisp improves the experience
24. Emacs embodies software freedom
25. The freedom of Emacs helps with learning
26. Emacs is not only for programmers
27. You benefit from all the Emacs extensions
28. Some powerful extensions are built-in
29. The documentation culture of Emacs
30. Most packages have high quality manuals
31. Emacs has a steep learning curve
32. Do not skip the manuals
33. Adjust your expectations
34. Why it is worth learning how to use Emacs
35. The initial effort pays off long-term
36. Good luck and have fun!

Hello everyone! My name is Protesilaos, also known as “Prot”.

This presentation is a modified version of the talk I gave last night at the FLOSS @ Oxford event: https://ox.ogeer.org/event/computing-in-freedom-with-gnu-emacs-protesilaos-stavrou.

It was an event organised by people from the University of Oxford. I thank them for giving me the opportunity to participate in their programme.

I want to have this modified version here for people who do not read my website. They may not be aware that I talked at this Oxford event.

Having the video on this platform means that everyone can benefit from it.

1 This is a holistic introduction to Emacs

In this presentation I will talk to you about GNU Emacs, or simply, “Emacs”. Emacs is a program you run on your computer. I am using it right now for this presentation.

Emacs is free or libre software. It allows you to read all of its source code, to modify it, and to share it with your customisations. Thus you contribute to—and benefit from—a community of welcoming Emacs users.

I will tell you what all this means in practice and how you can improve your computing experience by switching to Emacs.

2 Emacs as a capable text editor

When you first start using Emacs, it feels like a regular text editor program.

You move the cursor around and edit text. Nothing obviously impressive out-of-the-box.

As a text editor, Emacs is highly capable. It has all sorts of keyboard shortcuts that let you efficiently operate on text.

You can control Emacs without relying on the mouse, if you want.

3 Support for Unicode

Emacs supports the Unicode standard, which is essential for inclusivity of peoples.

The world’s scripts can be expressed in Emacs. I am a native Greek speaker.

I can use functionality that is built into Emacs to switch to the Greek alphabet in order to write something, such as to say «καλησπέρα», which means “good evening”.

I can even spell out “Dao De Jing” (道德经), which is the title of a book from ancient China.

Plus emoji: 🦚🦬🐉.

4 Include several fonts on the same page

The multitude of scripts can be present in the same document.

This is an advantage for multilingual people like myself or those who do research that involves many natural languages.

Emacs can combine several fonts in the same page as well as different colours.

Each fonts can have its own attributes, such as for its relative size and typographic intensity.

Same idea for colours.

On my screen right now, I am already combining two different font styles: that of the heading and the body of the text.

5 Emacs can display graphics alongside text

Emacs does not limit you to a text-only interface. It can also display images and PDF documents. Below I have a link to an image file. I will now type a keyboard shortcut to reveal this image. And I will do it again to hide it.

This, by the way, is a spot somewhere in my mountains.

6 Emacs is an extensible text editor

Although you can benefit from using Emacs as a generic text editor, what really appeals to people like me is the option to extend Emacs.

“Extend” here means to introduce new functionality; functionality that is not available in the default program you install on your computer.

These extensions are written in the same programming language as most of Emacs. It is a programming language called “Emacs Lisp” or “Elisp”.

You can extend Emacs on your own, by writing some program in Elisp, or you can download an existing extension that the community has made available.

7 Extending Emacs creates a community

For example, when I create a new extension for Emacs, I publish it under the terms of a free software license—the same terms that Emacs uses.

Others can then download my extension and use it as they prefer. If they want, they can make their own modifications on top, which may introduce other extensions that I had not thought of in my original implementation.

And if those users follow my example, then I can also benefit from their additions once they publish them.

As such, there exists a community of enthusiastic users of Emacs who care about sharing their works with the rest of the world.

8 The extensibility of Emacs happens live

Users can extend Emacs by running some Emacs Lisp program. Such a program can be as short as a single line. Or it can be as long as it needs to be. It does not matter.

Users run the program and Emacs immediately does what the program renders possible.

For example, I am doing this presentation inside of Emacs. But Emacs does not have a “presentation mode” built into it. I thus developed my own extension which empowers me to do what I am doing right now.

Let me toggle off my presentation mode to show you what I mean.

9 My view without the “presentation mode”

Notice that the display has changed.My main font is monospaced now.

The headings are smaller than they were before: they are the same size as the rest of the text. There is no number next to the heading anymore.

Then, there is a bar at the bottom of my screen, with information about what I am working on. On the side, there are line numbers, indicating where my cursor is in this file. Plus, my current line is highlighted with a distinct background colour. Let me shift it up and down to illustrate this point.

All those elements are useful while I am programming. But they look distracting when I wish to focus on some portion of text. So, I just type the keyboard shortcut I have and—voilà!—I get the style I prefer.

10 Emacs puts you in control of your computing

You may wonder: why do I even need a customisable text editor?

The answer is about control. You are in charge of what you use and how you use it. You can piece together a workflow that works the way you prefer.

This presentation mode I toggled on and off earlier behaves exactly how I want. I decided which set of interface tweaks to apply. Another user may have a different preference in this regard.

For instance, they may like having line numbers on the side of the screen. There is no right or wrong answer. What matters is that Emacs gives us the means to do what makes sense to us.

11 Your control extends to all workflows

Now apply this principle to everything you can use Emacs for: this will generally be a text-centric project.

I run my agenda exclusively through Emacs.

I handle all my email correspondence with Emacs.

I do programming and I write prose, such as blog posts for my website and books or technical manuals.

For each of these, I know that Emacs will empower me to perform my tasks without arbitrary restrictions.

Emacs lets me use Elisp to modify how I do my emails, for instance, and how I present tasks in my custom agenda view.

12 For an integrated computing environment

Without Emacs, I would not be in a position to control my computing experience to the extent I do.

The reason is that I would be relying on many different applications. Each application has its own interface and design paradigms.

Each application is configured, if at all, in a way that is specific to it. Customisations in one application do not carry over to other applications.

And, if we consider the important implementation details, each application may configurable in its own programming language.

In other words, that is not an integrated computing experience.

13 Many apps do not combine nicely

To have the same degree of control that Emacs makes possible, I would have to hope that somehow all those disparate applications would conspire in my favour.

That is wishful thinking.

The reality is that piecing together many different applications is an exercise in frustration and the path to a life of ever-distracting context switching.

14 Emacs makes your workflow consistent

Having everything I need inside of Emacs ensures that things happen in a manner that is consistent.

All customisations are written in the same programming language, namely, Emacs Lisp.

What I define for one context, such as this “presentation mode”, can be used in another context.

For example, I can have this presentation style enabled when I read emails. Why?

Because it can make it more comfortable for me at a certain hour. And I can even automate this with conditional logic, so it happens on its own when I open a new email under certain circumstances.

15 Integrated computing in practice

When you work with many applications that do not play nicely together, you cannot do something that the developers have not envisaged.

For example, your email client likely does not have access to a “presentation mode”. Same for your other applications.

Similarly, your many applications will not necessarily know how to read and interpret the configurations you have in one application.

Suppose you define your favourite colour scheme for your email client. You take the time to consider the harmonies and use precise typography to your liking.

Now, you switch to your calendar application and none of that work carries over: you have to do it again, assuming it is even possible.

16 Emacs makes integration easier

Colours and styles may seem like relatively small issues. But they are indicative of something greater: disparate applications do not work together seamlessly.

Emacs does not have this problem. You define something for one context you have in mind and, eventually, it can be used in another context that initially you had not even thought of.

For example, in my Emacs I wrote a small function to quickly copy the “thing” at where the cursor is. This is useful when I do programming, as the “thing” can be an entire expression, like the definition of a function. But the “thing” may also be a link that I got in my email.

I had not thought of that use-case in advance. Yet it was trivial to have my function do what I need in this once unforeseen situation.

17 Integration gives you emergent properties

The integrated computing environment of Emacs is more than the sum of its parts.

This is because you can combine different pieces of functionality in ways that the original developer had not foresaw.

You do not simply have your writing, your email, your agenda, et cetera, in Emacs.

You have the functionality of one in tandem with the functionality of another. And you draw linkages between them as you see fit.

Consider once again this presentation I am now doing. What I have in front of me is the transcript of my talk. This is a plain text document, which I can edit live. Let me CAPITALISE THIS to illustrate the point.

18 This is plain text that works like a slideshow

I have made this file look a little bit like a series of slides.

Notice that if I scroll up and down, which I will do shortly, you only get the current section I am reading from: you do not have access to the rest of the document. I will scroll up and down now.

This is a feature known as “narrowing”. Let me “widen” the view and then try to scroll again. You will now be exposed to the rest of the text.

The original developer of this “narrowing” facility did not know how someone like me would make use of it.

I have it here for my presentation. Each heading becomes its own pseudo-slide. I have narrowing for my emails, when I want to read a portion of the text in a more focused way. It is all about how I choose to do my computing.

19 Consistency facilitates productivity

For many years before switching to Emacs, I did not enjoy using the computer.

I needed too much time to accomplish every single task.

I could never find any of my files in a timely fashion because there was no program that would enforce on my behalf a predictable file-naming scheme.

All my notes were eventually not retrievable. This made them useless. Data you save is only good if you can find what you are searching for.

My music collection was inconsistent because I needed special software to write the metadata… In short, I was not as productive as I would like to be.

And, above all, it was not fun.

20 Consistency remove the cognitive burden

Most of my work at the time was centred around the email client and a word processor.

The email client had its own subsystem for handling reminders for tasks. The format of those tasks was not interoperable with other programs.

I could not access the tasks with my favourite text editor. I thus had to use the clunky interface of the email client, which was never designed for task management—and was not configurable.

And then I had all the cognitively burdensome annoyances of my two applications looking quite different from each other.

My emails did not behave like my documents, which made it harder for me to flip between the two and continue writing. I would roll my eyes each time.

21 The consistency of Emacs in action

Emacs has elevated my computing experience.

I have been much more productive ever since I switched to it. Allow me to demonstrate a tiny bit of what I do each day.

I will temporarily exit the presentation mode in this window.

Then, in the bottom half of my screen, I will open my email client to read a message I got.

Once you follow my switch to the email client, I will hide the window that shows this presentation.

After that I will switch to my agenda to record a task and review what I have to do.

All this is done inside of Emacs. Time for action!

22 Use Emacs Lisp to configure everything

What I just demonstrated is a very small part of what I do every single day.

There is much more, though I cannot cover it all in this presentation.

The point, however, is the consistency of the experience; consistency throughout.

I have customised my email client by writing some Emacs Lisp code for it. I have done the same for the custom agenda I have. And much more.

Every time I work with Emacs Lisp, I acquire skills that are applicable outside the confines of the problem I am solving.

For example, by configuring email the way I want, I pick up programming skills that I can then apply to the design of my custom agenda.

23 Learning Emacs Lisp improves the experience

This is an investment that pays off more and more.

Emacs will adapt to match my evolving needs. Each new workflow I incorporate in my Emacs setup will thus benefit from all the knowledge and features I have accumulated.

I do not have to relearn everything because I am not switching to another application.

I do not have to throw away all the work I did all those years. It is here to stay.

I do not feel the pressure to try the new shiny app of the day. I did that many times and always regretted it. I lost my data and time in the process.

Because I am rooted in this stability of Emacs, I remain productive and efficient.

24 Emacs embodies software freedom

I mentioned earlier that Emacs is free or libre software. This means that you can read its source code, modify it, and share your changes with others.

Emacs has a license that gives users power. There is no corporation that can take Emacs away from us. It belongs to the community and we all tend to its wellness.

In the case of Emacs, software freedom is not just about the license. It informs how you use the program. Emacs makes such freedom an irriducible part of its functionality.

You can, at any moment, ask Emacs what does a keyboard shortcut actually do. What is the definition of a function. What is the value of a variable. And you may even access the source code to check for yourself.

I will demonstrate this right now.

25 The freedom of Emacs helps with learning

I actually learnt to program in Emacs Lisp by exercising this freedom.

I would tinker with Emacs and continuously check on its state. What does this do? Which function is called by that keyboard shortcut? How is a program able to determine if the file is not saved?

I wanted to learn how, for example, we move down a line. From there, I learnt that we can move down many lines at once.

I then figured that we can move down the lines and then also do something else, such as place the cursor at the end of the line and create a pulse effect to bring attention to it.

Not only did I learn how to configure Emacs, I even wrote tens of extensions for it. I have also authored a libre book titled “Emacs Lisp Elements”. This freedom is not theoretical. I did not have a background in programming, yet was empowered to act and to grow as a person.

26 Emacs is not only for programmers

Emacs is extended with Emacs Lisp. If you know how to program in that language, you can be extra opinionated and particular about the way Emacs facilitates your work.

But even without any expertise of this sort, you can still do much of what you like. Remember that I started using Emacs without a background in programming.

Emacs blurs the distinction between user and developer. Many of the developers actually start out as users like myself. They learn along the way and, eventually, they contribute to the development of Emacs.

I even have written code that is in core Emacs: my modus-themes as well as several other smaller patches.

27 You benefit from all the Emacs extensions

The Emacs community has developed a rich corpus of extensions. You do not need to invent anything right away in order to be productive.

We call these extensions “packages”, as they are distributed in a way that makes them easy to install and then use directly.

The Emacs program you will download on your computer ships with plenty of packages built-in.

Depending on your needs, you may not even have to install anything from what the community has to offer.

Though if you want a package, it is fairly easy to get it and run it on your system.

Emacs is not picky about how you should use it. You are empowered to be opinionated.

28 Some powerful extensions are built-in

For example, Emacs ships with a package called org or “Org mode”. At its core, this is a markup language. I am using it right now in this document.

Notice how lines that start with an asterisk function as headings. This is what the markup does.

Org lets you write documents, including books, handle your tasks, organise your agenda, and much more. It is a powerhouse.

There are so many things to discover in Emacs as well as the broader package ecosystem.

Emacs as a whole provides high quality documentation that explains everything.

29 The documentation culture of Emacs

When you install Emacs, you get with it plenty of technical manuals. There is also an interactive tutorial to help you make sense of the basics.

Furthermore, when you ask Emacs for help about the definition of a function or the value of a variable, you receive the documentation for the thing you are looking for.

The expectation for all contributions to the official Emacs program is that the code is well-documented and the manual is updated accordingly.

30 Most packages have high quality manuals

Core Emacs sets the standard of what good documentation looks like. Package developers follow this practice.

For example, my denote package has a manual that is over 7500 lines long. It exceeds 52000 words. In it users find detailed instructions as well as code snippets that they can copy and use outright. And this is not the exception. All my packages are like that, to the extent necessary. Most other developers do the same.

As a community, we have access to so much knowledge for free and in freedom. If we are committed enough, we can learn from others and thus become better ourselves. We do so in a spirit of sharing and caring. For me, specifically, all this was of great help. I am self-taught because I received all those great resources from the community. I consider it my duty to give back in kind.

31 Emacs has a steep learning curve

Because Emacs is extensible, there is practically no limit to what you can do with it. At least this is the case for all tasks that are text-heavy.

Emacs will just gracefully evolve to match your requirements, provided you can extend it on your own or with a relevant package.

The downside, however, is that it is not easy to become proficient in it. If you are committed, you can learn the basics within the first few days.

Though you will need to invest a few weeks or months to become skillful. It depends on how much effort you put into it, what sort of work you are doing, and what your background is.

I learnt the basics within a few days. I started writing my own Emacs Lisp within weeks. And within a year I had my modus-themes moved into core Emacs.

32 Do not skip the manuals

Several “starter kits” are available to help you get started. They set things up so that you do not need to discover everything at the outset.

The new version of Emacs (Emacs 31) will even come with a “newcomers theme”, which configures several settings in advance.

These can make the learning curve a bit smoother. For me, anything that improves the onboarding experiences is a plus.

Though I do not think that Emacs will ever become “plug and play”. This is due to its sheer depth and extensibility. It does so much that you still need to invest the time and effort into learning it.

However you start, the most reliable study involves the manuals. Those are written for the benefit of the user. Read them carefully.

33 Adjust your expectations

What I can say with confidence is that Emacs is not for tourists. You cannot switch to it with the expectation that you will have a good time right away.

No. That will not work. There simply is no shortcut to excellence.

I encourage you to take it one step at a time. Emacs will make you more productive, provided you are patient enough to unlock its virtually boundless potential.

Take it slow and be methodical. Rely on the official manual no matter your starting point. Read from it and gradually incorporate its insights into your workflow.

The community—myself included—has plenty of resources to complement that study. Blog posts, video tutorials, books… But do not skip the official manual. Learning it slowly means that you will become proficient faster than you otherwise would.

34 Why it is worth learning how to use Emacs

I already talked about the technical side of things with regard to the integrated computing environment. Now combine that with two facts:

1. Emacs is free software. This means that we as a community are its custodians.
2. GNU Emacs has been around since the 1980s. It will stay relevant for decades to come.

Emacs is not old, it is timeless. This is because it can be extended in a spirit of freedom.

Whatever new technology or idea we have as a collective, we can eventually bring it into Emacs.

This way, our integrated computing environment adapts with the times.

Thus Emacs remains ever-relevant.

35 The initial effort pays off long-term

Couched in those terms, the initial effort you will put into learning Emacs is actually not that much.

You have to maintain a longer-term view of this project.

If you are patient, Emacs will be one of the most reliable tools you will ever use throughout your life. And I say this as a handy man myself, someone who uses many tools for manual labour, having built the house I am in, among others.

I switched to Emacs in the summer of 2019. It is almost 7 years already. I see no reason not to use it for the next 7 years, if I can.

I will still want to write articles, do programming, maintain my agenda, and probably make presentations like this one.

36 Good luck and have fun!

Remember that you will not learn Emacs over the weekend. You are in it for the long-term. Take it slow and you will enjoy the experience.

This is all I have for you today folks. Thank you very much for your attention!

You can find this and everything else I publish on my website: https://protesilaos.com.

Speech synthesis has come a long way since I first tried out Emacspeak in 2002. Kokoro TTS and Piper offer more natural-sounding voices now, although the initial delay in loading the models and generating speech mean that they aren't quite ready to completely replace espeak, which is faster but more robotic. I've been using the Kokoro FastAPI through my own functions for working with various speech systems. I wanted to see if I could get Kokoro and other OpenAI-compatible text-to-speech services to work with either speechd-el or Emacspeak just in case I could take advantage of the rich functionality either provides for speech-synthesized Emacs use. speechd-el is easier to layer on top of an existing Emacs if you only want occasional speech, while emacspeak voice-enables many packages to an extent beyond speaking simply what's on the screen.

Speech synthesis is particularly helpful when I'm learning French because I can use it as a reference for what a paragraph or sentence should sound like. It's not perfect. Sometimes it uses liaisons that my tutor and Google Translate don't use. But it's a decent enough starting point. I also used it before to read out IRC mentions and compile notifications so that I could hear them even if I was paying attention to a different activity.

Here's a demonstration of speechd reading out the following lines using the code I've just uploaded to https://codeberg.org/sachac/speechd-ai:

• The quick brown fox jumps over the lazy dog.
• Now let's set the language to French so we can read the next line.
• Bonjour, je m'appelle Emacs.

There's about a 2-second delay between the command and the start of the audio for the sentence.

Note that speechd-speak-read-sentence fails in some cases where (forward-sentence 1) isn't the same place as (backward-sentence 1) (forward-sentence 1), which can happen when you're in an Org Mode list. I've submitted a patch upstream.

Aside from that, speechd-speak-set-language, speechd-speak-read-paragraph and speechd-speak-read-region are also useful commands. I think the latency makes this best-suited for reading paragraphs, or for shadowing sentences for language learning.

I'm still trying to figure out how to get speechd-speak to work as smoothly as I'd like. I think I've got it set up so that the server falls back to espeak for short texts so that it can handle words or characters better, and uses the specified server for longer ones. I'd like to get to the point where it can handle all the things that speechd usually does, like saying lines as I navigate through them or giving me feedback as I'm typing. Maybe it can use espeak for fast feedback character by character and word by word, and then use Kokoro TTS for the full sentence when I finish. Then it will be possible to use it to type things without looking at the screen.

After putting this together, I still find myself leaning towards my own functions because they make it easy to see the generated speech output to a file, which is handy for saving reference audio that I can play on my phone and for making replays almost instant. That could also be useful for pre-generating the next paragraph to make it flow more smoothly. Still, it was interesting making something that is compatible with existing protocols and libraries.

Posting it in case anyone else wants to use it as a starting point. The repository also contains the starting point for an Emacspeak-compatible speech server. See See speechd-ai/README.org for more details.

https://codeberg.org/sachac/speechd-ai

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

Code formatters. Many people swear by them and always run their code through a formatter before checking it in. I’ve never seen the need for them. I have strong feelings about code format and I always write my code to that format: no need for a separate formatter. At the same time, I recognize that others have strong feelings about their preferred format so I never want to reformat someone else’s code.

There are, in every organization, control freaks who think it critically important that everyone’s code look the same. I’ve never accepted that premise and have ignored formatting guidelines. Somehow, I’ve always managed to get away with that minor recalcitrance.

Still, some people appear to like code formatters and for those people, Bozhidar Batsov has an interesting post on code formatters and how to use them in Emacs. It turns out that there’s a plethora of formatters with slightly different behavior to choose from

Happily the Lisp languages—which I use almost exclusively these days—don’t really need one since for a Lisp, code formatting is really just a matter of indentation, which Emacs handles on its own. Other languages need more work.

One of the problems with code formatters run from within Emacs is that they can freeze Emacs while they run. This is the case of formatters that run before the file is saved. There are formatters that run after the save by asynchronously reading the saved file, reformatting it, and writing it back to disk. This has the small defect that an unformatted file exists on disk for a short while.

Batsov’s post covers reformatters implementing both methods. Some of them allow extensive configuration of the reformatting rules. Others enforce a fixed format. Take a look at Batsov’s post for a really good rundown of all the possibilities.

There is now an in-buffer replace feature in ollama-buddy, so now an ollama response can work directly on your text, streaming the replacement in real-time, and giving you a simple accept/reject choice!, I have also added an smerge diff inline if desired to show the differences and give the user the ability to accept or reject

Here is how it works : https://www.youtube.com/watch?v=Po7Wqpk0sqY

The feature is tucked away in the transient menu. Here’s the workflow:

1. Toggle it on via C-c O → Actions → W, or run M-x ollama-buddy-toggle-in-buffer-replace
2. A small ✎ indicator appears in your header line, confirming the mode is active
3. Select a region of text you want rewritten
4. Invoke a command from the role menu; for example, C-c o then pick your rewrite command
5. Watch as the AI streams the replacement directly into your buffer

It is also worth noting that each custom menu can be defined with a :destination option, for either in-buffer or chat, so the global in-buffer replace doesn’t need to be selected, and the custom transient menu can be tailored for each command. For example, in the default custom menu, refactor code and proofread have the destination of in-buffer set, but actions like git commit message or describe code will fall back to the global option, which by default is chat, which is probably what you would want for these options.

During streaming, you’ll see a dimmed, italic [Rewriting...] placeholder where your selection was. The new text then flows in with a highlight overlay.

Once the stream finishes, you’re dropped into a minor mode with two options:

C-c C-c → accept the changes (keep new text, clear highlighting)
C-c C-k → reject and restore your original text

The mode line helpfully shows [Rewrite?] while you’re deciding. It’s a bit like ediff but for AI-generated changes and uses smerge-mode.

What if the AI starts going off the rails halfway through? No problem. Press C-c C-k at any point during streaming and the network process stops immediately, restoring your original selection. No waiting for it to finish rambling!

Press C-c d and the original text gets inserted below the new text in the same buffer. Word-level differences are highlighted using smerge-refine-regions, so you can see exactly what changed at a glance.

Green overlays mark added or modified words. Red strikethrough overlays show what was removed. It’s proper granular diffing, not just a before-and-after comparison.

This workflow is particularly useful for:

• Refactoring code blocks you’ve already written
• Rephrasing documentation or prose that feels clunky
• Adjusting tone without losing your core message
• Quick grammar and style improvements

It’s less about “write this for me from scratch” and more “help me iterate on what I’ve already got.”

For best results, I’ve found that smaller, focused selections work better than trying to rewrite entire files in one go. The AI has more context to work with, and you can make more granular decisions about what to keep.

Next up is probably some more polish on the diff highlighting, or perhaps exploring how this could work with multi-file projects. But for now, again I think this implementation is good enough.

Earlier today, at 20:00 Europe/Athens time, I provided an introduction to Emacs at the event FLOSS @ Oxford: https://ox.ogeer.org/event/computing-in-freedom-with-gnu-emacs-protesilaos-stavrou.

I had written the transcript ahead of time to make my presentation more accessible. The event was held live as a Jitsi call. There were questions from participants, which I answered. A recording of the event will be available before the end of this week. I will update this article to include a link to the video.

UPDATE 2026-03-16 07:49 +0200: The video is here: https://ogeer.org/ox/rec/emacs/.

Below is the text of my talk. It is titled “Computing in freedom with GNU Emacs”. Note that some parts of my presentation only make sense in the video format, though I tried to describe in the transcript what I was demonstrating.

Table of Contents

1. Emacs as a capable text editor
2. Emacs can display graphics alongside text
3. Emacs is an extensible text editor
4. The extensibility of Emacs happens live
5. Emacs puts you in control of your computing
6. The promise of an integrated computing environment
7. The integrated computing environment in practice
8. Integration gives you emergent properties
9. Consistency facilitates productivity
10. The consistency of Emacs in action
11. Use Emacs Lisp to configure everything
12. Emacs is the embodiment of software freedom
13. You do not need to be a programmer to use Emacs
14. The documentation culture of Emacs
15. Emacs has a steep learning curve
16. Why it is worth learning how to use Emacs
17. Good luck and have fun!

Hello everyone! My name is Protesilaos, also known as “Prot”. I am joining you from the mountains of Cyprus. Cyprus is an island in the Eastern Mediterranean Sea.

In this presentation I will talk to you about GNU Emacs, or simply, “Emacs”. Emacs is a program you run on your computer. I am using it right now for this presentation.

Emacs is free or libre software. It allows you to read all of its source code, to modify it, and to share it with your customisations. Thus you contribute to—and benefit from—a community of welcoming Emacs users.

I will tell you what all this means in practice and how you can improve your computing experience by switching to Emacs.

Emacs as a capable text editor

When you first start using Emacs, it feels like a regular text editor program. You move the cursor around and edit text. Nothing obviously impressive out-of-the-box. As a text editor, Emacs is highly capable. It has all sorts of keyboard shortcuts that let you efficiently operate on text. You can control Emacs without relying on the mouse, if you want.

Emacs supports the Unicode standard, which is essential for inclusivity of peoples. The world’s scripts can be expressed in Emacs. I am a native Greek speaker. I can use functionality that is built into Emacs to switch to the Greek alphabet in order to write something, such as to say «καλησπέρα», which means “good evening”. I can even spell out “Dao De Jing” (道德经), which is the title of a book from ancient China. Plus emoji: 🙃.

The multitude of scripts can be present in the same document. This is an advantage for multilingual people or those who do research that involves many natural languages.

Emacs can combine several fonts in the same page as well as different colours. Each fonts can have its own attributes, such as for its relative size and typographic intensity. Same idea for colours. On my screen right now, I am already combining two different font styles: that of the heading and the body of the text.

Emacs can display graphics alongside text

Emacs does not limit you to a text-only interface. It can also display images and PDF documents. Below I have a link to an image file. I will now type a keyboard shortcut to reveal this image. And I will do it again to hide it.

[Here is an image that I do not need to reproduce on my website: the specific image does not matter]

This, by the way, is a spot somewhere in my mountains.

Emacs is an extensible text editor

Although you can benefit from using Emacs as a generic text editor, what really appeals to people like me is the option to extend Emacs. “Extend” here means to introduce new functionality; functionality that is not available in the default program you install on your computer.

These extensions are written in the same programming language as most of Emacs. It is a programming language called “Emacs Lisp” or “Elisp”. You can extend Emacs on your own, by writing some program in Elisp, or you can download an existing extension that the community has made available.

For example, when I create a new extension for Emacs, I publish it under the terms of a free software license—the same terms that Emacs uses. Others can then download my extension and use it as they prefer. If they want, they can make their own modifications on top, which may introduce other extensions that I had not thought of in my original implementation. And if those users follow my example, then I can also benefit from their additions once they publish them.

As such, there exists a community of enthusiastic users of Emacs who care about sharing their works with the rest of the world.

The extensibility of Emacs happens live

Users can extend Emacs by running some Emacs Lisp program. Such a program can be as small as a single line. Or it can be as long as it needs to be. It does not matter. Users run the program and Emacs immediately does what the program renders possible.

For example, I am doing this presentation inside of Emacs. But Emacs does not have a “presentation mode” built into it. I thus developed my own extension which empowers me to do what I am doing right now. Let me toggle off my presentation mode to show you what I mean.

Notice that the display has changed. My main font is monospaced now. The headings are smaller than they were before: they are the same size as the rest of the text. There is no number next to the heading anymore. Then, there is a bar at the bottom of my screen, with information about what I am working on. On the side, there are line numbers, indicating where my cursor is in this file. Plus, my current line is highlighted with a distinct background colour. Let me shift it up and down to illustrate this point.

All those elements are useful while I am programming. But they look distracting when I wish to focus on some portion of text. So, I just type the keyboard shortcut I have and—voilà!—I get the style I prefer.

Emacs puts you in control of your computing

You may wonder: why do I even need a customisable text editor? The answer is about control. You are in charge of what you use and how you use it. You can piece together a workflow that works the way you prefer.

This presentation mode I toggled on and off earlier behaves exactly how I want. I decided which set of interface tweaks to apply. Another user may have a different preference in this regard. For instance, they may like having line numbers on the side of the screen. There is no right or wrong answer. What matters is that Emacs gives us the means to do what makes sense to us.

Now apply this principle to everything you can use Emacs for: this will generally be a text-centric project. I run my agenda exclusively through Emacs. I handle all my email correspondence with Emacs. I do programming and I write prose, such as blog posts for my website and books or technical manuals.

For each of these, I know that Emacs will empower me to perform my tasks without arbitrary restrictions. Emacs lets me use Elisp to modify how I do my emails, for instance, and how I present tasks in my custom agenda view.

The promise of an integrated computing environment

Without Emacs, I would not be in a position to control my computing experience to the extent I do. The reason is that I would be relying on many different applications. Each application has its own interface and design paradigms. Each application is configured, if at all, in a way that is specific to it. Customisations in one application do not carry over to other applications. And, if we consider the important implementation details, each application may configurable in its own programming language.

In other words, that is not an integrated computing experience. To have the same degree of control that Emacs makes possible, I would have to hope that somehow all those disparate applications would conspire in my favour. That is wishful thinking. The reality is that piecing together many different applications is an exercise in frustration and the path to a life of ever-distracting context switching.

Having everything I need inside of Emacs ensures that things happen in a manner that is consistent. All customisations are written in the same programming language, namely, Emacs Lisp. What I define for one context, such as this “presentation mode”, can be used in another context. For example, I can have this presentation style enabled when I read emails. Why? Because it can make it more comfortable for me at a certain hour. And I can even automate this, so it happens on its own when I open a new email.

The integrated computing environment in practice

When you work with many applications that do not play nicely together, you cannot do something that the developers have not envisaged. For example, your email client likely does not have access to a “presentation mode”. Same for your other applications.

Similarly, your many applications will not necessarily know how to read and interpret the configurations you have in one application. Suppose you define your favourite colour scheme for your email client. You take the time to consider the harmonies and use precise typography to your liking. Now, you switch to your calendar application and none of that work carries over: you have to do it again, assuming it is even possible.

Colours and styles may seem like relatively small issues. But they are indicative of something greater: disparate applications do not work together seamlessly.

Emacs does not have this problem. You define something for one context you have in mind and, eventually, it can be used in another context that initially you had not even thought of. For example, in my Emacs I wrote a small function to quickly copy the “thing” at where the cursor is. This is useful when I do programming, as the “thing” can be an entire expression, like the definition of a function. But the “thing” may also be a link that I got in my email. I had not thought of that use-case in advance.

Integration gives you emergent properties

The integrated computing environment of Emacs is more than the sum of its parts. This is because you can combine different pieces of functionality in ways that the original developer had not foresaw. You do not simply have your writing, your email, your agenda, et cetera, in Emacs. You have the functionality of one in tandem with the functionality of another. And you draw linkages between them as you see fit.

Consider once again this presentation I am now doing. What I have in front of me is the transcript of my talk. This is a plain text document, which I can edit live. Let me CAPITALISE THIS to illustrate the point. But I have made this file look a little bit like a series of slides. Notice that if I scroll up and down, which I will do now, you only get the current section I am reading from: you do not have access to the rest of the document. This is a feature known as “narrowing”. Let me “widen” the view and then try to scroll again. You will now be exposed to the rest of the text.

The original developer of this “narrowing” facility did not know how someone like me would make use of it. I have it here for my presentation. Each heading becomes its own pseudo-slide. I have narrowing for my emails, when I want to read a portion of the text in a more focused way. It is all about how I choose to do my computing.

Consistency facilitates productivity

For many years before switching to Emacs, I did not enjoy using the computer. I needed too much time to accomplish every single task. I could never find any of my files in a timely fashion because there was no program that would enforce on my behalf a predictable file-naming scheme.

All my notes were eventually not retrievable. My music collection was inconsistent because I needed special software to write the metadata… In short, I was not as productive as I would like to be. And, above all, it was not fun.

Most of my work at the time was centred around the email client and a word processor. The email client had its own subsystem for handling reminders for tasks. The format of those tasks was not interoperable with other programs. I could not access it with my favourite text editor. I thus had to use the clunky interface of the email client, which was never designed for task management—and was not configurable.

And then I had all the cognitively burdensome annoyances of my two applications looking quite different from each other. My emails did not behave like my documents, which made it harder for me to flip between the two and continue writing.

The consistency of Emacs in action

Emacs has elevated my computing experience. I have been much more productive ever since I switched to it. Allow me to demonstrate a tiny bit of what I do each day. I will temporarily exit the presentation mode in this window. Then, in the bottom half of my screen, I will open my email client to read a message I got. After that I will switch to my agenda to record a task and review what I have to do. All this is done inside of Emacs. Time for action!

Use Emacs Lisp to configure everything

What I just demonstrated is a very small part of what I do every single day. There is much more, though I cannot cover it all in this presentation. The point, however, is the consistency of the experience; consistency throughout.

I have customised my email client by writing some Emacs Lisp code for it. I have done the same for the custom agenda I have. And much more.

Every time I work with Emacs Lisp, I acquire skills that are applicable outside the confines of the problem I am solving. For example, by configuring email the way I want, I pick up programming skills that I can then apply to the design of my custom agenda.

This is an investment that pays off more and more. Emacs will grow or shrink to match my evolving needs. Each new workflow I incorporate in my Emacs setup will thus benefit from all the knowledge and features I have accumulated.

I do not have to relearn everything. I do not have to throw away all the work I did. It is here to stay. I do not feel the pressure to try the new shiny app of the day. And, because I am rooted in this stability, I remain productive and efficient.

Emacs is the embodiment of software freedom

I mentioned earlier that Emacs is free or libre software. This means that you can read its source code, modify it, and share your changes with others. Emacs has a license that gives users power. There is no corporation that can take Emacs away from us. It belongs to the community and we all tend to its wellness.

Software freedom is not just about the license. Emacs makes such freedom an irriducible part of its functionality. You can, at any moment, ask Emacs what does a keyboard shortcut actually do. What is the definition of a function. What is the value of a variable. And you may even access the source code to check for yourself.

I actually learnt to program in Emacs Lisp by exercising this freedom. I would tinker with Emacs and continuously check on its state. I wanted to learn how, for example, we move down a line. From there, I learnt that we can move down many lines at once. I then figured that we can move down the lines and then also do something else, such as place the cursor at the end of the line and create a pulse effect to bring attention to it.

Not only did I learn how to configure Emacs, I even wrote tens of extensions for it. I have also authored a libre book titled “Emacs Lisp Elements”. This freedom is not theoretical. I did not have a background in programming, yet was empowered to act.

You do not need to be a programmer to use Emacs

Emacs is extended with Emacs Lisp. If you know how to program in that language, you can be extra opinionated and particular about the way Emacs facilitates your work.

But even without any expertise of this sort, you can still do much of what you like. This is because the Emacs community has developed a rich corpus of extensions. We call these extensions “packages”, as they are distributed in a way that makes them easy to install and then use directly.

The Emacs program you will download on your computer ships with plenty of packages built-in. Depending on your needs, you may not even have to install anything from what the community has to offer.

For example, Emacs ships with a package called org or “Org mode”. At its core, this is a markup language. I am using it right now in this document. Notice how lines that start with an asterisk function as headings. This is what the markup does. Org lets you write documents, including books, handle your tasks, organise your agenda, and much more. It is a powerhouse. There are so many things to discover. Emacs provides high quality documentation that explains everything.

The documentation culture of Emacs

When you install Emacs, you get with it plenty of technical manuals. There is also an interactive tutorial to help you make sense of the basics. Furthermore, when you ask Emacs for help about the definition of a function or the value of a variable, you receive the documentation for the thing you are looking for.

The expectation for all contributions to the official Emacs program is that the code is well-documented and the manual is updated accordingly.

This is true also for packages that the community develops. For example, my denote package has a manual that is over 7500 lines long. It exceeds 52000 words. In it users find detailed instructions as well as code snippets that they can copy and use outright. And this is not the exception. All my packages are like that, to the extent necessary. Most other developers do the same.

As a community, we have access to so much knowledge for free and in freedom. If we are committed enough, we can learn from others and thus become better ourselves. We do so in a spirit of sharing and caring. For me, specifically, all this was of great help. I am self-taught because I received all those great resources from the community. I consider it my duty to give back in kind.

Emacs has a steep learning curve

Because Emacs is extensible, there is practically no limit to what you can do with it. At least this is the case for all tasks that are text-heavy. Emacs will just gracefully evolve to match your requirements, provided you know how to extend it.

The downside, however, is that it is not easy to become proficient in it. If you are committed, you can learn the basics within the first few days. Though you will need to invest a few weeks or months to become skillful. It depends on how much effort you put into it.

What I can say with confidence is that Emacs is not for tourists. You cannot switch to it with the expectation that you will have a good time right away. No. That will not work. There simply is no shortcut to excellence.

I thus encourage you to adjust your expectations. Emacs will make you more productive, provided you are patient enough to unlock its virtually boundless potential. Take it slow and be methodical. Rely on the official manual. Read from it and gradually incorporate its insights into your workflow. The community has plenty of resources to complement that study. But do not skip the official manual. Learning it slowly means that you will become proficient faster than you otherwise would.

Why it is worth learning how to use Emacs

I already talked about the technical side of things with regard to the integrated computing environment. Now combine that with two facts:

1. Emacs is free software. This means that we as a community are its custodians.
2. GNU Emacs has been around since the 1980s. It will stay relevant for decades to come.

Emacs is not old, it is timeless. This is because it can be extended in a spirit of freedom. Whatever new technology or idea we have as a collective, we can eventually bring it into Emacs. This way, our integrated computing environment adapts with the times.

Couched in those terms, the initial effort you will put into learning Emacs is actually not that much. You have to maintain a longer-term view of this project. If are patient, Emacs will be one of the most reliable tools you will ever use throughout your life. And I say this as a handy man myself, having built the house I am in, among others.

I switched to Emacs in the summer of 2019. It is almost 7 years already. I see no reason not to use it for the next 7 years, if I can. I will still want to write articles, do programming, maintain my agenda, and probably make presentations like this one.

Good luck and have fun!

Remember that you will not learn Emacs over the weekend. You are in it for the long-term. Take it slow and you will enjoy the experience.

This is all I have for you today folks. Thank you very much for your attention!

We got quite a few agent-shell additions since the last post, so let's go through the highlights as of v0.47.1.

What's agent-shell?

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

Your employer can make a difference

agent-shell has been attracting quite a few users. Many of you are working in tech where employers are happily paying for IDE subscriptions and LLM tokens to improve productivity. If you are using agent-shell for work, consider getting your employer to give back by sponsoring the project.

I also know many of you work at AI companies offering paid agents like Claude Code, Copilot, Gemini, Codex, etc. all supported by agent-shell. Please nudge your employers to help fund projects like agent-shell, which are making their services available to more users.

So what's new?

claude-code-acp renamed to claude-agent-acp [Action Required]

Let's get this one out of the way, as it needs actioning. Both the npm package and the CLI agent have been renamed from claude-code-acp to claude-agent-acp (to align with Anthropic's branding guidelines). If you're using Claude Code, you'll need to update:

npm remove -g @zed-industries/claude-code-acp
npm install -g @zed-industries/claude-agent-acp

If you had customized agent-shell-anthropic-claude-acp-command, update it to point to claude-agent-acp.

New agents supported

• Auggie (#179 by @Pacane).
• Cline.
• Factory Droid (#178 by @ag91).
• GitHub Copilot.
• Kiro CLI (#351 by @zmjones).
• Mistral Vibe.
• Pi (#232 by @conornash)

Bootstrapped sessions (experimental)

This was a biggie. How sessions are loaded is now configurable via agent-shell-session-strategy. When set to 'new, starting a new shell delivers a fully bootstrapped session before presenting you with the shell prompt. This means the ACP handshake, authentication, and session creation all happen upfront.

You can enable this flow with:

(setq agent-shell-session-strategy 'new)

What's the benefit? Bootstrapped sessions enable changing models and session modes (Planning, Don't ask, Skip permissions, etc…) before submitting your first prompt.

For the time being, the existing (deferred) behaviour is still offered via 'new-deferred. Just set as follows:

(setq agent-shell-session-strategy 'new-deferred)

Session resume (experimental)

Probably the most requested feature and also facilitated by the bootstrapping changes. agent-shell-session-strategy also unlocks session resume. Set it to 'prompt and every time either M-x agent-shell-new-shell or C-u M-x agent-shell are invoked, you'll be offered to resume previous sessions or start a new one.

(setq agent-shell-session-strategy 'prompt)

Alternatively, you can set to 'latest to always resume the most recent session in current project.

Under the hood, there are two ways to pick up from previous session: session/resume (lightweight, no message replay) and session/load (full history replay). By default, agent-shell prefers resuming (controlled by agent-shell-prefer-session-resume). Please favor resuming for the time being as loading has more edge cases to sort out still.

Note: Both resuming and loading sessions are agent-dependent. Some agents may not yet support either, especially as the features aren't yet considered stable in Agent Client Protocol (see session/list spec).

This feature was a collaboration between @farra, @travisjeffery, and myself.

Clipboard images

You can now use agent-shell-send-clipboard-image (#285 by @dangom) to send images straight from your clipboard into agent-shell. Clipboard images are saved to .agent-shell/screenshots in your project root and inserted into the shell buffer as context.

Note: You'll need either pngpaste or xclip installed on your system for the feature to automatically kick in.

In addition, we now have agent-shell-yank-dwim: if the clipboard has an image, it pastes it as context. Otherwise, it yanks text as usual. In other words, copy an image anywhere to your system's clipboard and paste/yank into the buffer as usual (typically via C-y).

Status display + tool calls

Status labels and tool call titles rendering got some improvements. Status reporting is generally more compact, redundant text is dropped from tool call titles, and tool status/kind shortening has been consolidated.

Image rendering

agent-shell now renders images inline. When agents output images (charts, diagrams, screenshots, etc.), they display directly in the shell buffer. You may need to nudge the agent to output image paths in the expected format so agent-shell can pick up.

Markdown images:

![alt text](/path/to/image.png)

Any of the following in a line of their own are supported also:

/path/to/image.png

file:///path/to/image.png

./output/chart.png
~/screenshots/demo.png

Recognized image formats depend on what your Emacs was built with (typically png, jpeg, gif, svg, webp, tiff, etc. via image-file-name-extensions).

Emacs skills

While on the topic of image rendering, this works particularly well when coupled with charting agent skills. I shared some of these over at emacs-skills, demoed in episode 13 of the Bending Emacs series.

Table rendering

Tables are now rendered using overlays (#17 by @ewilderj).

Usage tracking

Tracking usage now possible (#270 by @Lenbok):

• A color-coded context usage indicator in the header (green -> yellow -> red as context fills up), enabled by default via agent-shell-show-context-usage-indicator.
• M-x agent-shell-show-usage to check token counts, context window usage, and cost in the minibuffer.r- An optional end-of-turn usage summary can be enabled via (setq agent-shell-show-usage-at-turn-end t).

Git worktree shell

If keen to run multiple agents on the same repo without stepping on each other's work, M-x agent-shell-new-worktree-shell facilitates this via git worktrees (#255 by @nhojb).

Send context to…

You can now send context to a specific shell using agent-shell-send-file-to, agent-shell-send-region-to, agent-shell-send-clipboard-image-to. and agent-shell-send-screenshot-to. These prompt you to pick a target shell.

Both M-x agent-shell and agent-shell-send-dwim are now prefix-aware. C-u forces a new shell, while C-u C-u prompts you to pick a target shell.

Compose buffer improvements

Compose buffers now support file (via @) and command (via /) completions. It is now also possible to browse previous pages via C-c C-p and come back to your prompt draft.

There's also prompt history navigation/insertion when composing prompts via M-p (previous), M-n (next), and M-r (search).

Bringing context into viewport compose buffers is now more robust. For example, carrying context into a new viewport compose buffer is now supported (#383 by @liaowang11).

Viewport improvements

While viewport interaction was introduced in the previous post, it is now my preferred way of interacting with agent-shell. You can enable via (setq agent-shell-prefer-viewport-interaction t). In any case, viewport buffers got a handful of quality-of-life improvements.

Single key replies without needing to open a compose/reply buffer:

• y sends "yes" (handy for quickly answering agent questions).
• 1-9 sends digits (handy for quickly choosing options).
• m sends "more" (handy for requesting more of the same kind of data).
• a sends "again" (handy for requesting to carry out instructions again).

Customizable context sources

agent-shell-context-sources lets you configure which DWIM context sources are considered by M-x agent-shell, agent-shell-send-dwim, and compose buffers. You can control the order sources are checked and add custom functions. Defaults to files, region, error, and line.

I'm always on the lookout for some DWIM goodness. If you add your own context function, I'd love to hear about it.

Flycheck support

While on the topic of context sources, in addition to picking up flymake errors at point, flycheck errors are now automatically recognized (#219 by @Lenbok).

Diff improvements

Diff buffers got some love too, now with syntax highlighting (#198 by @Azkae). There's also a new agent-shell-diff-mode-map for customizing diff keybindings, which avoid inheriting unsupported features from the parent mode. You can also press f to open the modified file from a diff buffer.

Additionally, you can now press C-c C-c from an agent-shell-diff buffer to reject all changes (same binding as the shell itself).

Event subscriptions

You can now programmatically subscribe to agent-shell events like initialization steps, tool call updates, file writes, permission responses, permission requests, and turn completions. This opens the door for building integrations on top of agent-shell.

(agent-shell-subscribe-to
 :shell-buffer (current-buffer)
 :event 'file-write
 :on-event (lambda (event)
             (message "File written: %s"
                      (alist-get :path (alist-get :data event)))))

Permission UX improvements

Permission dialogs got a few improvements. Amongst them, automatic navigation to the next pending dialog and also making executed commands more prominent for some agents.

Permission responder function

You can now programmatically respond to permission requests via agent-shell-permission-responder-function. A built-in agent-shell-permission-allow-always handler is provided to auto-approve everything (use with caution):

(setq agent-shell-permission-responder-function #'agent-shell-permission-allow-always)

Claude Code OAuth token support

OAuth token now supported for Claude Code (#339 by @chemtov).

Transcript improvements

Markdown transcripts generation needed love. Thank you @Idorobots and @systemfreund for the improvements (#374, #325, and #326).

Session ID display

With (setq agent-shell-show-session-id t), session IDs are now displayed in header as well as session lists (#363 by @Cy6erBr4in).

Custom CWD function

agent-shell-cwd-function now enables customizing how agent-shell determines the working directory sent to agents.

Configurable dot-subdir location

agent-shell-dot-subdir-function now lets you customize where agent-shell keeps per-project files (#378 by @zackattackz).

Lambda MCP servers

agent-shell-mcp-servers now accept lambda functions too (#237 by @matthewbauer). Useful for setups like claude-code-ide using dynamic MCP details.

Buffer name format

agent-shell-buffer-name-format now makes buffer naming configurable. Choose between the default title case ("Claude Code Agent @ My Project"), kebab-case ("claude-code-agent @ my-project"), or provide your own function (#256 by @nhojb).

Inhibit minor modes during writes

agent-shell-write-inhibit-minor-modes lets you temporarily disable modes (like auto-formatting entire file) when agents write files (#224 by @ultronozm).

File autocompletion performance

File autocompletion is now more performant for larger repositories (#262 by @perfectayush).

Container modeline indicator

When running shells inside a container, a [C] indicator now shows up in the modeline (#250 by @ElleNajt).

Graphical header improvements

Graphical header rendering is more robust now (#275 by @nhojb).

Busy throbber display options

The busy/working indicator now offers multiple visual styles, customizable via agent-shell-busy-indicator-frames (#280 by @Lenbok).

New related packages

• agent-shell-to-go: Interact with agent-shell sessions from your mobile or any other device via Slack (by @ElleNajt).
• meta-agent-shell: Multi-agent coordination system for agent-shell with inter-agent communication, task tracking, and project-level dispatching (by @ElleNajt).
• agent-shell-workspace: Dedicated tab-bar workspace for managing multiple agent-shell sessions (by @gveres).

Pull requests

Thank you to all contributors for these improvements!

• #159: Improve Mistral Vibe documentation (@KaiHa)
• #162: Fix agent-shell-help-menu binding (@jinnovation)
• #164: Fix nil-check semantics in when-let (@jinnovation)
• #166: Use project-name for buffer names (@catern)
• #169: Resolve @mentioned paths in devcontainers (@fritzgrabo)
• #173: Fix when-let binding issue (@byronclark)
• #178: Add Factory Droid capability (@ag91)
• #179: Add Auggie support (@Pacane)
• #185: Update OpenCode logo (@bps)
• #186: Use context in viewport mode (@byronclark)
• #193: Handle user_message_chunk session update type (@Lenbok)
• #196: Fix agent names when config icons are off (@budevg)
• #197: Function-based container command runner (@rpoisel)
• #198: Syntax highlighting in diffs (@Azkae)
• #199: Fix reply in viewport mode (@byronclark)
• #200: Prevent context from own agent-shell buffer (@juboba)
• #204: Terminal-mode status labels (@whhone)
• #206: Add Evil section to README (@juboba)
• #208: Theme-aware status label color (@whhone)
• #209: Add missing image require (@timvisher)
• #212: Simplify language detection (@necaris)
• #213: Improve file and command completion (@necaris)
• #214: Fix auto-insert variable declaration (@ultronozm)
• #219: Flycheck error context support (@Lenbok)
• #224: Inhibit minor modes during file writes (@ultronozm)
• #226: Deduplicate file link (@bixuanzju)
• #232: Add Pi coding agent (@conornash)
• #235: Fix empty list normalizer (@ROCKTAKEY)
• #237: Lambda MCP servers (@matthewbauer)
• #240: Fix viewport shell buffer association (@Rutherther)
• #245: Fix :tool-calls state maintenance (@vermiculus)
• #246: Respect viewport visits for buffer ordering (@Rutherther)
• #249: Fix tool call title duplication (@ElleNajt)
• #250: Container modeline indicator (@ElleNajt)
• #252: Document C-c C-c to send (@HIRANO-Satoshi)
• #255: Git worktree shell (@nhojb)
• #256: Buffer name format customization (@nhojb)
• #257: Fix kebab-case project name (@nhojb)
• #262: File autocompletion speedup (@perfectayush)
• #266: Guard permission title rendering (@budevg)
• #269: Add missing paren (@Rutherther)
• #270: Session usage tracking (@Lenbok)
• #272: Update Copilot ASCII art (@ewilderj)
• #275: Graphical header improvements (@nhojb)
• #279: Add agent-shell-send-dwim to transient (@matthewbauer)
• #280: Busy throbber options (@Lenbok)
• #285: Clipboard image pasting (@dangom)
• #289: Session list/load/resume (@farra, @travisjeffery)
• #291: Normalize tool call commands (@ultronozm)
• #292: Strip text properties from copied text (@ultronozm)
• #293: Restore usage indicator color (@Lenbok)
• #295: Handle tools without a command (@byronclark)
• #296: Handle nil tool-call command (@genegoykhman)
• #299: claude-code-acp -> claude-agent-acp rename (@byronclark)
• #312: Function-valued model ID (@lgfang)
• #316: Fix diff syntax highlighting (@Azkae)
• #318: Tool call parameters in transcripts (@systemfreund)
• #319: Fix terminal Emacs font crash (@eddof13)
• #325: Log agent thoughts in transcript (@Idorobots)
• #326: Fix nested backtick fences in transcript (@systemfreund)
• #328: Switch modes in agent-shell-diff (@wmedrano)
• #329: Fix tests (@timvisher-dd)
• #313: Bring "Start a new session" to the top (@catern)
• #335: Fix plan from request_permission (@Azkae)
• #339: OAuth token support for Anthropic (@chemtov)
• #350: Prepare devcontainer package extraction (@fritzgrabo)
• #351: Add Kiro CLI ACP support (@zmjones)
• #353: Fix xclip blocking on X11 (@chemtov)
• #363: Configurable session selection columns (@Cy6erBr4in)
• #370: Fix permission UI on out-of-order status updates (@xar7)
• #374: Indent markdown headers in transcript (@systemfreund)
• #376: Fix file skip check (@zackattackz)
• #378: Configurable dot-subdir location (@zackattackz)
• #382: Permission-request and turn-complete subscription events (@emil-e)
• #383: Viewport context on first open (@liaowang11)
• #385: Fix leading space in terminal prompt (@bcc32)
• #388: Apply dir-local variables in shell buffer (@fritzgrabo)

Bug fixes

• #168: replace-buffer-contents timeout to prevent freeze on large diffs
• #170: Suppress effects of find-file-noselect during agent writes
• #175: ACP configuration JSON-RPC inserted into shell
• #180: Terminal-friendly keybindings
• #189: Changing the model with Claude causes hang
• #191: user_message_chunk session updates no longer dump raw JSON
• #220: Python comments no longer interpreted as Markdown headers
• #265: session/request_permission with argv array commands
• #297: Unexpected tool-call command type error
• #300: agent-shell-send-region no longer fails silently without a region
• #303: Context insertion for new deferred sessions
• #319: Fix "Wrong type argument: font, unspecified" in terminal Emacs (fix by @eddof13)
• #335: Plan not displaying from session/request_permission (fix by @Azkae)
• #345: Out of turn notifications inserted into shell
• #353: xclip handler blocking on X11 when clipboard has no image (fix by @chemtov)
• #361: loadSession regression
• #370: Permission UI not reacting on status failed/completed (fix by @xar7)
• #376: File skip check using full path instead of filename only (fix by @zackattackz)
• #385: Leading space in agent-shell-select-config prompt in terminal frames (fix by @bcc32)

Lots of polish

Beyond what's showcased, I've poured much love and effort into polishing the agent-shell experience. Interested in the nitty-gritty? Have a look through my regular commits.

Make the work sustainable

If agent-shell is useful to you, please consider sponsoring the project. These days, I've been working on agent-shell daily.

LLM tokens aren't free, and neither is the time dedicated to building this stuff. While I now have more time to work on agent-shell as an indie dev, I also have bills to pay ;)

Unless I can make this work sustainable, I will have to shift my focus to work on something else that is.

I am currently reading Clojure for the brave and true by Daniel Higginbotham and in Chapter 2 about how to use Emacs for Clojure, there are instructions on how to set up Emacs with Cider, a Clojure REPL. I tried installing the package with a use-package configuration with :ensure t and I got the package. However, when I tried using it as the book instructed, I just got an error. I then realised the need for OpenJDK and Clojure and installed those with my home-config.scm file in Guix. I tried again and I still got the same error. I then tried installing emacs-cider from Guix as well with the hope that maybe there was some kind of incompatibility between OpenJDK, Clojure and Cider that was ironed out in the guix package. It still did not work.

I tried looking up the error and found a blog post that suggested installing OpenJDK non-Guixily by downloading a binary and adding it to the $PATH which solved the problem for that user. I did not really want this, since I really like the idea of installing my whole system with a scheme file or two in a reproducible way. (I'm not there yet, but I hope to get there over time. I just started using Guix as my main distro a few weeks ago. For now, after installing Guix System or Guix on another distro, I do some manual work and then run a Shell script to set up a few folders and run the command that applies my home-config.)

Tonight, a day later, I DuckDuckWent again and found another blog post about Clojure that told me that since there are three outputs for the openjdk package, to get everything I would need for Clojure, I should install openjdk:jdk, not simply openjdk which would give me openjdk:out. In addition, I also added openjdk:doc since I am a fan of having as much documentation as possible available on my local machine. I saw a video where that documentation was read from inside Cider a couple of days ago, so I thought it might come in handy. Come to think of it, maybe that was accessed over the internet, not from the local machine. Anyway, it doesn't hurt to have some documentation.

And now, everything just works. Turns out the problem was just user error. Whenever there are multiple outputs of a package in Guix, it is important to know what you get with each output and choose accordingly. As someone who just recently switched my main machine to Guix, this is very useful information that I had not seen before. I thought I would write this up in a blog post so people out there trying to fix the same problem have a chance of finding a solution faster than I did, and for my own future reference.

Over at The Art of Not Asking Why, JTR has a nice post on attaching an image file to an Org file and displaying it inline. He begins by reviewing how to display an image file inline in an Org file and how to attach any file to an Org file. Most experienced Org users are familiar with all this. I used them just the other day to attach a delivery receipt for my tax papers to my accountant.

It’s the second half of his post that’s interesting. It turns out that when you attach a file to an Org file, the link to the attached file is added to org-stored-links just as if you had run org-store-link (bound to Ctrl+c l by default). That means you can insert the image in line by simply running org-insert-link (bound to Ctrl+c Ctrl+l by default) as usual.

Take a look at JTR’s post for all the details. If you often attach image files to an Org file and want to display them inline as well, this workflow is easy and efficient.

I got inspired to look into this topic after receiving the following obscure bug report for neocaml:

I had your package installed. First impressions were good, but then I had to uninstall it. The code formatting on save stopped working for some reason, and the quickest solution was to revert to the previous setup.

I found this somewhat entertaining – neocaml is a major mode, it has nothing to do with code formatting. But I still started to wonder what kind of setup that user might have. So here we are!

Code formatting is one of those things that shouldn’t require much thought – you pick a formatter, you run it, and your code looks consistent. In practice, Emacs gives you a surprising number of ways to get there, from built-in indentation commands to external formatters to LSP-powered solutions. This article covers the landscape and helps you pick the right approach.

One thing to note upfront: most formatting solutions hook into saving the buffer, but there are two distinct patterns. The more common one is format-then-save (via before-save-hook) – the buffer is formatted before it’s written to disk, so the file is always in a formatted state. The alternative is save-then-format (via after-save-hook) – the file is saved first, then formatted and saved again. The second approach can be done asynchronously (the editor doesn’t block), but it means the file is briefly unformatted on disk. Keep this distinction in mind as we go through the options.

Built-in: Indentation, Not Formatting

Let’s get the terminology straight. Emacs has excellent built-in indentation support, but indentation is not the same as formatting. indent-region (C-M-\) adjusts leading whitespace according to the major mode’s rules. It won’t reformat long lines, reorganize imports, add or remove blank lines, or apply any of the opinionated style choices that modern formatters handle.

That said, for many languages (especially Lisps), indent-region on the whole buffer is all the formatting you’ll ever need:

;; A simple indent-buffer command (Emacs doesn't ship one)
(defun indent-buffer ()
  "Indent the entire buffer."
  (interactive)
  (indent-region (point-min) (point-max)))

Tip: whitespace-cleanup is a nice complement – it handles trailing whitespace, mixed tabs/spaces, and empty lines at the beginning and end of the buffer. Adding it to before-save-hook keeps things tidy:

(add-hook 'before-save-hook #'whitespace-cleanup)

Shelling Out: The DIY Approach

The simplest way to run an external formatter is shell-command-on-region (M-|). With a prefix argument (C-u M-|), it replaces the region with the command’s output:

C-u M-| prettier --stdin-filepath foo.js RET

(The --stdin-filepath flag doesn’t read from a file – it just tells Prettier which parser to use based on the filename extension.)

You can wrap this in a command for repeated use:

(defun format-with-prettier ()
  "Format the current buffer with Prettier."
  (interactive)
  (let ((point (point)))
    (shell-command-on-region
     (point-min) (point-max)
     "prettier --stdin-filepath foo.js"
     (current-buffer) t)
    (goto-char point)))

This works, but it’s fragile – no error handling, no automatic file type detection, and cursor position is only approximately preserved. For anything beyond a quick one-off, you’ll want a proper package.

reformatter.el: Define Your Own (Re)Formatters

reformatter.el is a small library that generates formatter commands from a simple declaration. You define the formatter once, and it creates everything you need:

(reformatter-define black-format
  :program "black"
  :args '("-q" "-")
  :lighter " Black")

This single form generates three things:

• black-format-buffer – format the entire buffer
• black-format-region – format the selected region
• black-format-on-save-mode – a minor mode that formats on save

Enabling format-on-save is then just:

(add-hook 'python-mode-hook #'black-format-on-save-mode)

reformatter.el handles temp files, error reporting, and stdin/stdout piping. It also supports formatters that work on files instead of stdin (via :stdin nil and :input-file), and you can use buffer-local variables in :program and :args for per-project configuration via .dir-locals.el.

I love the approach taken by this package! It’s explicit, you see exactly what’s being called, and the generated on-save mode plays nicely with the rest of your config.

format-all: Zero Configuration

format-all takes a different approach – it auto-detects the right formatter for 70+ languages based on the major mode. You don’t define anything; it just works:

(add-hook 'prog-mode-hook #'format-all-mode)
(add-hook 'prog-mode-hook #'format-all-ensure-formatter)

The main command is format-all-region-or-buffer. The format-all-mode minor mode handles format-on-save. If you need to override the auto-detected formatter, set format-all-formatters (works well in .dir-locals.el):

;; In .dir-locals.el -- use black instead of autopep8 for Python
((python-mode . ((format-all-formatters . (("Python" black))))))

;; Or in your init file
(setq-default format-all-formatters '(("Python" black)))

The trade-off is less control – you’re trusting the package’s formatter database, and debugging issues is harder when you don’t see the underlying command.

apheleia: Async and Cursor-Aware

apheleia is the most sophisticated option. It solves two problems the other packages don’t:

1. Asynchronous formatting – it runs the formatter after save, so the editor never blocks. If you modify the buffer before formatting completes, the result is discarded.
2. Cursor preservation – instead of replacing the entire buffer, it applies changes as RCS patches (a classic diff format from one of the earliest version control systems), so your cursor position and scroll state are maintained.

;; Enable globally
(apheleia-global-mode +1)

apheleia auto-detects formatters like format-all, but you can configure things explicitly:

;; Chain multiple formatters (e.g., sort imports, then format)
(setf (alist-get 'python-mode apheleia-mode-alist)
      '(isort black))

Formatter chaining is a killer feature – isort then black, eslint then prettier, etc. No other package handles this as cleanly.

Caveat: Because apheleia formats after save, the file on disk is briefly in an unformatted state. This is usually fine, but it can confuse tools that watch files for changes. It also doesn’t support TRAMP/remote files.

LSP: eglot and lsp-mode

If you’re already using a language server, formatting is built in. The language server handles the formatting logic, and Emacs just sends the request.

eglot (built-in since Emacs 29)

The main commands are eglot-format (formats the active region, or the entire buffer if no region is active) and eglot-format-buffer (always formats the entire buffer).

Format-on-save requires a hook – eglot doesn’t provide a toggle for it:

(add-hook 'eglot-managed-mode-hook
          (lambda ()
            (add-hook 'before-save-hook #'eglot-format-buffer nil t)))

The nil t makes the hook buffer-local, so it only fires in eglot-managed buffers.

lsp-mode

The equivalents here are lsp-format-buffer and lsp-format-region.

lsp-mode has a built-in option for format-on-save:

(setq lsp-format-buffer-on-save t)

It also supports on-type formatting (formatting as you type closing braces, semicolons, etc.) via lsp-enable-on-type-formatting, which is enabled by default.

LSP Caveats

• Formatting capabilities depend entirely on the language server. Some servers (like gopls or rust-analyzer) have excellent formatters; others may not support formatting at all.
• The formatter’s configuration lives outside Emacs – in .clang-format, pyproject.toml, .prettierrc, etc. This is actually a feature if you’re working on a team, since the config is shared.
• LSP formatting can be slow for large files since it’s a round-trip to the server process.

Which Approach Should You Use?

There’s no single right answer, but here’s a rough guide:

• Lisps and simple indentation needs: Built-in indent-region is probably all you need.
• Specific formatter, full control: reformatter.el – explicit, simple, and predictable.
• Many languages, minimal config: format-all or apheleia. Pick apheleia if you want async formatting and cursor stability.
• Already using LSP: Just use eglot-format / lsp-format-buffer. One less package to maintain.
• Mixed setup: Nothing stops you from using LSP formatting for some languages and reformatter.el for others. Just be careful not to have two things fighting over format-on-save for the same mode.

Tip: Whichever approach you choose, consider enabling format-on-save per project via .dir-locals.el rather than globally. Not every project uses the same formatter (or any formatter at all), and formatting someone else’s unformatted codebase on save is a recipe for noisy diffs.

;; .dir-locals.el
((python-mode . ((eval . (black-format-on-save-mode)))))

Epilogue

So many options, right? That’s so Emacs!

I’ll admit that I don’t actually use any of the packages mentioned in this article – I learned about all of them while doing a bit of research for alternatives to the DIY and LSP approaches. That said, I have a very high opinion of everything done by Steve Purcell (author of reformatter.el, many other Emacs packages, a popular Emacs Prelude-like config, and co-maintainer of MELPA) and Radon Rosborough (author of apheleia, straight.el, and the Radian Emacs config), so I have no issue endorsing packages created by them.

I’m in camp LSP most of the time these days, and I’d guess most people are too. But if I weren’t, I’d probably take apheleia for a spin. Either way, it’s never bad to have options, right?

There are languages where LSP isn’t as prevalent – all sorts of Lisp dialects, for instance – where something like apheleia or reformatter.el might come in handy. But then again, in Lisps indent-region works so well that you rarely need anything else. I’m a huge fan of indent-region myself – for any good Emacs mode, it’s all the formatting you need.

In the previous article in the Emacs ways series we did a little jive on copying files from one source location to a destination location. As you can imagine, this keeps a copy in the source location and creates a copy in the destination location—exactly what you would expect.

Now, what if you don’t want a copy in the source location, but want to move that file completely to a different location? Or, what if you wanted to keep the source file in place but merely change the name?

This is where the UNIXy way of doing things can be a little confusing, and I think the Emacs way is superior, but I will let you be the judge of that.

If you are a writer interested in introducing open source tools into your workflow, you will love my DRM-free eBooks:

• Emacs For Writers
• Git For Writers

Now let’s get into some Emacs fun.

mv old_name.txt new_name.txt
mv file.txt /path/to/destination/
mv -v *.org ~/documents/

$ mv -v old_name.txt new_name.txt
renamed 'old_name.txt' -> 'new_name.txt'

$ mv -v report.txt ~/documents/
renamed 'report.txt' -> '/home/user/documents/report.txt'

$ mv -v *.org ~/documents/
renamed 'notes.org' -> '/home/user/documents/notes.org'
renamed 'todo.org' -> '/home/user/documents/todo.org'

  /home/user/projects:
  -rw-r--r--  1 user user 1234 Jan  8 14:22 draft.txt

Rename draft.txt to: final.txt

 Rename from (regexp): \.txt$
 Rename to: .org

   /home/user/notes:
 * -rw-r--r--  1 user user 1234 Jan  8 14:22 ideas.txt
 * -rw-r--r--  1 user user 5678 Jan  7 09:15 plans.txt

Rename ideas.txt to ideas.org? (y or n) y
Rename plans.txt to plans.org? (y or n) y

The post The Emacs Way: Moving and Renaming Files appeared first on Chris Maiorana.

Writing quizzes in Canvas is, to put it mildly, a pain in the neck, especially for keyboard-centric users. Every tiny step in the process requires a mouse click, something that quickly becomes irritating. Fortunately, the New York Institute of Technology provides the Canvas Exam Converter which takes a formatted text file and converts to an XML file that Canvas can import. This means that, with a little help from Emacs, writing quizzes that can be quickly imported into Canvas is quick and easy. (See my 2024 post, Converting Org Files to Canvas Quizzes for details.)

Coming up with good questions is still a challenge, though. It turns out that Claude is very effective at writing good multiple choice questions from a document. The questions are formatted like this:

**Question 1:** According to Aristotle, which of the following best describes distributive justice?

- A) Restoring equality after a wrong has been committed
- B) Equality of ratios based on factors like merit, need, or virtue
- C) Following the laws of society without exception
- D) Maximizing overall welfare for the greatest number of people

---

**Question 2:** Which of the following is a criticism of the Utilitarian approach to punishment?

- A) It fails to consider the consequences of punishment
- B) It relies too heavily on retribution
- C) It can justify punishing the innocent if doing so maximizes good outcomes
- D) It requires the punishment to exactly fit the crime

To run my conversion function for sending to NYIT, I first need it in this form:

1. According to Aristotle, which of the following best describes distributive justice?
     a) Restoring equality after a wrong has been committed
     b) Equality of ratios based on factors like merit, need, or virtue
     c) Following the laws of society without exception
     d) Maximizing overall welfare for the greatest number of people
2. Which of the following is a criticism of the Utilitarian approach to punishment?
     a) It fails to consider the consequences of punishment
     b) It relies too heavily on retribution
     c) It can justify punishing the innocent if doing so maximizes good outcomes
     d) It requires the punishment to exactly fit the crime

For weeks, I’ve been converting them a series of regex search and replace operations, but why do that every time? One of the main reasons I use Emacs is to avoid repetitive, tedious tasks. Here’s the function:

(defun convert-quiz-claude-to-org ()
  "Convert markdown-style quiz questions from Claude to Org mode format. Operates on the current buffer or active region."
  (interactive)
  (let ((start (if (use-region-p) (region-beginning) (point-min)))
          (end   (if (use-region-p) (region-end)       (point-max)))
          (question-num 0))
    (save-excursion
      ;; Remove '---' separator lines
      (goto-char start)
      (while (re-search-forward "^---\n?" end t)
          (replace-match ""))

      ;; Convert **Question N:** to "N."
      (goto-char start)
      (while (re-search-forward "^\\*\\*Question [0-9]+:\\*\\* " end t)
          (setq question-num (1+ question-num))
          (replace-match (format "%d. " question-num)))

      ;; Convert "- A)" "- B)" etc. to "     a)"  "     b)" etc.
      (goto-char start)
      (while (re-search-forward "^- \\([A-D]\\))" end t)
          (replace-match (format "     %s)" (downcase (match-string 1)))))

      ;; Remove blank lines
      (goto-char start)
      (while (re-search-forward "^[[:blank:]]*\n" end t)
          (replace-match "")))))

During the sessions with my French tutor, I share a Google document so that we can mark the words where I need to practice my pronunciation some more or tweak the wording. Using Ctrl+B to make the word as bold is an easy way to make it jump out.

I used to copy these changes into my Org Mode notes manually, but today I thought I'd try automating some of it.

First, I need a script to download the HTML for a specified Google document. This is probably easier to do with the NodeJS library rather than with oauth2.el and url-retrieve-synchronously because of various authentication things.

require('dotenv').config();
const { google } = require('googleapis');

async function download(fileId) {
  const auth = new google.auth.GoogleAuth({
    scopes: ['https://www.googleapis.com/auth/drive.readonly'],
  });
  const drive = google.drive({ version: 'v3', auth });
  const htmlRes = await drive.files.export({
    fileId: fileId,
    mimeType: 'text/html'
  });
  return htmlRes.data;
}

async function main() {
  console.log(await download(process.argv.length > 2 ? process.argv[2] : process.env['DOC_ID']));
}

main();

Then I can wrap a little bit of Emacs Lisp around it.

(defvar my-google-doc-download-command
  (list "nodejs" (expand-file-name "~/bin/download-google-doc-html.cjs")))

(defun my-google-doc-html (doc-id)
  (when (string-match "https://docs\\.google\\.com/document/d/\\(.+?\\)/" doc-id)
    (setq doc-id (match-string 1 doc-id)))
  (with-temp-buffer
    (apply #'call-process (car my-google-doc-download-command)
           nil t nil (append (cdr my-google-doc-download-command) (list doc-id)))
    (buffer-string)))

(defun my-google-doc-clean-html (html)
  "Remove links on spaces, replace Google links."
  (let ((dom (with-temp-buffer
               (insert html)
               (libxml-parse-html-region))))
    (dom-search
     dom
     (lambda (o)
       (when (eq (dom-tag o) 'a)
         (when (and (dom-attr o 'href)
                    (string-match "https://\\(www\\.\\)?google\\.com/url\\?q=" (dom-attr o 'href)))
           (let* ((parsed (url-path-and-query
                           (url-generic-parse-url (dom-attr o 'href))))
                  (params (url-parse-query-string (cdr parsed))))
             (dom-set-attribute o 'href (car (assoc-default "q" params #'string=)))))
         (let ((text (string= (string-trim (dom-text o)) "")))
           (when (string= text "")
             (setf (car o) 'span))))
       (when (and
              (string-match "font-weight:700" (or (dom-attr o 'style) ""))
              (not (string-match "font-style:normal" (or (dom-attr o 'style) ""))))
         (setf (car o) 'strong))
       (when (dom-attr o 'style)
         (dom-remove-attribute o 'style))))
    ;; bold text is actually represented as font-weight:700 instead
    (with-temp-buffer
      (svg-print dom)
      (buffer-string))))

(defun my-google-doc-org (doc-id)
  "Return DOC-ID in Org Mode format."
  (pandoc-convert-stdio (my-google-doc-clean-html (my-google-doc-html doc-id)) "html" "org"))

I have lots of sections in that document, including past journal entries, so I want to get a specific section by name.

(defun my-org-get-subtree-by-name (org-text heading-name)
  "Return ORG-TEXT subtree for HEADING-NAME."
  (with-temp-buffer
    (insert org-text)
    (org-mode)
    (goto-char (point-min))
    (let ((org-trust-scanner-tags t))
      (car (delq nil
                 (org-map-entries
                  (lambda ()
                    (when (string= (org-entry-get (point) "ITEM") heading-name)
                      (buffer-substring (point) (org-end-of-subtree))))))))))

Now I can get the bolded words from a section of my notes, with just a sentence for context. I use pandoc to convert it to Org Mode syntax.

(defvar my-lang-words-for-review-context-function 'sentence-at-point)
(defvar my-lang-tutor-notes-url nil)
(defun my-lang-tutor-notes (section-name)
  (my-org-get-subtree-by-name
   (my-google-doc-org my-lang-tutor-notes-url)
   section-name))

(defun my-lang-words-for-review (section)
  "List the bolded words for review in SECTION."
  (let* ((section (my-lang-tutor-notes section))
         results)
    (with-temp-buffer
      (insert section)
      (org-mode)
      (goto-char (point-min))
      (org-map-entries
       (lambda ()
         (org-end-of-meta-data t)
         (while (re-search-forward "\\*[^* ].*?\\*" nil t)
           (cl-pushnew
            (replace-regexp-in-string
             "[ \n ]+" " "
             (funcall my-lang-words-for-review-context-function))
            results
            :test 'string=)))))
    (nreverse results)))

For example, when I run it on my notes on artificial intelligence, this is the list of bolded words and the sentences that contain them.

(my-lang-words-for-review "Sur l'intelligence artificielle")

• Je l'ai aussi utilisée pour faire des recherches.
• Je peux consacrer une petite partie de mon budget à des essais, mais je ne veux pas travailler davantage pour rentabiliser une dépense plus importante.
• Je n'ai pas le temps de concentration nécessaire pour justifier l'investissement dans mon propre matériel, et sinon, les progrès sont trop rapides pour m'engager dans une configuration spécifique.
• J'ai une conscience aiguë des limites cognitives ou physiques à cause des difficultés de santé de ma mère et de ma sœur, et de mes expériences avec mes limitations à cause du fait que je suis la personne principalement en charge de ma fille.
• Je lis très vite, mais je n'ai pas assez de patience pour les longs contenus vidéo ou audio.
• Je n'aime pas les textes qui contiennent beaucoup de remplissage.
• Beaucoup de gens ont une réaction forte contre l'IA pour plusieurs raisons qui incluent le battage médiatique excessif dont elle fait l'objet, son utilisation à mauvais escient, et l'inondation de banalité qu'elle produit.
• Je réécris souvent la majorité du logiciel à l'exception d'un ou deux morceaux parce que ce code ne me convient pas.
• Je ne veux pas l'utiliser pour les correctifs que je veux soumettre à d'autres projets parce que le code ne me semble pas correct et je ne veux pas gaspiller le temps d'autres bénévoles.
• J'aime pouvoir lui donner trois dépôts git et des instructions pour générer un logiciel à partir d'un dépôt pour un autre via le troisième dépôt.
• Mais je ne veux pas le publier avant de réécrire et tout comprendre.
• Sans l'IA, je pourrais peut-être apprendre plus lentement avec l'aide d'Internet, qui a beaucoup de ressources commehttps://vitrinelinguistique.oqlf.gouv.qc.ca/Vitrine linguistique.
• Je veux profiter davantage, apprendre davantage avec l'aide de vraies personnes, complétée par l'aide de l'IA.
• J'adore les sous-titres simultanés, mais je n'ai pas toujours trouvé une méthode ou un système qui me convienne.

I can then go into the WhisperX transcription JSON file and replay those parts for closer review.

I can also tweak the context function to give me less information. For example, to limit it to the containing phrase, I can do this:

(defun my-split-string-keep-delimiters (string delimiter)
  (when string
    (let (results pos)
      (with-temp-buffer
        (insert string)
        (goto-char (point-min))
        (setq pos (point-min))
        (while (re-search-forward delimiter nil t)
          (push (buffer-substring pos (match-beginning 0)) results)
          (setq pos (match-beginning 0)))
        (push (buffer-substring pos (point-max)) results)
        (nreverse results)))))

(ert-deftest my-split-string-keep-delimiters ()
 (should
  (equal (my-split-string-keep-delimiters
          "Beaucoup de gens ont une réaction forte contre l'IA pour plusieurs raisons qui *incluent* le battage médiatique excessif dont elle fait l'objet, son utilisation à mauvais escient, et *l'inondation de banalité* qu'elle produit."
          ", \\| que \\| qui \\| qu'ils? \\| qu'elles? \\| qu'on "
          )
 )))

(defun my-lang-words-for-review-phrase-context (&optional s)
  (setq s (replace-regexp-in-string " " " " (or s (sentence-at-point))))
  (string-join
   (seq-filter (lambda (s) (string-match "\\*" s))
               (my-split-string-keep-delimiters s ", \\| parce que \\| que \\| qui \\| qu'ils? \\| qu'elles? \\| qu'on \\| pour "))
   " ... "))

(ert-deftest my-lang-words-for-review-phrase-context ()
  (should
   (equal (my-lang-words-for-review-phrase-context
           "Je peux consacrer une petite partie de mon *budget* à des essais, mais je ne veux pas travailler davantage pour rentabiliser une dépense plus importante.")
          "Je peux consacrer une petite partie de mon *budget* à des essais")))

(let ((my-lang-words-for-review-context-function 'my-lang-words-for-review-phrase-context))
  (my-lang-words-for-review "Sur l'intelligence artificielle"))

• pour faire des recherches.
• Je peux consacrer une petite partie de mon budget à des essais
• , et sinon
• J'ai une conscience aiguë des limites cognitives ou physiques à cause des difficultés de santé de ma mère et de ma sœur
• pour les longs contenus vidéo ou audio.
• Je n'aime pas les textes qui contiennent beaucoup de remplissage.
• qui incluent le battage médiatique excessif dont elle fait l'objet … , et l'inondation de banalité
• Je réécris souvent la majorité du logiciel à l'exception d'un ou deux morceaux
• pour les correctifs … parce que le code ne me semble pas correct et je ne veux pas gaspiller le temps d'autres bénévoles.
• pour un autre via le troisième dépôt.
• Mais je ne veux pas le publier avant de réécrire et tout comprendre.
• , je pourrais peut-être apprendre plus lentement avec l'aide d'Internet
• , apprendre davantage avec l'aide de vraies personnes, complétée par l'aide de l'IA.
• qui me convienne.

Now that I have a function for retrieving the HTML or Org Mode for a section, I can use that to wdiff against my current text to more easily spot wording changes.

(defun my-lang-tutor-notes-wdiff-org ()
  (interactive)
  (let ((section (org-entry-get (point) "ITEM")))
    (my-wdiff-strings
     (replace-regexp-in-string
      " " " "
      (my-org-subtree-text-without-blocks))
     (replace-regexp-in-string
      " " " "
      (my-lang-tutor-notes section)))))

Related:

• my-wdiff-strings is in Wdiff
• my-org-subtree-text-without-blocks is in Counting words without blocks

Screenshot:

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

I loyally enjoy running Debian Stable. I am with less enthusiasm accustomed to GNOME, after years of habit and customizations on which I have come to rely. But Debian has some disadvantages: for me, it was that (apparently) GRUB was not always configured correctly after installation to a random laptop. Meanwhile Linux Mint (inlcuding LMDE) installs are always solid. And I am too thick to troubleshoot GRUB. I found that I can have the best of both worlds.

Linux Mint is a popular and highly-recommended Linux distribution based on Ubuntu. I avoid Ubuntu, although Linux Mint overcomes many of my objections (by removing snaps and other Canonical transgressions). But there is also a Linux Mint Debian Edition (LMDE) in which Linux Mint user affordances, including its Cinnamon desktop environment, are built atop Debian instead. (For the record, I install Linux Mint on machines that I give to people who want to try Linux. Everything just works, reliably, and Cinnamon is a great entry point for Windows refugees, with a nice familiar look and feel.)

To my surprise, it turns out that it is possible to completely remove Cinnamon and its dependencies from LMDE and replace it with GNOME. The resulting experience is very similar to a Debian GNOME install, with the following differences (that I take to be advantages):

• a new install boots on more of the machines I have lying around
• the repositories curated by the Ubuntu and Linux Mint folks have newer versions (e.g. of GNOME and Emacs) than the Debian Stable repositories.

apt update
apt upgrade
reboot

sudo apt install tasksel
sudo tasksel

Choose software to install:

   [*] Debian desktop environment
   [*] ... GNOME
   [ ] ... Xfce
   [ ] ... GNOME Flashback
   [ ] ... KDE Plasma
   [ ] ... Cinnamon
   [ ] ... MATE
   [ ] ... LXDE
   [ ] ... LXQt

Default display manager:

         gdm3
         lightdm

sudo apt autoremove --purge cinnamon* mint*

This is my entry to the march emacs carnival on mistakes and misconceptions, hosted by Philip Kaluđerčić.

One of the things that hindered my usage of computers for a long time is that i thought that it was somehow better to use the keyboard as much as possible. This mentality is rampant among linux users in particular, and the majority of the classic linux/unix tools were designed for use without a mouse (because mouses were not commonplace at the time that they were created).

Many classic linux programs prefer to be operated with the keyboard, and emacs is no exception. But emacs is rather special in that it also has an extremely functional gui, and that gui is the default way of using emacs if a windowing system is available for it. There is good support for smooth scrolling, proportional fonts, images, and various other sundries associated with life after the eighties, including mouse support.

Unfortunately, there is still the notion among many people that emacs is not supposed to be used with the mouse: The guru-mode package, for example, claims to help you “learn to use emacs the way it was meant to be used”. The arguments put forth by these people had me convinced for a good while, and i cannot remember exactly why i changed my mind. But now my question is: if emacs was not meant to be used with the mouse, why is its mouse support so good?

There are all sorts of arguments for and against the mouse when it comes to speed. I won’t contribute to that discussion, and i would encourage others to also be sceptical of the conclusions those studies come to, as they tend to have some kind of bias towards a particular outcome. What i will point everyone towards is this blog post, which argues that calm, not speed, should be the focus, and the mouse, for the author, is the calmer input.

I no longer use avy, or any other packages aiming to replace mouse functionality with keyboard movements. It’s not that i think they don’t have their place, but rather that using the mouse is significantly less cognitive burden, and not significantly more effort.

Perhaps i should also note that although i say mouse, most of the time i’m actually using a trackpad. I used to use a thinkpad, and then i’d use the trackpoint. All have the same benefits over a keyboard for their particular use case: using a device designed for navigating a point across a plane in two dimensions works really nicely when i want to navigate a point across a plane in two dimensions.

One of the nicest things about emacs is that although it is very evidently a historical program, it still has added many modern features over the years. I know multiple people who are very excited about emacs’s integration with llms, although i admit that personally i can’t muster the same excitement that they have. But that doesn’t really matter: what matters is that emacs has a single fundamental concept, that of the text buffer, and as a result, anything that reads text and writes text can be integrated well with the platform. However, although the text buffer lends itself very well to keyboard interaction—i cannot imagine myself ever using a virtual keyboard to write this article, for example—the keyboard doesn’t need to be the only method of interaction. As apple showed us with the mac over forty years ago, the mouse is a powerful input device with many benefits when used in conjunction with the keyboard.

Eschewing the mouse purely because of some misguided sense of purity or superiority means that the emacs user is making some tasks more difficult than the need to be with entirely arbitrary justifications. It’s not necessary to use the mouse for everything, and i still use the keyboard to jump around text all the time. But there are some situations where the mouse feels like the best tool for the job, and i am glad that i am now able to take advantage of that best tool guilt-free.

I recently wrote about customizing font-lock in the age of Tree-sitter. After publishing that article, a reader pointed out that I’d overlooked font-lock-ignore – a handy option for selectively disabling font-lock rules that was introduced in Emacs 29. I’ll admit I had no idea it existed, and I figured if I missed it, I’m probably not the only one.¹

It’s a bit amusing that something this useful only landed in Emacs 29 – the very release that kicked off the transition to Tree-sitter. Better late than never, right?

The Problem

Traditional font-lock gives you two ways to control highlighting: the coarse font-lock-maximum-decoration (pick a level from 1 to 3) and the surgical font-lock-remove-keywords (manually specify which keyword rules to drop). The first is too blunt – you can’t say “I want level 3 but without operator highlighting.” The second is fragile – you need to know the exact internal structure of the mode’s font-lock-keywords and call it from a mode hook.

What was missing was a declarative way to say “in this mode, don’t highlight these things” without getting your hands dirty with the internals. That’s exactly what font-lock-ignore provides.

How It Works

font-lock-ignore is a single user option (a defcustom) whose value is an alist. Each entry maps a mode symbol to a list of conditions that describe which font-lock rules to suppress:

(setq font-lock-ignore
      '((MODE CONDITION ...)
        (MODE CONDITION ...)
        ...))

MODE is a major or minor mode symbol. For major modes, derived-mode-p is used, so a rule for prog-mode applies to all programming modes. For minor modes, the rule applies when the mode is active.

CONDITION can be:

• A face symbol – suppresses any font-lock rule that applies that face. Supports glob-style wildcards: font-lock-*-face matches all standard font-lock faces.
• A string – suppresses any rule whose regexp would match that string. This lets you disable highlighting of a specific keyword like "TODO" or "defun".
• (pred FUNCTION) – suppresses rules for which FUNCTION returns non-nil.
• (not CONDITION), (and CONDITION ...), (or CONDITION ...) – the usual logical combinators.
• (except CONDITION) – carves out exceptions from broader rules.

Note: The Emacs manual covers font-lock-ignore in the Customizing Keywords section of the Elisp reference.

When to Use It

font-lock-ignore is most useful when you’re generally happy with a mode’s highlighting but want to tone down specific aspects. Maybe you find type annotations too noisy, or you don’t want preprocessor directives highlighted, or a minor mode is adding highlighting you don’t care for.

For Tree-sitter modes, the feature/level system described in my previous article is the right tool for the job. But for traditional modes – and there are still plenty of those – font-lock-ignore fills a gap that existed for decades.

Discovering Which Faces to Suppress

To use font-lock-ignore effectively, you need to know which faces are being applied to the text you want to change. A few built-in commands make this easy:

• C-u C-x = (what-cursor-position with a prefix argument) – the quickest way. It shows the face at point along with other text properties right in the echo area.
• M-x describe-face – prompts for a face name (defaulting to the face at point) and shows its full definition, inheritance chain, and current appearance.
• M-x list-faces-display – opens a buffer listing all defined faces with visual samples. Handy for browsing the font-lock-*-face family and the newer Emacs 29 faces like font-lock-bracket-face and font-lock-operator-face.

Once you’ve identified the face, just drop it into font-lock-ignore.

Practical Examples

Here’s the example from the Emacs manual, which shows off the full range of conditions:

(setq font-lock-ignore
      '((prog-mode font-lock-*-face
                   (except help-echo))
        (emacs-lisp-mode (except ";;;###autoload"))
        (whitespace-mode whitespace-empty-at-bob-regexp)
        (makefile-mode (except *))))

Let’s break it down:

1. In all prog-mode derivatives, suppress all standard font-lock-*-face highlighting (syntactic fontification for comments and strings is unaffected, since that uses the syntax table, not keyword rules).
2. But keep any rules that add a help-echo text property.
3. In emacs-lisp-mode, also keep the ;;;###autoload cookie highlighting (which rule 1 would have suppressed).
4. When whitespace-mode is active, additionally suppress the whitespace-empty-at-bob-regexp highlight.
5. In makefile-mode, (except *) undoes all previous conditions, effectively exempting Makefiles from any filtering.

Here are some simpler, more focused examples:

;; Disable type highlighting in all programming modes
(setq font-lock-ignore
      '((prog-mode font-lock-type-face)))

;; Disable bracket and operator faces specifically
(setq font-lock-ignore
      '((prog-mode font-lock-bracket-face
                   font-lock-operator-face)))

;; Disable keyword highlighting in python-mode only
(setq font-lock-ignore
      '((python-mode font-lock-keyword-face)))

Pretty sweet, right?

Important Caveats

A few things to keep in mind:

• font-lock-ignore only affects keyword fontification (the regexp-based rules in font-lock-keywords). It does not touch syntactic fontification – comments and strings highlighted via the syntax table are not affected.
• It’s a global option, not buffer-local. You scope rules to specific modes via the alist keys.
• Since it filters rules at compile time (during font-lock-compile-keywords), changes take effect the next time font-lock is initialized in a buffer. If you’re experimenting, run M-x font-lock-mode twice (off then on) to see your changes.

The End

I don’t know about you, but I really wish that font-lock-ignore got added to Emacs a long time ago. Still, the transition to Tree-sitter modes is bound to take years, so many of us will still get to leverage font-lock-ignore and benefit from it.

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

If you use kubernetes-el, don't update for now, and you might want to check your installation if you updated it recently. The repo was compromised a few days ago.

I've occasionally wanted to tangle a single Org Mode source block to multiple places, so I'm glad to hear that ob-tangle has just added support for multiple targets. Niche, but could be handy. I'm also curious about using clime to write command-line tools in Emacs Lisp that handle argument parsing and all the usual stuff.

If you're looking for something to write about, why not try this month's Emacs Carnival theme of mistakes and misconceptions?

Enjoy!

• Security:
  • First (?) hacked Emacs package: kubernetes-el (Reddit)
• Upcoming events (iCal file, Org):
  • Emacs Berlin: In-Person-Only Emacs-Berlin Stammtisch https://emacs-berlin.org/ Tue Mar 10 1900 Europe/Berlin
  • OrgMeetup (virtual) https://orgmode.org/worg/orgmeetup.html Wed Mar 11 0900 America/Vancouver - 1100 America/Chicago - 1200 America/Toronto - 1600 Etc/GMT - 1700 Europe/Berlin - 2130 Asia/Kolkata – Thu Mar 12 0000 Asia/Singapore
  • Computing in freedom with GNU Emacs - Protesilaos Stavrou - FLOSS@Oxford https://ox.ogeer.org/event/computing-in-freedom-with-gnu-emacs-protesilaos-stavrou Thu Mar 12 1100 America/Vancouver - 1300 America/Chicago - 1400 America/Toronto - 1800 Etc/GMT - 1900 Europe/Berlin - 2330 Asia/Kolkata – Fri Mar 13 0200 Asia/Singapore
  • Atelier Emacs Montpellier (in person) https://lebib.org/date/atelier-emacs Fri Mar 13 1800 Europe/Paris
  • M-x Research: TBA https://m-x-research.github.io/ Wed Mar 18 0900 America/Vancouver - 1100 America/Chicago - 1200 America/Toronto - 1600 Etc/GMT - 1700 Europe/Berlin - 2130 Asia/Kolkata – Thu Mar 19 0000 Asia/Singapore
• Beginner:
  • Emacs: Buffers, Frames, and Windows, A Brief Introduction « Here's The Beef (@BeefGriller@dice.camp)
• Emacs configuration:
  • Elpaca Version 0.1.0 (Reddit) accepts use-package :vc keyword
  • Sacha Chua: Emacs Lisp: defvar-keymap hints for which-key
  • Re-imagining the Emacs user experience with Casual Suite (Reddit, Irreal)
    • Charles Choi: Casual now available on NonGNU ELPA (Irreal)
  • Two Years of Emacs Solo: 35 Modules, Zero External Packages, and a Full Refactor (Reddit)
• Emacs Lisp:
  • cosmicz/clime: Build real CLI tools in pure Emacs Lisp. Declare commands, options, and args in a single form — clime handles parsing, –help, error messages, and dispatch. ./myapp.el just works. · GitHub (Reddit)
  • Async link fetching in Emacs
  • Progress (GNU Emacs Lisp Reference Manual) (@kickingvegas@sfba.social)
  • Emacs Internal #02: Data First — Deconstructing Lisp_Object in C | The Cloudlet (HN)
  • [19] Working on Canvas API Patch - 3/8/2026, 2:28:14 PM - Dyne.org TV
  • [19] Working on Canvas API Patch - 3/8/2026, 3:49:58 PM - Dyne.org TV
• Appearance:
  • Emacs Redux: Customizing Font-Lock in the Age of Tree-sitter
  • Protesilaos Stavrou: Emacs: four new themes are coming to the ‘doric-themes’
• Navigation:
  • My first meaningful hack of Emacs (proper isearch) - search with recenter after threshold
  • Emacs Redux: expreg: Expand Region, Reborn (Reddit, Irreal)
  • Emacs Redux: Transpose All The Things (Irreal)
• Dired:
  • Chris Maiorana: The Emacs Way: Copying Files
• Writing:
  • Wai Hon: Introducing markdown-indent-mode (Reddit)
• Org Mode:
  • Curtis McHale: Stop Mixing DONE and TODO in Org — Auto-Sort Like a Pro (YouTube 05:15)
  • a niche emacs productivity system (28:31)
  • Irreal: Abrams On Literate Programming Redux
  • We Should Revisit Literate Programming in the Agent Era | silly business (lobste.rs)
  • TAONAW - Emacs and Org Mode: Display images with Org-attach and org-insert-link quickly and effectively (Irreal)
  • Latex preview on Emacs tty
  • Toward the Org Mode future: distributed notebooks (Reddit)
  • Jeremias-A-Queiroz/chrono-org: extract logbooks for sleek, Clockify-style web visualizations using Chart.js and org-publish (Reddit)
  • naiquevin/clockwise: visualize time records from org clock entries (@naiquevin@fosstodon.org)
  • (update) org-supertag 5.8 & 5.8.1 - Board, Graph UI & Relation Index Optimization
  • Remember to set org-latx-hyperref-template to nil if you're writing an anonymous referee report
  • lazyblorg updates: tag feeds, random articles on this day, list of external URLs (@publicvoit@graz.social)
  • Thanos Apollo: Gnosis: Design Mistakes Roam-inspired note-taking system, 0.8.0 release notes
  • Org development: ob-tangle.el: Support tangling a source block to multiple targets
• Completion:
  • gggion/let-completion.el: Let-binding values in Elisp completion · GitHub (Reddit)
  • Sacha Chua: Expanding yasnippets by voice in Emacs and other applications
• Coding:
  • Emacs Redux: Mastering Compilation Mode
  • Tip on using built-in vc-mode with C-x v (useful: C-x v d, C-x v v, C-x v L)
  • James Cherti: pathaction.el: execute pathaction rules, the universal Makefile for the entire filesystem (Github)
  • gcv/julia-snail: An Emacs development environment for Julia · GitHub
  • [EMACS LAB #2] Do zero a uma IDE para programar em C (parte 2) (01:17:59)
  • Marcin Borkowski: Lispy and Iedit
  • Meta Redux: What’s Next for clojure-mode?
  • The Emacs Cat: Emacs, Software Development, and LLM
• Math:
  • Why did I create ESR (my thoughts on ESS) | Teoten's blog (@teoten@social.linux.pizza)
• Evil mode:
  • Sid Kasivajhula: On “Tempo” in Text Editing - normal Emacs commands in insert mode (Reddit)
• Fun:
  • Launching Brogue from Emacs via transient
• AI:
  • Bozhidar Batsov: Emacs and Vim in the Age of AI (@bbatsov@hachyderm.io)
  • simple LLM text and images meets org-mode
  • Claude Code + Org Mode + Git + Hooks
  • Transformei meu segundo cérebro em uma IA em 4 minutos (08:43) - with org-roam
  • Alvaro Ramirez: Bending Emacs - Episode 13: agent-shell charting (YouTube 28:11, Reddit)
  • James Dyer: Ollama Buddy - Web Search Integration (YouTube 02:12)
• Community:
  • My Emacs Misconceptions — Where Are The Wise Men? (@mikehoss@appdot.net)
  • Protesilaos Stavrou: I talk with Joshua Blais about Emacs and life issues
  • Org Social social network summary, 2.11 update with bugfixes
  • Org Social - Reading (@andros@activity.andros.dev)
• Other:
  • koreader json to org: convert KOReader JSON highlights to Org mode, also here (@srijan@indieweb.social)
  • For Mac users: pbcopy.el spawns two subprocesses on every C-y - suggests alternate implementation
• Emacs development:
  • emacs-devel:
    • notes on CEDET and EDE
    • Re: Sending `quit` to a batch Emacs process - Eli Zaretskii Thinking about how to interrupt batch processes
  • New user option and function 'recentf-exclude-ignored-extensions'
  • New user option vc-display-failed-async-commands
  • Make 'frame-use-time' more reliable. (bug#80397)
  • Rename 'any' to 'member-if' and deprecate 'cl-member-if'
  • New command 'unfill-paragraph'
  • Revert "Rename 'any' to 'member-if' and deprecate 'cl-member-if'"
  • Add mirroring for special glyphs (bug#80440)
  • Rename 'any' to 'member-if' and deprecate 'cl-member-if'
  • Make tree-sitter thing navigation handle nested parsers
• New packages:
  • emacs-lisp-intro-es: ELisp intro manual in Spanish (GNU ELPA)
  • hackernews-modern: Hacker News client with modern widget UI (MELPA)
  • helm-eca: Helm UI for ECA chats/workspaces (MELPA)
  • let-completion: Show let-binding values in Elisp completion (MELPA)
  • magit-browse-commit: Browse pull/merge requests from magit-blame (MELPA)
  • markdown-indent-mode: Dynamic indentation for Markdown (MELPA)
  • mathprog-ts-mode: Major mode for the GNU MathProg modeling language (MELPA)
  • md-ts-mode: Major mode for Markdown using tree-sitter (MELPA)
  • mutype: Type into stillness (MELPA)
  • org-eval: Execute named org-mode blocks on load/save (MELPA)
  • php-fill: Additional fill commands for PHP code editing (GNU ELPA)
  • rtf-view: View Rich Text Format files (MELPA)
  • solo-rpg: Solo roleplaying games support functions (MELPA)
  • yomikata: Annotates Japanese text with reading tooltips (MELPA)

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

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

It’s tough to make predictions, especially about the future.

– Yogi Berra

I’ve been an Emacs fanatic for over 20 years. I’ve built and maintained some of the most popular Emacs packages, contributed to Emacs itself, and spent countless hours tweaking my configuration. Emacs isn’t just my editor – it’s my passion, and my happy place.

Over the past year, I’ve also been spending a lot of time with Vim and Neovim, relearning them from scratch and having a blast contrasting how the two communities approach similar problems. It’s been a fun and refreshing experience.¹

And lately, like everyone else in our industry, I’ve been playing with AI tools – Claude Code in particular – watching the impact of AI on the broader programming landscape, and pondering what it all means for the future of programming. Naturally, I keep coming back to the same question: what happens to my beloved Emacs and its “arch nemesis” Vim in this brave new world?

I think the answer is more nuanced than either “they’re doomed” or “nothing changes”. Predicting the future is hard, but speculating is irresistible.

The Risks

The only thing that is constant is change.

– Heraclitus

Things are rarely black and white – usually just some shade of gray. AI is obviously no exception, and I think it’s worth examining both sides honestly before drawing any conclusions.

Let’s start with the challenges.

The IDE gravity well

VS Code is already the dominant editor by a wide margin, and it’s going to get first-class integrations with every major AI tool – Copilot (obviously), Codex, Claude, Gemini, you name it. Microsoft has every incentive to make VS Code the best possible host for AI-assisted development, and the resources to do it.

On top of that, purpose-built AI editors like Cursor, Windsurf, and others are attracting serious investment and talent. These aren’t adding AI to an existing editor as an afterthought – they’re building the entire experience around AI workflows. They offer integrated context management, inline diffs, multi-file editing, and agent loops that feel native rather than bolted on.

Every developer who switches to one of these tools is a developer who isn’t learning Emacs or Vim keybindings, isn’t writing Elisp, and isn’t contributing to our ecosystems. The gravity well is real.

I never tried Cursor and Windsurf simply because they are essentially forks of VS Code and I can’t stand VS Code. I’ve tried it several times over the years and I never felt productive in it for a variety of reasons.

Do you even need a “power tool” anymore?

Part of the case for Emacs and Vim has always been that they make you faster at writing and editing code. The keybindings, the macros, the extensibility – all of it is in service of making the human more efficient at the mechanical act of coding.

But if AI is writing most of your code, how much does mechanical editing speed matter? When you’re reviewing and steering AI-generated diffs rather than typing code character by character, the bottleneck shifts from “how fast can I edit” to “how well can I specify intent and evaluate output.” That’s a fundamentally different skill, and it’s not clear that Emacs or Vim have an inherent advantage there.

The learning curve argument gets harder to justify too. “Spend six months learning Emacs and you’ll be 10x faster” is a tough sell when a junior developer with Cursor can scaffold an entire application in an afternoon.² Then again, maybe the question of what exactly you’re editing deserves a closer look.

The corporate backing asymmetry

VS Code has Microsoft. Cursor has venture capital. Emacs has… a small group of volunteers and the FSF. Vim had Bram, and now has a community of maintainers. Neovim has a small but dedicated core team.

This has always been the case, of course, but AI amplifies the gap. Building deep AI integrations requires keeping up with fast-moving APIs, models, and paradigms. Well-funded teams can dedicate engineers to this full-time. Volunteer-driven projects move at the pace of people’s spare time and enthusiasm.

The doomsday scenario

Let’s go all the way: what if programming as we know it is fully automated within the next decade? If AI agents can take a specification and produce working, tested, deployed software without human intervention, we won’t need coding editors at all. Not Emacs, not Vim, not VS Code, not Cursor. The entire category becomes irrelevant.

I don’t think this is likely in the near term, but it’s worth acknowledging as a possibility. The trajectory of AI capabilities has surprised even the optimists (and I was initially an AI skeptic, but the rapid advancements last year eventually changed my mind).

The Opportunities

That paints a grim picture, but Emacs and Vim have been written off more times than I can count. Eclipse was going to kill them. IntelliJ was going to kill them. VS Code was going to kill them. Sublime Text, Atom, TextMate – all were supposedly the final nail in the coffin. Most of those “killers” are themselves dead or declining, while Emacs and Vim keep chugging along. There’s a resilience to these editors that’s easy to underestimate.

So let’s look at the other side of the coin.

AI helps you help yourself

One of the most underappreciated benefits of AI for Emacs and Vim users is mundane: troubleshooting. Both editors have notoriously steep learning curves and opaque error messages. “Wrong type argument: stringp, nil” has driven more people away from Emacs than any competitor ever did.

AI tools are remarkably good at explaining cryptic error messages, diagnosing configuration issues, and suggesting fixes. They can read your init file and spot the problem. They can explain what a piece of Elisp does. They can help you understand why your keybinding isn’t working. This dramatically flattens the learning curve – not by making the editor simpler, but by giving every user access to a patient, knowledgeable guide.

I don’t really need any AI assistance to troubleshoot anything in my Emacs setup, but it’s been handy occasionally in Neovim-land, where my knowledge is relatively modest by comparison.

There’s at least one documented case of someone returning to Emacs after years away, specifically because Claude Code made it painless to fix configuration issues. They’d left for IntelliJ because the configuration burden got too annoying – and came back once AI removed that barrier. “Happy f*cking days I’m home again,” as they put it. If AI can bring back lapsed Emacs users, that’s a good thing in my book.

AI makes configuration and extension trivial

Something that doesn’t get nearly enough attention: Emacs and Vim have always suffered from the obscurity of their extension languages. Emacs Lisp is a 1980s Lisp dialect that most programmers have never seen before. VimScript is… VimScript. Even Lua, which Neovim adopted specifically because it’s more approachable, is niche enough that most developers haven’t written a line of it.

This has been the single biggest bottleneck for both ecosystems. Not the editors themselves – they’re incredibly powerful – but the fact that customizing them requires learning an unfamiliar language, and most people never make it past copying snippets from blog posts and READMEs.

I felt incredibly overwhelmed by Elisp and VimScript when I was learning Emacs and Vim for the first time, and I imagine I wasn’t the only one. I started to feel very productive in Emacs only after putting in quite a lot of time to actually learn Elisp properly. (Never bothered to do the same for VimScript, though, and I’m not too eager to master Lua either.)

AI changes this overnight. You can now describe what you want in plain English and get working Elisp, VimScript, or Lua. “Write me an Emacs function that reformats the current paragraph to 72 columns and adds a prefix” – done. “Configure lazy.nvim to set up LSP with these keybindings” – done. The extension language barrier, which has been the biggest obstacle to adoption for decades, is suddenly much lower.

The same goes for plugin development

After 20+ years in the Emacs community, I often have the feeling that a relatively small group – maybe 50 to 100 people – is driving most of the meaningful progress. The same names show up in MELPA, on the mailing lists, and in bug reports. This isn’t a criticism of those people (I’m proud to be among them), but it’s a structural weakness. A community that depends on so few contributors is fragile.

And it’s not just Elisp and VimScript. The C internals of both Emacs and Vim (and Neovim’s C core) are maintained by an even smaller group. Finding people who are both willing and able to hack on decades-old C codebases is genuinely hard, and it’s only getting harder as fewer developers learn C at all.

AI tools can help here in two ways. First, they lower the barrier for new contributors – someone who understands the concept of what they want to build can now get AI assistance with the implementation in an unfamiliar language. Second, they help existing maintainers move faster. I’ve personally found that AI is excellent at generating test scaffolding, writing documentation, and handling the tedious parts of package maintenance that slow everything down.

AI integrations are already happening

The Emacs and Neovim communities aren’t sitting idle. There are already impressive AI integrations:

Emacs:

• gptel – a versatile LLM client that supports multiple backends (Claude, GPT, Gemini, local models)
• ellama – an Emacs interface for interacting with LLMs via llama.cpp and Ollama
• aider.el – Emacs integration for Aider, the popular AI pair programming tool
• copilot.el – GitHub Copilot integration (I happen to be the current maintainer of the project)
• elysium – an AI-powered coding assistant with inline diff application
• agent-shell – a native Emacs buffer for interacting with LLM agents (Claude Code, Gemini CLI, etc.) via the Agent Client Protocol
• ECA – an editor-agnostic AI coding assistant (built in Clojure!) that works via a protocol similar to LSP, supporting multiple LLM providers (and Neovim too)

Neovim:

• avante.nvim – a Cursor-like AI coding experience inside Neovim
• codecompanion.nvim – a Copilot Chat replacement supporting multiple LLM providers
• copilot.lua – native Copilot integration for Neovim
• gp.nvim – ChatGPT-like sessions in Neovim with support for multiple providers

And this is just a sample. Building these integrations isn’t as hard as it might seem – the APIs are straightforward, and the extensibility of both editors means you can wire up AI tools in ways that feel native. With AI assistance, creating new integrations becomes even easier. I wouldn’t be surprised if the pace of plugin development accelerates significantly.

Terminal-native AI tools are a natural fit

Funny enough, many of the most powerful AI coding tools are terminal-native. Claude Code, Aider, and various Copilot CLI tools all run in the terminal. And what lives in the terminal? Emacs and Vim.³

Running Claude Code in an Emacs vterm buffer or a Neovim terminal split is a perfectly natural workflow. You get the AI agent in one pane and your editor in another, with all your keybindings and tools intact. There’s no context switching to a different application – it’s all in the same environment.

This is actually an advantage over GUI-based AI editors, where the AI integration is tightly coupled to the editor’s own interface. With terminal-native tools, you get to choose your own editor and your own AI tool, and they compose naturally.

There’s another angle worth considering: if programming is increasingly about writing prompts rather than code, you still benefit from a great text editor for that. Prompts are text, and crafting them well matters. I find it ironic that Claude Code – a tool I otherwise love – doesn’t use readline, so my Emacs keybindings don’t work properly in it, and its vim emulation is fairly poor. I still think using React for CLI apps is a mistake, and I suspect many people would enjoy running Claude Code inside their Emacs or Vim instead. That’s exactly what the Agent Client Protocol (ACP) enables – it lets editors like Emacs (via agent-shell) act as first-class clients for AI agents, giving you proper editing, keybindings, and all the power of your editor while interacting with tools like Claude Code. The best prompt editor might just be the one you’ve been using for decades.

Emacs as an AI integration platform

Emacs’s “editor as operating system” philosophy is uniquely well-suited to AI integration. It’s not just a code editor – it’s a mail client (Gnus, mu4e), a note-taking system (Org mode), a Git interface (Magit), a terminal emulator, a file manager, an RSS reader, and much more.

AI can be integrated at every one of these layers. Imagine an AI assistant that can read your org-mode agenda, draft email replies in mu4e, help you write commit messages in Magit, and refactor code in your source buffers – all within the same environment, sharing context. No other editor architecture makes this kind of deep, cross-domain integration as natural as Emacs does.

I stopped using Emacs as my OS a long time ago, and these days I use it mostly for programming and blogging. (I’m writing this article in Emacs with the help of markdown-mode.) Still, I’m only one Emacs user and many are probably using it in a more holistic manner.

Even in the post-coding apocalypse, Emacs and Vim survive

Let’s revisit the doomsday scenario. Say programming is fully automated and nobody writes code anymore. Does Emacs die?

Not necessarily. Emacs is already used for far more than programming. People use Org mode to manage their entire lives – tasks, notes, calendars, journals, time tracking, even academic papers. Emacs is a capable writing environment for prose, with excellent support for LaTeX, Markdown, AsciiDoc, and plain text. You can read email, browse the web, manage files, and yes, play Tetris.

Vim, similarly, is a text editing paradigm as much as a program. Vim keybindings have colonized every text input in the computing world – VS Code, IntelliJ, browsers, shells, even Emacs (via Evil mode). Even if the Vim program fades, the Vim idea is immortal.⁴

And who knows – maybe there’ll be a market for artisanal, hand-crafted software one day, the way there’s a market for vinyl records and mechanical watches.⁵ “Organic, small-batch code, lovingly typed by a human in Emacs – one character at a time.” I’d buy that t-shirt. And I’m fairly certain those artisan programmers won’t be using VS Code.

So even in the most extreme scenario, both editors have a life beyond code. A diminished one, perhaps, but a life nonetheless.

The Bigger Picture

I think what’s actually happening is more interesting than “editors die” or “editors are fine.” The role of the editor is shifting.

For decades, the editor was where you wrote code. Increasingly, it’s becoming where you review, steer, and refine code that AI writes. The skills that matter are shifting from typing speed and editing gymnastics to specification clarity, code reading, and architectural judgment.

In this world, the editor that wins isn’t the one with the best code completion – it’s the one that gives you the most control over your workflow. And that has always been Emacs and Vim’s core value proposition.

The question is whether the communities can adapt fast enough. The tools are there. The architecture is there. The philosophy is right. What’s needed is people – more contributors, more plugin authors, more documentation writers, more voices in the conversation. AI can help bridge the gap, but it can’t replace genuine community engagement.

The Ethical Elephant in the Room

Not everyone in the Emacs and Vim communities is enthusiastic about AI, and the objections go beyond mere technophobia. There are legitimate ethical concerns that are going to be debated for a long time:

• Energy consumption. Training and running large language models requires enormous amounts of compute and electricity. For communities that have long valued efficiency and minimalism – Emacs users who pride themselves on running a 40-year-old editor, Vim users who boast about their sub-second startup times – the environmental cost of AI is hard to ignore.

• Copyright and training data. LLMs are trained on vast corpora of code and text, and the legality and ethics of that training remain contested. Some developers are uncomfortable using tools that may have learned from copyrighted code without explicit consent. This concern hits close to home for open-source communities that care deeply about licensing.

• Job displacement. If AI makes developers significantly more productive, fewer developers might be needed. This is an uncomfortable thought for any programming community, and it’s especially pointed for editors whose identity is built around empowering human programmers.

These concerns are already producing concrete action. The Vim community recently saw the creation of EVi, a fork of Vim whose entire raison d’etre is to provide a text editor free from AI-assisted (generated?) code contributions.⁶ Whether you agree with the premise or not, the fact that people are forking established editors over this tells you how strongly some community members feel.

I don’t think these concerns should stop anyone from exploring AI tools, but they’re real and worth taking seriously. I expect to see plenty of spirited debate about this on emacs-devel and the Neovim issue tracker in the years ahead.

Closing Thoughts

The future ain’t what it used to be.

– Yogi Berra

I won’t pretend I’m not worried. The AI wave is moving fast, the incumbents have massive advantages in funding and mindshare, and the very nature of programming is shifting under our feet. It’s entirely possible that Emacs and Vim will gradually fade into niche obscurity, used only by a handful of diehards who refuse to move on.

What keeps these editors alive isn’t stubbornness – it’s adaptability. The communities are small but passionate, the editors are more capable than ever, and the architecture is genuinely well-suited to the AI era. Vim’s core idea is so powerful that it keeps finding new expression (Neovim being the most vigorous one). And Emacs? Emacs just keeps absorbing whatever the world throws at it. It always has.

The editors that survive won’t be the ones with the flashiest AI features. They’ll be the ones whose users care enough to keep building, adapting, and sharing. That’s always been the real engine of open-source software, and no amount of AI changes that.

So if you’re an Emacs or Vim user: don’t panic, but don’t be complacent either. Learn the new AI tools (if you’re not fundamentally opposed to them, that is). Pimp your setup and make it awesome. Write about your workflows. Help newcomers. The best way to ensure your editor survives the AI age is to make it thrive in it.

Maybe the future ain’t what it used to be – but that’s not necessarily a bad thing.

This essay covered more ground than I originally intended – lots of thoughts have been rattling around in my head for a while now, and I wanted to get them all out. Programming may be hard, but writing prose remains harder. Still, I hope some of these ideas resonated with you.

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

P.S. There’s an interesting Hacker News discussion about this article. Check it out if you want to see what the broader community thinks!

This Thursday, the 12th of March, at 20:00 Europe/Athens time I will do a live presentation of Emacs for OxFLOSS (FLOSS @ Oxford). This is an event organised by people at the University of Oxford. My goal is to introduce Emacs to a new audience by showing them a little of what it can do while describing how exactly it gives users freedom.

The presentation will be about 40 minutes long. I will then answer any questions from the audience. Anyone can participate: no registration is required. The event will be recorded for future reference. The link for the video call and further details are available here: https://ox.ogeer.org/event/computing-in-freedom-with-gnu-emacs-protesilaos-stavrou.

I will prepare a transcript for my talk. This way people can learn about my presentation without having to access the video file.

Looking forward to it!

Suppose you have an org-mode file and want an image to appear in the buffer. The way to do that is to insert a link to the file, for example:

[[home/username/downloads/image.png]].

Then, you toggle inline images with C-c C-x C-v, and the image should display inside the org-mode buffer, provided the path in the link is correct. If you do this often in your notes as I do, you might as well just turn it on for the entire file with #+STARTUP: inlineimages at the top of your org file, with the rest of the options you have there; this way, images will always display when you load the file. This is all nice and good, and most of us org-mode users probably know that.

A common use case for a full workflow like this is attaching images to your org file. You have a file in your Downloads folder, as shown in the example above, and you want to keep the image with your org file where it belongs, rather than in Downloads, where it will be lost among other files sooner or later.

For this, as most of us know, we have org-attach (C-c C-a by default). This starts a wonderful organizational process for our files:

1. It creates a data folder (by default) inside the folder the org-file is in if it’s not there
2. It then gives the header (even if you don’t have one) a UUID (Universally Unique Identifier) and creates two more directories, one inside the other:
   1. The parent directory consists of the first part of the UUID
   2. The child directory consists of the rest of the UUID
3. Lastly, the file itself will be copied into the child directory above.

For example:

./data/acde070d/8c4c-4f0d-9d8a-162843c10333/someimage.png

If you’re not used to how org-attach works, it might take some time getting used to, but it’s worth it. Images (or any file, as we will deal with soon) are kept next to the files they are associated with. Of course, org-attach is customizable, and you can change those folders and UUIDs to make them less cryptic.

For example, my init includes this:

    (setq org-id-method 'ts)
    (setq org-attach-id-to-path-function-list 
      '(org-attach-id-ts-folder-format
        org-attach-id-uuid-folder-format))

This tells org-mode to change the UUID to IOS date stamp format, so the folders under the data folder are dates, and tells org-mode to use that system (I wrote about this in length in my old blog; it is yet another post I need to bring over here).

In my case, this creates a file reference system by date: inside the data folder, each month of the year has a folder; inside those, a folder for the day and time (down to fractions of seconds) of the attachment. The beauty of org-attach is that you’re not meant to deal with the files directly. You summon the org-attach dispatcher and tell it to go to the relevant folder (C-c C-a to bring it up, then f as the option to go to that directory).

org-attach and displaying images inline are known to many org-mode users, but here comes the part I never realized:

org-attach stores the link to the file you just attached inside a variable called org-stored-link, along with other links you might have grabbed, like URLs from the web (take a look with C-h v org-stored-links). And, even better, these links are added to your org-insert-link, ready to go when you insert a link to your file with C-c C-l.

So when you have an image ready to attach to an org file, say in your Downloads folder, you could first attach it with org-attach, and then you can call it back quickly with C-c C-l. The trick is, since this is an image link (and not just any file), is not to give it a description. By default, org-mode will suggest you describe the link as the file you attached, but inline images do not work like that, and with a description, the image will just display as a file name. In other words:

A link to an image you want to display in the org buffer should look like:

[[file:/Home/username/downloads/someimage.jpg]]

But any other file would look like:

[[file:/Home/username/downloads/somefile.jpg][description]]

By deleting the suggestion, you are effectively creating the first case, the one that is meant to display images. This is explained nicely here.

There’s more to it. As it turns out, the variable org-attach-store-link-p is responsible for the links to these files to automatically be stored in org-insert-link (you can toggle it to change this option). This is why, when you use it, your files or images will show as [[attachment:description]], without the need for the path as specified above.

I have years of muscle memory to undo, as I’m used to manually inserting the links with the full path for my images. I did not realize the links to the images I’ve attached are right there, ready for me to place into the buffer if I only delete the description.

Howard Abrams has a video and associated post that updates his post on the same subject from 11 years ago. As with yesterday’s post, the video is from EmacsConf 2024 but someone just reposted it to reddit and it’s definitely worth taking a look at.

Abrams is explicit that by “literate programming” he means using code blocks and Babel in Org mode files. It’s an extremely powerful workflow. You can execute those code blocks in place or you can use org-babel-tangle to export the code to a separate file.

The majority of his video and post discuss ways of working with those Org files. One simple example is that he uses the local variables feature of Emacs files to set a hook that automatically tangles the file every time he saves it. That keeps the parent Org file and the generated code file in sync. He also has some functions that leverage Avy to find and execute a code block without changing the point’s location.

Finally, he talks about navigating his—possibly multi-file—projects. We wants to do the usual things like jumping to a function definition or getting a list of where a function is called. Emacs, of course, has functions for that but they don’t work in Org files. So Abrams wrote his own extension to the xref API based on ideas from dumb-jump.

Abrams drew all this together with a hydra that makes it easy for him to call any of his functions. He moves a bit rapidly in the video so you might want to read the post first in order to follow along. The video is 16 minutes, 38 seconds long so plan accordingly.

I've been maintaining Emacs Solo for a while now, and I think it's time to talk about what happened in this latest cycle as the project reaches its two-year mark.

For those who haven't seen it before, Emacs Solo is my daily-driver Emacs configuration with one strict rule: no external packages. Everything is either built into Emacs or written from scratch by me in the lisp/ directory. No package-install, no straight.el, no use-package :ensure t pointing at ELPA or MELPA. Just Emacs and Elisp. I'm keeping this post text only, but if you'd like to check how Emacs Solo looks and feels, the repository has screenshots and more details.

Why? Partly because I wanted to understand what Emacs actually gives you out of the box. Partly because I wanted my config to survive without breakage across Emacs releases. Partly because I was tired of dealing with package repositories, mirrors going down in the middle of the workday, native compilation hiccups, and the inevitable downtime when something changed somewhere upstream and my job suddenly became debugging my very long (at the time) config instead of doing actual work. And partly, honestly, because it's a lot of fun!

This post covers the recent refactor, walks through every section of the core config, introduces all 35 self-contained extra modules I've written, and shares some thoughts on what I've learned.

Now, I'll be the first to admit: this config is long. But there's a principle behind it. I only add features when they are not already in Emacs core, and when I do, I try to build them myself. That means the code is sketchy sometimes, sure, but it's in my control. I wrote it, I understand it, and when it breaks, I know exactly where to look. The refactor I'm about to describe makes this distinction crystal clear: what is "Emacs core being tweaked" versus what is "a really hacky outsider I built in because I didn't want to live without it".

The Refactor: Core vs. Extras

The single biggest change in this cycle was architectural. Emacs Solo used to be one big init.el with everything crammed together. That worked, but it had problems:

— It was hard to navigate (even with outline-mode)

— If someone wanted just one piece, say my Eshell config or my VC extensions, they had to dig through thousands of lines

— It was difficult to tell where "configuring built-in Emacs" ended and "my own hacky reimplementations" began

The solution was clean and simple: split the config into two layers.

Layer 1: init.el (Emacs core configuration)

This file configures only built-in Emacs packages and features. Every use-package block in here has :ensure nil, because it's pointing at something that ships with Emacs. This is pure, standard Emacs customization.

The idea is that anyone can read init.el, find a section they like, and copy-paste it directly into their own config. No dependencies. No setup. It just works, because it's configuring things Emacs already has.

Layer 2: lisp/ (Self-contained extra modules)

These are my own implementations: replacements for popular external packages, reimagined as small, focused Elisp files. Each one is a proper provide/require module. They live under lisp/ and are loaded at the bottom of init.el via a simple block:

(add-to-list 'load-path (expand-file-name "lisp" user-emacs-directory))
(require 'emacs-solo-themes)
(require 'emacs-solo-movements)
(require 'emacs-solo-formatter)
;; ... and so on

If you don't want one of them, just comment out the require line. If you want to use one in your own config, just copy the .el file into your own lisp/ directory and require it. That's it.

This separation made the whole project dramatically easier to maintain, understand, and share.

The Core: What init.el Configures

The init.el file is organized into clearly labeled sections (using outline-mode-friendly headers, so you can fold and navigate them inside Emacs). Here's every built-in package and feature it touches, and why.

General Emacs Settings

The emacs use-package block is the largest single section. It sets up sensible defaults that most people would want:

— Key rebindings: M-o for other-window, M-j for duplicate-dwim, C-x ; for comment-line, C-x C-b for ibuffer

— Window layout commands bound under C-x w (these are upcoming Emacs 31 features: window-layout-transpose, window-layout-rotate-clockwise, window-layout-flip-leftright, window-layout-flip-topdown)

— Named frames: C-x 5 l to select-frame-by-name, C-x 5 s to set-frame-name, great for multi-frame workflows

— Disabling C-z (suspend) because accidentally suspending Emacs in a terminal is never fun

— Sensible file handling: backups and auto-saves in a cache/ directory, recentf for recent files, clean buffer naming with uniquify

— Tree-sitter auto-install and auto-mode (treesit-auto-install-grammar t and treesit-enabled-modes t, both Emacs 31)

— delete-pair-push-mark, kill-region-dwim, ibuffer-human-readable-size, all the small quality-of-life settings coming in Emacs 31

Abbrev

A full abbrev-mode setup with a custom placeholder system. You define abbreviations with ###1###, ###2### markers, and when the abbreviation expands, it prompts you to fill in each placeholder interactively. The ###@### marker tells it where to leave point after expansion. I wrote a whole article about it.

Auth-Source

Configures auth-source to use ~/.authinfo.gpg for credential storage. Simple but essential if you use Gnus, ERC, or any network-facing Emacs feature.

Auto-Revert

Makes buffers automatically refresh when files change on disk. Essential for any Git workflow.

Conf / Compilation

Configuration file mode settings and a compilation-mode setup with ANSI color support, so compiler output actually looks readable.

Window

Custom window management beyond the defaults, because Emacs window management out of the box is powerful but needs a little nudging.

Tab-Bar

Tab-bar configuration for workspace management. Emacs has had tabs since version 27, and they're genuinely useful once you configure them properly.

RCIRC and ERC

Two IRC clients, both built into Emacs, both configured. ERC gets the bigger treatment: logging, scrolltobottom, fill, match highlighting, and even inline image support (via one of the extra modules). The Emacs 31 cycle brought nice improvements here too, including a fix for the scrolltobottom/fill-wrap dependency issue.

Icomplete

This is where Emacs Solo's completion story lives. Instead of reaching for Vertico, Consult, or Helm, I use icomplete-vertical-mode, which is built into Emacs. With the right settings it's surprisingly capable:

(setq icomplete-delay-completions-threshold 0)
(setq icomplete-compute-delay 0)
(setq icomplete-show-matches-on-no-input t)
(setq icomplete-scroll t)

I've also been contributing patches upstream to improve icomplete's vertical rendering with prefix indicators. Some of those features are already landing in Emacs 31, which means the polyfill code I carry today will eventually become unnecessary.

Dired

A heavily customized Dired setup. Custom listing switches, human readable sizes, integration with system openers (open on macOS, xdg-open on Linux), and the dired-hide-details-hide-absolute-location option from Emacs 31.

WDired

Writable Dired, so you can rename files by editing the buffer directly.

Eshell

This one I'm particularly proud of. Emacs Solo's Eshell configuration includes:

— Shared history across all Eshell buffers: Every Eshell instance reads from and writes to a merged history, so you never lose a command just because you ran it in a different buffer

— Custom prompts: Multiple prompt styles you can toggle between with C-c t (full vs. minimal) and C-c T (lighter vs. heavier full prompt)

— A custom welcome banner with keybinding hints

— History size of 100,000 entries with deduplication

Isearch

Enhanced incremental search with sensible defaults.

VC (Version Control)

This is one of the largest sections and one I'm most invested in. Emacs's built-in vc is an incredible piece of software that most people overlook in favor of Magit. I'm not saying it replaces Magit entirely, but with the right configuration it covers 95% of daily Git operations:

— Git add/reset from vc-dir: S to stage, U to unstage, directly in the vc-dir buffer. Admittedly, I almost never use this because I'm now used to the Emacs-style VC workflow: C-x v D or C-x v =, then killing what I don’t want, splitting what isn’t ready yet, and finishing with C-c C-c. Amending with C-c C-e is awesome. Still useful once or twice a semester.

— Git reflog viewer: A custom emacs-solo/vc-git-reflog command with ANSI color rendering and navigation keybindings

— Browse remote: C-x v B opens your repository on GitHub/GitLab in a browser; with a prefix argument it jumps to the current file and line

— Jump to current hunk: C-x v = opens the diff buffer scrolled to the hunk containing your current line

— Switch between modified files: C-x C-g lets you completing-read through all modified/untracked files in the current repo

— Pull current branch: A dedicated command for git pull origin <current-branch>

— Emacs 31 settings: vc-auto-revert-mode, vc-allow-rewriting-published-history, vc-dir-hide-up-to-date-on-revert

Smerge / Diff / Ediff

Merge conflict resolution and diff viewing. Ediff configured to split windows sanely (side by side, not in a new frame).

Eldoc

Documentation at point, with eldoc-help-at-pt (Emacs 31) for showing docs automatically.

Eglot

The LSP client that ships with Emacs. Configured with:

— Auto-shutdown of unused servers

— No event buffer logging (for performance)

— Custom server programs, including rassumfrassum for multiplexing TypeScript + ESLint + Tailwind (I wrote a whole post about that)

— Keybindings under C-c l for code actions, rename, format, and inlay hints

— Automatic enabling for all prog-mode buffers except emacs-lisp-mode and lisp-mode

Flymake / Flyspell / Whitespace

Diagnostics, spell checking, and whitespace visualization. All built-in, all configured.

Gnus

The Emacs newsreader and email client. Configured for IMAP/SMTP usage.

Man

Manual page viewer settings.

Minibuffer

Fine-tuned minibuffer behavior, including completion-eager-update from Emacs 31 for faster feedback during completion.

Newsticker

RSS/Atom feed reader built into Emacs. Customized with some extras I build my self for dealing with youtube feeds: thumbnail, transcripts, sending to AI for a quick summary, and so on.

Electric-Pair / Paren

Auto-closing brackets and parenthesis highlighting.

Proced

Process manager (like top, but inside Emacs).

Org

Org-mode configuration, because of course.

Speedbar

File tree navigation in a side window. With Emacs 31, speedbar gained speedbar-window support, so it can live inside your existing frame instead of spawning a new one.

Time

World clock with multiple time zones, sorted by ISO timestamp (Emacs 31).

Uniquify

Buffer name disambiguation when you have multiple files with the same name open.

Which-Key

Key discovery. Built into Emacs since version 30.

Webjump

Quick web searches from the minibuffer. Configured with useful search engines.

Language Modes

Specific configurations for every language I work with, organized into three areas:

Common Lisp: inferior-lisp and lisp-mode with custom REPL interaction, evaluation commands, and a poor man's SLIME/SLY setup that actually works quite well for basic Common Lisp development.

Non-Tree-sitter: sass-mode for when tree-sitter grammars aren't available.

Tree-sitter modes: ruby-ts-mode, js-ts-mode, json-ts-mode, typescript-ts-mode, bash-ts-mode, rust-ts-mode, toml-ts-mode, markdown-ts-mode (Emacs 31), yaml-ts-mode, dockerfile-ts-mode, go-ts-mode. Each one configured with tree-sitter grammar sources (which Emacs 31 is starting to define internally, so those definitions will eventually become unnecessary).

The Extras: 35 Self-Contained Modules

This is where the fun really is. Each of these is a complete, standalone Elisp file that reimplements functionality you'd normally get from an external package. They're all in lisp/ and can be used independently.

I call them "hacky reimplementations" in the spirit of Emacs Solo: they're not trying to be feature-complete replacements for their MELPA counterparts. They're trying to be small, understandable, and good enough for daily use while keeping the config self-contained.

emacs-solo-themes

Custom color themes based on Modus. Provides several theme variants: Catppuccin Mocha, Crafters (the default), Matrix, and GITS. All built on top of Emacs's built-in Modus themes by overriding faces, so you get the accessibility and completeness of Modus with different aesthetics.

emacs-solo-mode-line

Custom mode-line format and configuration. A hand-crafted mode-line that shows exactly what I want: buffer state indicators, file name, major mode, Git branch, line/column, and nothing else. No doom-modeline, no telephone-line, just format strings and faces.

emacs-solo-movements

Enhanced navigation and window movement commands. Extra commands for moving between windows, resizing splits, and navigating buffers more efficiently.

emacs-solo-formatter

Configurable format-on-save with a formatter registry. You register formatters by file extension (e.g., prettier for .tsx, black for .py), and the module automatically hooks into after-save-hook to format the buffer. All controllable via a defcustom, so you can toggle it on and off globally.

emacs-solo-transparency

Frame transparency for GUI and terminal. Toggle transparency on your Emacs frame. Works on both graphical and terminal Emacs, using the appropriate mechanism for each.

emacs-solo-exec-path-from-shell

Sync shell PATH into Emacs. The classic macOS problem: GUI Emacs doesn't inherit your shell's PATH. This module solves it the same way exec-path-from-shell does, but in about 20 lines instead of a full package.

emacs-solo-rainbow-delimiters

Rainbow coloring for matching delimiters. Colorizes nested parentheses, brackets, and braces in different colors so you can visually match nesting levels. Essential for any Lisp, and helpful everywhere else.

emacs-solo-project-select

Interactive project finder and switcher. A completing-read interface for finding and switching between projects, building on Emacs's built-in project.el.

emacs-solo-viper-extensions

Vim-like keybindings and text objects for Viper. If you use Emacs's built-in viper-mode (the Vim emulation layer), this extends it with text objects and additional Vim-like commands. No Evil needed.

emacs-solo-highlight-keywords

Highlight TODO and similar keywords in comments. Makes TODO, FIXME, HACK, NOTE, and similar keywords stand out in source code comments with distinctive faces. A small thing that makes a big difference.

emacs-solo-gutter

Git diff gutter indicators in buffers. Shows added, modified, and deleted line indicators in the margin, like diff-hl or git-gutter. Pure Elisp, using vc-git under the hood.

emacs-solo-ace-window

Quick window switching with labels. When you have three or more windows, this overlays single-character labels on each window so you can jump to any one with a single keystroke. A minimal reimplementation of the popular ace-window package.

emacs-solo-olivetti

Centered document layout mode. Centers your text in the window with wide margins, like olivetti-mode. Great for prose writing, Org documents, or any time you want a distraction-free centered layout.

emacs-solo-0x0

Upload text and files to 0x0.st. Select a region or a file and upload it to the 0x0.st paste service. The URL is copied to your kill ring. Quick and useful for sharing snippets.

emacs-solo-sudo-edit

Edit files as root via TRAMP. Reopen the current file with root privileges using TRAMP's /sudo:: prefix. A reimplementation of the sudo-edit package.

emacs-solo-replace-as-diff

Multi-file regexp replace with diff preview. Perform a search-and-replace across multiple files and see the changes as a diff before applying them. This one turned out to be more useful than I expected.

emacs-solo-weather

Weather forecast from wttr.in. Fetches weather data from wttr.in and displays it in an Emacs buffer. Because checking the weather shouldn't require leaving Emacs.

emacs-solo-rate

Cryptocurrency and fiat exchange rate viewer. Query exchange rates and display them inside Emacs. For when you need to know how much a bitcoin is worth but refuse to open a browser tab.

emacs-solo-how-in

Query cheat.sh for programming answers. Ask "how do I do X in language Y?" and get an answer from cheat.sh displayed right in Emacs. Like howdoi but simpler.

emacs-solo-ai

AI assistant integration (Ollama, Gemini, Claude). Send prompts to AI models directly from Emacs. Supports multiple backends: local Ollama, Google Gemini, and Anthropic Claude. The response streams into a buffer. No gptel, no ellama, just url-retrieve and some JSON parsing.

emacs-solo-dired-gutter

Git status indicators in Dired buffers. Shows Git status (modified, added, untracked) next to file names in Dired, using colored indicators in the margin. Think diff-hl-dired-mode but self-contained.

emacs-solo-dired-mpv

Audio player for Dired using mpv. Mark audio files in Dired, hit C-c m, and play them through mpv. You get a persistent mpv session you can control from anywhere with C-c m. A mini music player that lives inside your file manager.

emacs-solo-icons

File type icon definitions for Emacs Solo. The icon registry that maps file extensions and major modes to Unicode/Nerd Font icons. This is the foundation that the next three modules build on.

emacs-solo-icons-dired

File type icons for Dired buffers. Displays file type icons next to file names in Dired. Uses Nerd Font glyphs.

emacs-solo-icons-eshell

File type icons for Eshell listings. Same as above but for Eshell's ls output.

emacs-solo-icons-ibuffer

File type icons for ibuffer. And again for the buffer list.

emacs-solo-container

Container management UI for Docker and Podman. A full tabulated-list-mode interface for managing containers: list, start, stop, restart, remove, inspect, view logs, open a shell. Works with both Docker and Podman. This one started small and grew into a genuinely useful tool.

emacs-solo-m3u

M3U playlist viewer and online radio player. Open .m3u playlist files, browse the entries, and play them with mpv. RET to play, x to stop. Great for online radio streams.

emacs-solo-clipboard

System clipboard integration for terminals. Makes copy/paste work correctly between Emacs running in a terminal and the system clipboard. Solves the eternal terminal Emacs clipboard problem.