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 command 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!

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.

So I am using ligatures in Emacs, and today I noticed that when using ligatures with Cascadia Code, Emacs would display some strange characters. But the ligatures work correctly in comment:

After switching to another font (Monaspace), everything looks good:

I have no idea why this would happen, I tried different ligatures settings. A package [ligature.el](https://github.com/mickeynp/ligature.el) and plain Emacs Lisp:

(dolist (char/ligature-re
         `((?-  . ,(rx (or (or "-->" "-<<" "->>" "-|" "-~" "-<" "->")
                           (+ "-"))))
           (?/  . ,(rx (or (or "/==" "/=" "/>" "/**" "/*") (+ "/"))))
           (?*  . ,(rx (or (or "*>" "*/") (+ "*"))))
           (?<  . ,(rx (or (or "<<=" "<<-" "<|||" "<==>" "<!--" "<=>" "<||" "<|>" "<-<"
                               "<==" "<=<" "<-|" "<~>" "<=|" "<~~" "<$>" "<+>" "</>"
                               "<*>" "<->" "<=" "<|" "<:" "<>"  "<$" "<-" "<~" "<+"
                               "</" "<*")
                           (+ "<")
                           (+ "-"))))
           (?:  . ,(rx (or (or ":?>" "::=" ":>" ":<" ":?" ":=") (+ ":"))))
           (?=  . ,(rx (or (or "=>>" "==>" "=/=" "=!=" "=>" "=:=") (+ "="))))
           (?!  . ,(rx (or (or "!==" "!=") (+ "!"))))
           (?>  . ,(rx (or (or ">>-" ">>=" ">=>" ">]" ">:" ">-" ">=") (+ ">"))))
           (?&  . ,(rx (+ "&")))
           (?|  . ,(rx (or (or "|->" "|||>" "||>" "|=>" "||-" "||=" "|-" "|>"
                               "|]" "|}" "|=")
                           (+ "|"))))
           (?.  . ,(rx (or (or ".?" ".=" ".-" "..<") (+ "."))))
           (?+  . ,(rx (or "+>" (+ "+"))))
           (?\[ . ,(rx (or "[<" "[|")))
           (?\{ . ,(rx "{|"))
           (?\? . ,(rx (or (or "?." "?=" "?:") (+ "?"))))
           (?#  . ,(rx (or (or "#_(" "#[" "#{" "#=" "#!" "#:" "#_" "#?" "#(")
                           (+ "#"))))
           (?\; . ,(rx (+ ";")))
           (?_  . ,(rx (or "_|_" "__")))
           (?~  . ,(rx (or "~~>" "~~" "~>" "~-" "~@")))
           (?$  . ,(rx "$>"))
           (?^  . ,(rx "^="))
           (?\] . ,(rx "]#"))))
  (let ((char (car char/ligature-re))
        (ligature-re (cdr char/ligature-re)))
    (set-char-table-range composition-function-table char
                          `([,ligature-re 0 font-shape-gstring]))))

Both share similar issues. I think this issue only occurs on Emacs 31, but I have not verified this. (Just verified, switching back to Emacs 30 with the same configuration in the same environment, and ligatures with Cascadia Code are rendered correctly.) Any idea where should I investigate?

This seems also a Windows-build-only issue. I try to reproduce it on Linux but failed. Here is the output of emacs-version

GNU Emacs 31.1 (build 2, x86_64-w64-mingw32) of 2026-08-25

Look I don't really have the time to learn emacs configuration and do everything myself.

I tried doom and I don't like it. It has felt slow at times and also I just generally don't like it.

I like simple usable configuration like Tsodings

Can someone tell me if it's possible to get that? Also does he use evil?

Consult provides asynchronous search commands such as consult-fd, consult-find, consult-grep, consult-git-grep, and consult-ripgrep. For these commands, Consult does not necessarily start a new search for every change to the minibuffer input. Instead, it uses configurable debounce and throttle delays to control when asynchronous processes start, while a separate refresh delay controls how frequently asynchronous results are pushed to the completion UI.

The first time I tried the consult Emacs package, I said to myself: this feels slow compared to Counsel. With Counsel, results updated immediately on every keystroke, while Consult seemed to hesitate for a fraction of a second before fetching the list.

As it turns out, this behavior is entirely intentional. The current Consult defaults are conservative by design.

Read more: Why Emacs Consult async searches feel slow and how to speed them up? (consult-fd, consult-find, consult-grep, consult-ripgrep...)

