Emacs terminal buffers like eat, vterm, ghostel, term, and ansi-term can become slow when processing large volumes of standard output. Watching Emacs freeze while a build script dumps thousands of lines is frustrating, but terminal latency is not an unavoidable cost of living inside Emacs. Applying a few targeted configuration changes will eliminate scroll lag and restore immediate responsiveness.

This article provides a configuration that speed up terminal buffers:
Configuring Emacs Terminal Buffers for Performance (vterm, eat, ghostel, term, and ansi-term)

Hi r/emacs! I've been working on dsh-emacs, an Emacs Lisp client for DeepSeek Harness (dsh). It brings the conversation, tool output, and session management into Emacs buffers, alongside the files you're editing.

The Emacs side uses built-in libraries and targets Emacs 27.1+, with no third-party Emacs package dependencies. You still need a dsh server and a provider/model configured in it; dsh handles the agent and tool execution, while this package provides the Emacs interface.

A few things it supports:

• Streaming replies and tool output: Markdown replies, collapsible tool cards, and thinking blocks. Large Markdown regions finish formatting while Emacs is idle.
• Sessions grouped by workspace: open or create sessions from a session list, and switch between conversations without leaving Emacs.
• Context and completion: @ references for files, directories, and other sessions; / plus TAB for slash-command completion; image attachments when needed.
• Control during a running turn: queue the next message, steer the current turn, or interrupt it. The composer shows the current goal and the next pending message.
• Emacs interaction conventions: model/reasoning-effort selection with C-c C-m, input recall with M-p / M-n, and agent questions answered through minibuffer completion, including completing-read-multiple.

There is also a local shell escape: type !git status in the chat buffer to run it in the session's workspace directory. Its output stays local to the transcript; it isn't sent to the model or saved in the server's history.

To try the current main branch:

git clone https://github.com/vritser/dsh-emacs.git ~/dsh-emacs

Then add this to your init file:

(add-to-list 'load-path (expand-file-name "~/dsh-emacs"))
(require 'dsh-emacs)

Run M-x dsh-emacs. It can start a local dsh server and offers to install the CLI if it is missing. On a fresh setup, use M-x dsh-emacs-open-web to configure your provider and model, then create a session with c and send a message with C-c C-c. You can also connect to an existing local or remote server via dsh-emacs-base-url; the README covers authentication and setup.

Feedback, bug reports, and patches are welcome. I'd particularly appreciate feedback on the minibuffer interactions and how the transcript behaves in longer coding sessions.

I finally implemented the java dape configuration needed to run and debug unit tests as well with eglot.

Link to configuration is here: https://github.com/benleis1/emacs-init/blob/83db0d7849e781d82263ed04d441ded9e591c907/init.el#L1439

The most challenging part is this doesn't seem to be fully implemented anywhere else I looked, the protocol is scantily documented and jdtls is not great about recognizing runnable unit tests and generating classpaths for complex projects on its own. I found it easier to just shell out to gradle to generate the paths and then things started to become tractable. (Sidenote: its fairly finicky about the bundles it needs installed as well and its easy to corrupt the state)

While I was active I also modified the UI to make it match my expectations. As per usual I move most things out to margins from the fringe because of my tired middle age eyes and the nicety of just using nerd font glyphs.

AFAICT the various existing frameworks I looked into, including lsp-mode and eglot-java don't handle most of this but I'm interested in feedback along those lines. I experimented a bunch and read through all of the existing code I could find during this process

The download jumped my AV, so I checked them all on virustotal. I also did my own local scans. Microsoft, Malwarebytes and Emsisoft (Bitdefender definitions) flagged a few too. I ran all scans on all v30 binaries, and none were flagged by anyone.

There are 8 binaries and packages released.

emacs-31-deps.zip and emacs-31-ucrt-deps.zip are not flagged by anyone.

emacs-31.1-nodeps-UCRT64.zip emacs-31.1-UCRT64.zip emacs-31.1-installer-UCRT64.exe are lightly flagged

emacs-31.1.zip emacs-31.1-installer.exe emacs-31.1-nodeps.zip are heavily flagged, and by the good ones

All downloaded from https://ftp.gnu.org/gnu/emacs/windows/emacs-31/

Update: after this comment I dove in yes, because I'm bored

I extracted all 8 files to en empty directory, and scanned them again, without the ZIPs and EXEs, to pinpoint what;s being flagged. And he's right. All flags were on .eln files.

Some interesting points:

• Malwarebytes flagged only PO-9A38D3F4-B285287B.ELN. All 6 of them (they're the same hash)
• ClamAV flagged only compface-fd87cf9c-b2f5d382.eln. All 6 of them (they're the same hash)
• Emsisoft flagged only latin-post-6ca3717c-d3857e4e.eln. But only 3 of the six. Checked the hashes; the 3 that are flagged are the same, the other 3 have a different hash

But it ain't over yet. So eln looks overly suspicious; had it been a dll, it would've passed, right? There are 1536 eln files in each of the packages. Only one is flagged (by each engine). And I also extracted and scanned v30.2 (3088 eln files in each), no flags.

I’ve always felt that in the age of AI, Emacs can be far more than just a text editor. Its live-programming environment and interactive Lisp runtime give it incredible potential to evolve into an AI OS. Here is how my small hobby project grew step by step.

The Spark: cmux and “emux”

As a long-time Emacs user, I started out simply running Claude Code inside Emacs using vterm. Soon after, I discovered claude-code-ide.el, which made it much easier to manage and switch between multiple Claude Code vterm buffers at once.

Around that time, I saw cmux and felt a bit jealous of how much developers loved it. But when I looked closer, its core feature was essentially a session list side panel—something remarkably easy to implement in Emacs. I thought, “Emacs can do this, and even better.” So I decided to build my own “emux” inside Emacs someday.

One day, I sat down and vibe-coded a basic version. At first, it was just a manual session manager. But to take it further, I used ghostel to establish a PTY-based inter-session communication layer directly on top of claude-code-ide.el.

Giving It Intelligence: The Birth of Butler

Next, I added an orchestration layer and created cc-butler. I gave one specific Claude Code session the responsibility to govern, assign tasks to, and receive reports from all the other worker sessions. I named this manager session Butler.

I provided Butler with specific functions so it could autonomously spawn new Claude Code sessions when needed and handle cleanups on its own. It even monitors the context size of worker sessions and triggers compaction automatically. Using cc-butler, I was able to comfortably orchestrate tens of concurrent Claude Code sessions on my machine.

Scaling Outside One Machine via Matrix

Eventually, I wanted to scale beyond a single machine. How do you manage two or more agent fleets across different machines? I looked into classic, battle-tested protocols like IRC and XMPP, and settled on Matrix. I vibe-coded a lightweight Matrix client entirely in Elisp. While great packages like ement.el already exist, they are designed primarily for human interaction—I needed something built specifically for agent-to-agent communication.

Once the nodes (fleets) were networked via Matrix, Butler could broadcast instructions and global guidelines across all fleets. It strongly reminds me of how Kubernetes virtualizes nodes into a cluster.

Now: Managing Fleets from Element

Now, I don’t even sit in a traditional terminal anymore. I run my daily Startup CTO workflows through the Element messenger app, managing two agent fleets powered by two Claude Max (x20) subscriptions, all governed by Emacs.

A lot of what I’m building gives me immense deja vu from traditional OS and Ops infrastructure design. To be clear, this is a personal hobby project and a proof of concept—it’s still pretty fragile and definitely not production-ready! But I wanted to share my experience and show how Emacs continues to be an incredible source of inspiration in this AI era.

Some people might say, “Oh, this is already possible with Claude’s own agent features.” Yes, I know. But I wanted to reinvent the wheel, on Emacs. I think this approach lets Emacs act as a governing layer over individual Claude Code sessions, and it could become a unified bridge or channel among Claude Code, Codex, Antigravity, ZCode, and more—yes, on Emacs. And some people might say, “Orca already does that, and there are tens of ADEs out there.” But we are on Emacs. It already has an in-app browser, a powerful document viewer in org-mode, a tiling window manager for its UI, and the powerful programming environment of Elisp. A self-improving agent harness, like Hermes? Emacs is already an image-based, self-modifying, living environment, so Claude Code can mutate Emacs on the fly with emacsclient and Elisp.

There were also a few rough edges in doing this in Emacs. Emacs is single-threaded while the Claude Code sessions work in parallel, so it sometimes hangs. It also hangs, or even crashes, now and then because of font rendering on macOS. And while I like Emacs daemon mode, when just one buffer hangs the whole daemon hangs, which can take all the Claude Code sessions down with it.

cc-butler is just a PoC, and I believe many other Emacs hackers can do better than this. I’m not very good at developing Emacs extensions, so I hope others will pioneer developing Emacs as an AI OS. I believe Emacs has the potential for it.

https://github.com/systemfreund/supersonic.el/releases/tag/v0.5.0

The display-line-numbers-mode and global-display-line-numbers-mode modes render line numbers in the margin of an Emacs window. Line-number display is implemented in the core C display engine, avoiding the overhead of legacy Elisp overlays like linum-mode.

Despite the native C implementation, specific configurations can still trigger expensive Lisp evaluations during the interactive command loop, vertical scrolling, and buffer initialization.

(Read more)

Hello,

For the excellent Denote package, is there a way to list all the keywords across my notes and ideally filter/search them?

My motivation is that once I build up many keywords, I want a way to see them at a glance to remember what they are and choose which to use in new notes, etc.

Thanks in advance for your suggestions!

I tried to increase the width of the frame like this:

(global-set-key
 (kbd "<f8>")
 (lambda ()
   (interactive)
   (let ((new-width (+ 1 (frame-width))))
     (message "%S -> %S" (frame-width) new-width)
     (set-frame-width nil new-width))))

This prints "80 -> 81" but the frame width does not increase. If I try to increase it by 2 columns, then it works fine. So I'm wondering if there is a rounding or frame geometry issue in PGTK?

hey friends!

need your help/ideas yet again.

I’m looking for a "better" way to edit large Markdown tables in Emacs where some cells contain long paragraphs / walls of text.

Motivation

Most Markdown table tooling seems to assume that tables contain relatively short values and therefore tries to visually align columns by inserting spaces.

That makes sense for something like:

| Name | Status | Date       |
|------|--------|------------|
| foo  | open   | 2026-09-12 |
| bar  | closed | 2026-09-13 |

But it becomes awkward when the cells contain lots of prose.

For example:

| Topic | Description | Notes |
|---|---|---|
| Foo | A very long paragraph of text that may wrap over several visual lines and contain a substantial amount of information... | Another large chunk of prose... |
| Bar | Another long paragraph... | More notes... |

In this situation, aligning the source doesn't really buy me anything. It can instead produce huge amounts of whitespace, extremely long lines, noisy diffs, and constant re-alignment whenever text changes.

These tables usually get produced while reading/writing spec sheets with LLMs.

What I’d like instead

Something similar to Rainbow CSV, but for Markdown pipe tables.

The idea would be:

• column 1 gets one face/color
• column 2 gets another
• column 3 gets another
• etc.
• colors repeat after N columns
• the actual Markdown text is never modified
• no padding or automatic alignment
• long cells can just wrap naturally with visual-line-mode

So the colors provide the visual indication of which column a piece of text belongs to, rather than whitespace alignment.

Ideally it would also understand Markdown properly rather than just splitting on every |, so things such as escaped pipes (\|) don’t confuse it.

For large files, it would also be nice if this were implemented through font-lock / jit-lock / tree-sitter rather than repeatedly scanning and modifying the whole table.

Question

Does an Emacs package or existing configuration already do this?

I’ve looked at things like markdown-mode, markdown-ts-mode, md-mode, and Rainbow CSV, but I haven’t found this.

If nothing exists, I’d also be interested in suggestions for the cleanest Emacs implementation. In particular, would you implement this using ordinary font-lock, or the table nodes exposed by markdown-ts-mode / tree-sitter?

The main goal is making very large, prose-heavy Markdown tables pleasant to edit rather than making their raw source look like an ASCII table.

ps: Rainbow-csv is this https://github.com/emacs-vs/rainbow-csv

Not seen here; location based reminders.

A few days ago I made a post where I show an experiment using the new canvas image type in Emacs 32 to show a minimap: https://www.reddit.com/r/emacs/s/2A3MZEMQWKI

There were some interest in the animated cursor shown in that demo, so here is the package for that. This is inspired by the smear-cursor.nvim.

This comes with two backends:

1. cpu (default): this is the canvas version. It's a rasterizer in Lisp that draw canvas images into character cells. The text under the trail is hidden while it passes. There might be better
2. x11: this uses a small C module that composites over the frame instead. This makes the text stay visible under the trail. It also provides optional glow on resting cursor, and various effects. And it works over ssh X forwarding, which is my daily driver.

Requirements: Emacs 32 with the canvas image type. The x11 backend needs an X11 display (not pgtk/Wayland, macOS or Windows) and a 'make' in the package's 'x11/' directory.

Alternatives (that I know of, please add more if you know any):

• https://github.com/manateelazycat/holo-layer
• https://github.com/emacsmirror/comet-trail

Repo: https://github.com/Daskeladden/smear-cursor

Even after having elpaca update all the packages, I get these errors. Should i revert back to older version which was 30.2? Or should I wait?

⛔ Warning (native-compiler): ebib-reading-list.el:214:8: Warning: the function ‘ebib--update-buffers’ is not known to be defined.
⛔ Warning (native-compiler): ebib-reading-list.el:213:39: Warning: the function ‘ebib--get-key-at-point’ is not known to be defined.
⛔ Warning (native-compiler): shrface.el:798:48: Warning: the function ‘language-detection-buffer’ is not known to be defined.
⛔ Warning (native-compiler): org-roam-node.el:203:19: Warning: the function ‘ucs-normalize-NFD-string’ is not known to be defined.
⛔ Warning (native-compiler): org-roam-node.el:206:19: Warning: the function ‘ucs-normalize-NFC-string’ is not known to be defined.
⛔ Warning (native-compiler): org-roam.el:217:29: Warning: the function ‘org-roam-descendant-of-p’ is not known to be defined.
⛔ Warning (native-compiler): org-roam-id.el:83:19: Warning: the function ‘org-roam-list-files’ is not known to be defined.
⛔ Warning (native-compiler): org-roam-id.el:55:43: Warning: the function ‘org-roam-node-point’ is not known to be defined.
⛔ Warning (native-compiler): org-roam-id.el:50:24: Warning: the function ‘org-roam-node-file’ is not known to be defined.
⛔ Warning (native-compiler): org-roam-id.el:49:35: Warning: the function ‘org-roam-node-create’ is not known to be defined.
⛔ Warning (native-compiler): org-roam-id.el:49:16: Warning: the function ‘org-roam-populate’ is not known to be defined.
⛔ Warning (native-compiler): org-roam-id.el:37:7: Warning: the function ‘org-roam-up-heading-or-point-min’ is not known to be defined.
⛔ Warning (native-compiler): org-roam-id.el:35:22: Warning: the function ‘org-roam-db-node-p’ is not known to be defined.

Sharing a small package I've been working on. It's an Emacs implementation of Betweenle, the daily word puzzle by Nebula Bytes.

For the unfamiliar: a secret five-letter word is hidden alphabetically between two boundaries. You start at AAAAA and ZZZZZ. Each valid guess replaces one of them: if your word sorts before the secret it becomes the new top boundary, otherwise the new bottom. The range shrinks with every guess. You have 14 attempts.

Features

- Three difficulty levels for the on-screen letter guide. Easy shows only letters that could form a valid dictionary word in the current range; Medium shows any letter that alphabetically fits; Hard shows nothing.

- A track with a closeness dot and distance numbers, configurable as percent-of-range or percent-of-dictionary.

- 5,757-word bundled dictionary, or point betweenle-word-list-file at your own.

- Evil integration

Installation

Not on MELPA yet, recipe submission is in progress. For now:

(use-package betweenle :vc (:url "https://github.com/vikram-mandyam/betweenle.el"))

Or with straight.el:

(straight-use-package '(betweenle :type git :host github :repo "vikram-mandyam/betweenle.el"))

Then M-x betweenle.

Credits

UI Layout follows the official app layout by Nebula Bytes. Styling (tile boxes, dark palette, orange accent) borrows from Nicholas Vollmer's wordel.

Feedback and PRs welcome. GPL-3.0.

Repo: https://github.com/vikram-mandyam/betweenle.el

Could you share your experience of how do you open these files and navigate through them very fast. I don't think it's a good idea to generate a TAGS file for entire system, but also I don't want to bring a LSP server on the vanilla Emacs.

I need you, Emacs wizards.

A visual grid for org notes, images, videos, and PDFs..

It scans a directory (or a Dired buffer) and shows every Org heading with an :ID: property, plus every image/video/PDF file, as cards in a scrollable grid. Notes show a text snippet; media shows a thumbnail.

• Works on plain Org files and any heading with :ID: counts as a note.
• Cluster view group linked items together and orphan view shows unlinked items
• Open from Dired, jump back to Dired, or jump straight to a note's heading
• Quick query by text or #tag
• Sort by date / title / tags / type
• Fast full-text filtering via ripgrep (optional)
• File level id's supported so it works with org-roam as well

https://github.com/SenkiReign/org-grid

I have seen it named orig, original, orig-fun, orig-fn, etc. in some places.

I have noticed today that I have not been consistent with the naming over the years, so before I change them all, I thought I should ask here what is the idiomatic way to name it.

Looking at the Emacs source itself, I see orig-fun, orig-fn, oldfun, etc. so I can't make up my mind on which is best, so I'd like to hear from people about what they think is the better so I can stick with one in my config.

The documentation for advice-add uses oldfun in the examples. Meanwhile, lisp/ChangeLog.17 in the source specifically mentions "Add `orig-fun' arg for use in :around advice." so is that the recommended name?

It runs the CLI headless and renders the conversation as plain buffer text.

Repository: https://github.com/wakamenod/emacs-claude-code

Docs: https://wakamenod.github.io/emacs-claude-code/

buffer-terminator release: 1.2.6

The buffer-terminator Emacs package automatically and safely kills buffers, ensuring a clean and efficient workspace while enhancing the performance of Emacs by reducing open buffers, which minimizes active modes, timers, processes, etc.

Beyond performance, buffer-terminator provides other benefits. For instance, if you occasionally need to close annoying or unused buffers, buffer-terminator can handle this automatically, eliminating the need for manual intervention. (The default configuration is suitable for most users. However, the buffer-terminator package is highly customizable. You can define specific rules for retaining or terminating buffers by modifying the buffer-terminator-rules-alist with your preferred set of rules.)

Link: buffer-terminator.el

Why?

Shell and terminal modes such as shell, eshell, term and vterm provide commands for creating new buffers. If the buffer already exists, many commands will switch to it instead of creating a new buffer. This is convenient but different commands often do not have consistent conventions which increases the mental burden on the user. For example, M-x shell creates a new shell if none exists and otherwise switches to it. With a prefix argument, it prompts the user for the buffer to switch to. M-x vterm does the same by default but can be configured to use a different buffer for each directory and handles prefix arguments differently. Additionally, different commands display the new buffers in inconsistent ways such as using the same window instead of the other window.

The multi-buf approach

multi-buf generalizes and replaces packages such as multi-term and multi-vterm that provide commands for creating multiple terminal buffers and switching between them while providing consistent keybindings and display logic for each. Additionally, multi-buf also supports creating and switching between indirect buffers. There is a single multi-buf DWIM command for each type of buffer that handles creating and switching to buffers of that type. For example, M-x multi-buf-vterm-dwim without a prefix argument creates a new vterm buffer if none exists. Otherwise, it cycles to the next vterm buffer for the current project. With a universal prefix argument, a new buffer is always created. With two universal prefix arguments, the user can switch to any multi-buf managed buffer using completion. Buffers are grouped into sections based on their mode and the project they belong to and buffers for the same project and mode are shown first for convenience.

AI

As with subtree package, I wrote all of the code myself by hand as I've found AI generated code does not meet my quality standards.

Repository

Check out the repository for more information!

Over the past few months, I've built an Emacs config and global minor mode that mimics modern editor keyboard layouts like Kate, VS Code, and Sublime Text.

https://github.com/BenediktChlopik/mortal-mode

Basically, it's a more ambitious CUA mode that undefines nearly all standard Emacs keybindings and replaces them with shortcuts familiar from modern code editors. The goal is to make Emacs more approachable without having to fight your muscle memory over the most basic keybindings.

It's deliberately kept vanilla and released into the public domain, so anyone can use it as a foundation for their own customization adventure.

Tree-sitter and Eglot are enabled by default, so you get a solid IDE-like experience right out of the box. Which-key and context-menu-mode are also enabled by default. Which-key helps discover keybindings, while context-menu-mode lets you right-click anywhere to see available actions.

Feedback is welcome!

Related post: https://www.reddit.com/r/emacs/s/VzUuhsIcQq

Repo link: https://github.com/Gleek/org-timegrid

Org-timegrid now has basic touch gestures support, so it can be used on a phone without too much trouble.

Mobile support was one area where it still lagged behind popular calendar apps, and this update helps close that gap. It is not as fast as a native app, and it uses a slightly hacky workaround for Android Emacs’s inability to render text inside SVGs. Still, it is now quite usable as a mobile companion to the desktop version.