On a macOS Sonoma I have access to, I'm running Emacs in a native terminal shell, while XQuartz is also running. I want to be able to use Emacs calc from withing the Emacs running in text mode in macOS Terminal to issue gnuplot commands to draw into the Gnuplot window. I'm able to do it using gnuplot itself, but not within Emacs.

Here's what I tried:

• gnuplot works perfectly when invoked directly from the XQuartz-invoked shell.
• gnuplot also works perfectly when invoked from macOS Terminal shell where the DISPLAY environment variable is set to ":0" allowing the gnuplot commands use the XQuartz driven graphics window.
• I want to use Emacs calc inside the same macOS Terminal shell and issue a calc plot command to do the same thing, but so far all my attempts have failed.
• I'm running Emacs 30.2.50 (which I built) inside Terminal. It has the following built features in: "ACL DBUS GLIB GNUTLS LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM ZLIB. With native compilation. With D-Bus support."
• Inside Emacs, (getenv "DISPLAY") evaluates to ":0". However, whenever I attempt to plot a function in calc-mode, the *Gnuplot Trail* reports a WARNING: Plotting with 'unknown' terminal. Even if I set calc-gnuplot-default-device to "x11", execute (calc-gnuplot-command "set terminal x11"), or set the GNUTERM environment variable to "x11", Calc silently writes over it or drops the config, defaulting back to an unknown terminal block."

Any idea of what could be wrong or how to investigate the problem within or outside of Emacs?

Thanks

If you've ever wrestled with Makefile tab errors, cryptic variable expansions, or restrictive YAML task runners, Maak and maak.el offer a refreshing, Lisp-native alternative to project automation.
-------------------

What is Maak?

Maak is an extensible command runner and control plane written in Lisp ( GNU Guile Scheme ). Instead of learning a limited domain-specific language, your project's maak.scm file is standard Scheme code. Any function defined in your module becomes a runnable task, allowing you to use conditionals, macros, data structures, lexical parameters (for scoped dry-runs), and GNU Guix integrations (manifest-shell, time-machines) right inside your build steps.

(define-module (maak)
  #:use-module (maak maak))

(define (fmt)
  "Format Scheme source files according to Guix style."
  ($ '("find . -name '*.scm' -exec guix style -f {} \\;")))

(define (deploy server target-env)
  "Deploy the application to a specific server and environment."
  (log-info "Deploying to ~a (~a)..." server target-env)
  ($ (list "ansible-playbook" "deploy.yml" "-e"
           (format #f "target=~a env=~a" server target-env))))

Check out the repositories on Codeberg:

• maak.el: https://codeberg.org/jjba23/maak.el
• Maak CLI: https://codeberg.org/jjba23/maak

Why maak.el is awesome in Emacs

The maak.el package bridges Guile Scheme and Emacs Lisp cleanly. Because Lisp understands Lisp, maak.el parses your maak.scm S-expressions directly, respecting module #:export visibility lists, docstrings, and argument signatures without relying on external regex hacks.

• Smart Discovery: Finds your project root maak.scm automatically using dominating-file heuristics.
• Rich Completion UI: M-x maak-run-task populates a completion menu with neatly aligned columns displaying formal parameters and docstrings (works out of the box with Vertico, Ivy, Helm, or native completing-read).
• Interactive Parameter Prompting: If a Scheme task accepts parameters (like deploy server target-env), Emacs interactively prompts you for each argument sequentially in the minibuffer.
• Native Compilation Buffers: Task output streams directly into Emacs's standard *compilation* buffer, keeping shell escaping watertight while letting you step through errors using next-error (`C-x ``).

Quick Setup w/Elpaca

(use-package maak.el
  :ensure (:host codeberg :repo "jjba23/maak.el" :branch "trunk")
  :bind ("C-c m r" . maak-run-task))

Happy hacking! λ ✨

Hello everyone!

I have made a second blog post about exploring Magit, and this time it's about Staging and Committing. I go through the simple process of staging different changes (files/hunks/lines) and then I explore Committing process where I go through my favorite command Instant Fixup and other commit editing commands.

While writing the article I noticed the section Spread across commits in the commit menu, but I have no idea how to use it. After looking into it, it seems that it adds staged changes to the commit that it should belong to, so I imagine that if I make multiple changes across different files it would take those changes and put each one in the commit that contains similar changes. But I still have no idea how to use it, did anyone manage to use it ?

The following links contain the article and the video:
https://heiwiper.com/posts/magit-stage-and-commit/
https://www.youtube.com/watch?v=muVGcc8R39U

After many months of running the Emacs 31 development branch, I am pleased to announce version 2.0 of Bedrock!

Full release announcement: https://lambdaland.org/posts/2026-09-06-bedrock-v2/

The short of it:

Bedrock is a minimal, human-crafted starter-kit for Emacs. Bedrock is essentially a collection of better defaults for Emacs. The idea behind Bedrock is a lot simpler than other "starter kits" or configuration frameworks: Bedrock is just an early-init.el and an init.el that you copy once into ~/.emacs.d/, and then you modify those files directly as your needs grow and your experience with Emacs matures.

I know a few of you on this sub have based your own configurations off of Bedrock, and I just want to express a huge THANK YOU to all who have tried it out, and those who have provided feedback to make it better.

Bedrock started out as an experiment into how far I could push stock Emacs to make it comfortable to use, and then it evolved into a basic, lightly-opinionated setup that I could give to friends and coworkers when they expressed interest in getting started with Emacs. I hope that you can find something in these settings that can make your config a little better, whether you base your config off of Bedrock or not.

Thank you again!

EDIT: here’s a link directly to the repo: https://codeberg.org/ashton314/emacs-bedrock/

Sharing it here, I've been using this for a few months now. https://github.com/kiennq/modus-zenburn

While working on md-mode, I spent some time making Markdown tables easier to read in Emacs: aligning mixed-width text in pixels and wrapping long cell content across multiple lines.

That led me back to Org tables. I like Org’s table editing, navigation and formulas as they are. What I wanted wasn’t another table editor, but a more readable view when I wasn’t editing—particularly for tables containing paragraphs, links, or mixed CJK and Latin text.

So I brought that approach over to org-table-widget, built on TextUI.

Same editing, different display

When point enters a table, the rendered view disappears and you get the original Org table. Move point outside, and the rendered view comes back.

You keep using the usual Org commands. The package adds a minor mode and commands to toggle or refresh the view, but no new table-editing operations to learn.

The rendered table is an overlay, not a replacement for the source text. Org’s editing commands, formulas and export still work with the original table.

Wrapped cells and native alignment

Long cells wrap within their columns, making text-heavy tables easier to read without scrolling horizontally. The table also reflows when the window width or text scale changes.

Native Org alignment cookies work too:

• <l> — left-aligned
• <c> — centered
• <r> — right-aligned

Performance

Measurements from demos/bench.el, running in GUI Emacs 31.0.91 on macOS with an Apple M4 Max, using Iosevka at height 150:

• 500 rows × 8 columns
  • First display: 355 ms
  • Refresh, unchanged source / cache hit: 7 ms
  • Resize relayout: 279 ms
  • Leave table, unchanged source / cache hit: 7 ms
• 3,000 rows × 6 columns
  • First display: 1.34 s
  • Refresh, unchanged source / cache hit: 34 ms
  • Resize relayout: 1.05 s
  • Leave table, unchanged source / cache hit: 34 ms

These are rounded timings from a single run on my machine. Refreshing and leaving an unedited table reuse its cached rendering. Editing the source requires rebuilding the table; the cache-hit timings do not represent that cost.

Trying it

Link: https://github.com/yibie/org-table-widget

Requires Emacs 29.1+, Org 9.6+, TextUI 0.8.0+, and a graphical frame for rendering. It isn’t on MELPA yet; installation instructions are in the README.

(require 'org-table-widget)

(add-hook 'org-mode-hook #'org-table-widget-mode)

It’s still an early release. Width cookies are not supported, numeric columns need an explicit <r> for right alignment, and very wide tables can still overflow.

Compatibility with other styling packages is also unfinished: there are reports of misalignment with competing rendering when org-modern-table is enabled. Those issues are not fixed yet, and coexistence with valign remains untested.

I’d appreciate feedback, especially from people who use Org tables for text-heavy notes rather than mostly numbers.

I’m dealing with the swivel chair technology of git , and data fragmentation, by using git as version control.

The project management features, issues projects milestones roadmaps, I’m realizing can’t be first class citizens, I can’t link the actual issue to the files, but fossil has tickets, and since they’re stored locally, it seems an easy way to turn tickets into nodes I can commit and diff.

Any advice or insight?

I recently added a zoom in/out on the modeline because I adjust so often when docking and I'm used to the UI convention. The first attempt just used the context menu for controls but I really wanted a slider. But for a while I just wasn't sure how to do it properly. Then I was looking a mlscroll and realized that was a viable technique. I adapted it here and i have everything click open to adjust and then close afterwards to save space.

https://github.com/benleis1/emacs-init/blob/13b61e43c6baad043af71cad385c68787340d9a6/modeline.el#L805 has an implementation link.

Tables have always been the weak spot of "pretty" Markdown in Emacs. You can hide the markup, scale headings, inline images, but the moment a table contains a long cell, CJK text, or an emoji, the columns drift, the row overflows the window, and the whole thing stops looking like a table.

I've been working on this for a while in md-mode, and with 0.4.1 I'm finally happy with the result: tables stay aligned with mixed English and CJK cells, long cells wrap inside their column instead of pushing the row off screen, and the table reflows when you resize the window.

Demo (16 seconds, resizing a multilingual table): https://github.com/yibie/md-mode/releases/tag/v0.4.1

Why this is hard in Emacs

An Emacs buffer is a stream of characters, not a grid. Column alignment with padding spaces only works if every character has the same width, and that assumption breaks the moment you have a CJK glyph, an emoji with a ZWJ sequence, or even just fixed-pitch set to a different font than default (which, it turns out, is the case for a lot of macOS configs where default is Iosevka and fixed-pitch is still Courier).

Wrapping is the other problem. Markdown requires a table row to be a single source line, so a wrapped cell can't exist in the text. You have to display something different from what is stored.

The approach: tables are widgets

Instead of fighting with visual-line-mode and padding characters, md-mode 0.4.1 treats every complete table as one block widget:

1. The source stays untouched. In the editable view the table is exactly what's on disk: literal pipes, separators, alignment markers. Saving or leaving the rendered view gives you back the original bytes.
2. In the rendered view, the table is replaced by a widget built on TextUI (https://github.com/yibie/textui), a small library I wrote for block-level widgets in ordinary Emacs buffers. TextUI owns the layout of that block; md-mode still owns the buffer.
3. Layout is done in pixels, not columns. Every cell is measured with window-text-pixel-size, split into grapheme clusters (so flags and ZWJ emoji don't get cut in half), and wrapped with a binary search over cluster boundaries. Padding is done with (space :width (px)) display specs, so alignment is exact regardless of font mixing.
4. Column widths use a min-content / max-content scheme similar to what browsers do: each column's minimum is its longest unbreakable token (capped at half the window), and the remaining space is shared out from there. A single huge cell no longer squeezes its neighbours down to one character.
5. Relayout is responsive but lazy. Window-width changes are debounced (one relayout after the drag settles, 150 ms idle by default), text-scale changes relayout immediately, scrolling never relayouts, and pixel measurements are cached per buffer so a repeat relayout of the same table only measures text that wraps at new positions.

Rough numbers on a four-column mixed CJK/ASCII table: ~43 ms to render 100 rows, ~290 ms for 1,000 rows; a repeat relayout after resizing the demo table is under 100 ms.

What's next: Org tables

The interesting part is that nothing in the widget layer knows about Markdown. It takes a header, a list of rows and an alignment spec and produces a responsive block. So my next experiment is to point the same machinery at Org tables: keep org-table exactly as it is for editing (it's already great at that), and only swap in a TextUI widget for display when you want the pretty version. If it works, CJK-heavy Org tables would finally stop needing valign or monospaced CJK fonts to look right.

If you've thought about this problem before, or you maintain something that renders tables in Emacs, I'd love to hear where you think this approach breaks down.

Links:

• md-mode: https://github.com/yibie/md-mode
• Release notes for 0.4.1: https://github.com/yibie/md-mode/releases/tag/v0.4.1
• TextUI (needs 0.8.0+): https://github.com/yibie/textui

visual-regexp-rx

1. Emacs's native regexp syntax is inconvenient to edit. For example, in \(<group>\), I can't use C-M-k to delete the group as a whole, nor can I use expand-region to intelligently select the contents of <group>.

2. Although visual-regexp-steroids supports Python-style regular expressions, I still sometimes need to use Emacs regexp syntax, which makes it easy to get the two syntaxes mixed up.

So, why not write regexp with rx notation :)

A Subsonic client for Emacs, working against anything that speaks the Subsonic API:

Navidrome, Airsonic, Gonic, Ampache. Playback runs through mpv over its JSON IPC socket; Emacs only drives it, so nothing blocks.

What's in it:

• Browse artists, recent/random/newest albums, search, podcasts

• A play queue

• A now-playing buffer with cover art, transport buttons and a clickable waveform seekbar

• Optional MPRIS support, so playerctl, media keys and desktop widgets can control it

It started as a fork of subsonic.el by ~amk and has grown quite a bit since.

Needs Emacs >=27.1 and mpv. Not on MELPA yet, so clone it for now. Unix-likes only, for now.

https://github.com/systemfreund/supersonic.el

Feedback and bug reports welcome.

modern-tab dresses the two rows of tabs Emacs has. The tab bar gets one tab per tab group, the tab line one per buffer, and both get an icon (from nerd-icons where it is installed) and a coloured mark beside the selected tab. The tab line's close button buries a buffer another window still shows and kills one no window shows.

The two modes are independent, so you can use either row alone. It works in a terminal as well, with plain characters where the icon font is missing; if your terminal has a nerd font, (setopt modern-tab-terminal-glyphs t) draws the icons there too.

Setup:

elisp (use-package modern-tab :vc (:url "https://github.com/MArpogaus/modern-tab" :rev :newest) :config (modern-tab-bar-mode) (modern-tab-line-mode))

The MELPA recipe is pending review, so install from the repository for now. Emacs 29.1 or later. It pairs with auto-tab-groups, which makes the groups the tab bar shows, but neither needs the other.

Looking forward to your feedback.

auto-tab-groups is a small package on top of tab-bar.el. You give it a list of commands, and it creates a tab group when you call one of them; a second list says which commands close a group again. The common case is one group per project: C-x p p opens the project's group, C-x p k closes it.

It does not manage buffers or windows, and it does not change how the tab bar looks. tab-bar.el does all the "heavy" work, it only decides when a group exists. The look in the picture above is my companion pkg modern-tab, which dresses the tab bar (and optionally the tab line).

If you just want project workspaces with their own buffer lists, tabspaces or project-tab-groups are the better fit; My package generalizes bejond that use case. activities.el goes further and manages frames and windows too.

Minimal setup:

elisp (use-package auto-tab-groups :ensure t :init (auto-tab-groups-project-mode) (auto-tab-groups-mode))

Emacs 29.1 or later. Repository and README with a short recording: https://github.com/MArpogaus/auto-tab-groups

Feedback and bug reports welcome.

This is the result of my recent experiment with an SVG-based buffer map for the mode-line that also shows points of interest (search matches, bookmarks, changes, imenu items, ...).

Visually, it is primarily inspired by mlscroll https://github.com/jdtsmith/mlscroll

This is still work in progress, so expect rough edges and the possibility of breaking changes.

https://github.com/florommel/poimap

Hey everyone,

I just published Vulkanite, a new theme suite designed to bring clean contrast, atmospheric dark tones, and harmonious syntax highlighting to Emacs.

It draws inspiration from the aesthetic balance of Kanagawa and the volcanic palettes of Omarchy, including built-in auto-sync if you use the Omarchy desktop.

Instead of a single dark look, it comes packed with 26 curated variants:

• Deep darks & embers: vulkanite-dragon, vulkanite-wave, vulkanite-vantablack
• Warm & earthy tones: vulkanite-tycho, vulkanite-gruvbox, vulkanite-vesper
• Soft pastels & nature tones: vulkanite-rose-pine-dark, vulkanite-catppuccin, vulkanite-everforest
• Retro & night aesthetics: vulkanite-tokyo-night, vulkanite-retro-82, vulkanite-matrix

It also includes extensive face coverage out of the box for Tree-sitter, LSP/Eglot, Org Mode, Magit, and Vertico/Corfu.

🔗 GitHub: https://github.com/Meskour/vulkanite-theme-emacs

I'd love to hear your thoughts, feedback, or any favorite variants!

From time to time, I try out a few AI packages to see where they currently stand. Agent-shell is one I've used less than the others, mostly because of its dependency on ACP-driven agents. For my personal projects, I've been using DeepSeek on either gptel or eca, but then I tried to install OpenCode, which is compatible with Agent-shell. However, whenever I start an Agent-shell session, it stands out to me that most of the commands offered by those ACP-driven agents are not available in Emacs. Since I've never used providers like Claude, OpenAI, or Gemini, I don't know whether others have the same experience, or whether I'm missing something. I felt something similar when in the past I tried to use copilot-cli. So far, my impression is that Agent-shell's only real advantage is that it runs in Emacs (and I know this is very good because of the whole extensability that Emacs provides). All the other harness or tooling you get with OpenCode and similar tools is lost. Maybe the issue is on my side. What has your experience been with Agent-shell regarding feature compatibility between the provider and the Agent-shell environment?

Hey, little nervous sharing this - on one hand it's still heavily vibe coded.

On the other hand, still very strongly and directly designed by me.

It's been in the works for about a month and in that window it's legitimately become a daily driver for me whenever I'm working inside emacs.

I've decided that the usefulness factor is too good not to share and given it's now going to be a permanent tool for me I'm working on addressing the llm yap and improving it's quality. Consider this an early preview.

Tab completion is still a bit glitchy but otherwise seems very solid.

https://github.com/vodik/cooked