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.

emacs-solo-eldoc-box

Eldoc documentation in a child frame. Shows eldoc documentation in a floating child frame near point instead of the echo area. A reimplementation of the eldoc-box package.

emacs-solo-khard

Khard contacts browser. Browse and search your khard address book from inside Emacs. Niche, but if you use khard for contact management, this is handy.

emacs-solo-flymake-eslint

Flymake backend for ESLint. Runs ESLint as a Flymake checker for JavaScript/TypeScript files. Disabled by default now that LSP servers handle ESLint natively, but still available if you prefer the standalone approach.

emacs-solo-erc-image

Inline images in ERC chat buffers. When someone posts an image URL in IRC, this fetches and displays the image inline in the ERC buffer. A small luxury that makes IRC feel more modern.

emacs-solo-yt

YouTube search and playback with yt-dlp and mpv. Search YouTube from Emacs, browse results, and play videos (or just audio) through mpv. Because sometimes you need background music and YouTube is right there.

emacs-solo-gh

GitHub CLI interface with transient menu. A transient-based menu for the gh CLI tool. Browse issues, pull requests, run actions, all from a structured Emacs interface without memorizing gh subcommands.

Emacs 31: Looking Forward

Throughout the config you'll see comments tagged ; EMACS-31 marking features that are coming (or already available on the development branch). Some highlights:

— Window layout commands: window-layout-transpose, window-layout-rotate-clockwise, and flip commands. Finally, first-class support for rearranging window layouts

— Tree-sitter grammar sources defined in modes: No more manually specifying treesit-language-source-alist entries for every language

— markdown-ts-mode: Tree-sitter powered Markdown, built-in

— Icomplete improvements: In-buffer adjustment, prefix indicators, and better vertical rendering

— Speedbar in-frame: speedbar-window lets the speedbar live inside your frame as a normal window

— VC enhancements: vc-dir-hide-up-to-date-on-revert, vc-auto-revert-mode, vc-allow-rewriting-published-history

— ERC fixes: The scrolltobottom/fill-wrap dependency is finally resolved

— native-comp-async-on-battery-power: Don't waste battery on native compilation

— kill-region-dwim: Smart kill-region behavior

— delete-pair-push-mark: Better delete-pair with mark pushing

— World clock sorting: world-clock-sort-order for sensible timezone display

I tag these not just for my own reference, but so that anyone reading the config can see exactly which parts will become cleaner or unnecessary as Emacs 31 stabilizes. Some of the polyfill code I carry today, particularly around icomplete, exists specifically because those features haven't landed in a stable release yet.

What I've Learned

This latest cycle of working on Emacs Solo taught me a few things worth sharing.

Emacs gives you more than you think. Every time I set out to "reimplement" something, I discovered that Emacs already had 70% of it built in. vc is far more capable than most people realize. icomplete-vertical-mode is genuinely good. tab-bar-mode is a real workspace manager. proced is a real process manager. The gap between "built-in Emacs" and "Emacs with 50 packages" is smaller than the community often assumes.

Writing your own packages is the best way to learn Elisp. I learned more about Emacs Lisp writing emacs-solo-gutter and emacs-solo-container than I did in years of tweaking other people's configs. When you have to implement something from scratch, you're forced to understand overlays, process filters, tabulated-list-mode, transient, child frames, and all the machinery that packages usually hide from you.

Small is beautiful. Most of the modules in lisp/ are under 200 lines. Some are under 50. They don't try to handle every edge case. They handle my edge cases, and that's enough. If someone else needs something different, the code is simple enough to fork and modify.

Contributing upstream is worth it. Some of the things I built as workarounds (like the icomplete vertical prefix indicators) turned into upstream patches. When you're deep enough in a feature to build a workaround, you're deep enough to propose a fix.

Conclusion

Emacs Solo started as a personal challenge: can I have a productive, modern Emacs setup without installing a single external package?

The answer, after this cycle, is a definitive yes.

Is it for everyone? Absolutely not. If you're happy with Doom Emacs or Spacemacs or your own carefully curated package list, that's great. Those are excellent choices.

But if you're curious about what Emacs can do on its own, if you want a config where you understand every line, if you want something you can hand to someone and say "just drop this into ~/.emacs.d/ and it works", then maybe Emacs Solo is worth a look.

The repository is here: https://github.com/LionyxML/emacs-solo

It's been a lot of fun. I learned more in this cycle than in any previous one. And if anyone out there finds even a single module or config snippet useful, I'd be happy.

That's the whole point, really. Sharing what works.

Acknowledgements

None of this exists in a vacuum, and I want to give proper thanks.

First and foremost, to the Emacs core team. The people who maintain and develop GNU Emacs are doing extraordinary work, often quietly, often thanklessly. Every built-in feature I configure in init.el is the result of decades of careful engineering. The fact that Emacs 31 keeps making things better in ways that matter (tree-sitter integration, icomplete improvements, VC enhancements, window layout commands) is a testament to how alive this project is.

While working on Emacs Solo I also had the opportunity to contribute directly to Emacs itself. I originally wrote markdown-ts-mode, which was later improved and integrated with the help and review of Emacs maintainers. I also contributed changes such as aligning icomplete candidates with point in the buffer (similar to Corfu or Company) and a few fixes to newsticker.

I'm very grateful for the help, reviews, patience, and guidance from people like Eli Zaretskii, Yuan Fu, Stéphane Marks, João Távora, and others on the mailing lists.

To the authors of every package that inspired a module in lisp/. Even though Emacs Solo doesn't install external packages, it is deeply influenced by them. diff-hl, ace-window, olivetti, doom-modeline, exec-path-from-shell, eldoc-box, rainbow-delimiters, sudo-edit, and many others showed me what was possible and set the bar for what a good Emacs experience looks like. Where specific credit is due, it's noted in the source code itself.

A special thanks to David Wilson (daviwil) and the System Crafters community. David's streams and videos were foundational for me in understanding how to build an Emacs config from scratch, and the System Crafters community has been an incredibly welcoming and knowledgeable group of people. The "Crafters" theme variant in Emacs Solo exists as a direct nod to that influence.

To Protesilaos Stavrou (Prot), whose work on Modus themes, Denote, and his thoughtful writing about Emacs philosophy has shaped how I think about software defaults, accessibility, and keeping things simple. The fact that Emacs Solo's themes are built on top of Modus is no coincidence.

And to Gopar (goparism), whose Emacs content and enthusiasm for exploring Emacs from the ground up resonated deeply with the spirit of this project. It's encouraging to see others who believe in understanding the tools we use.

To everyone who I probably forgot to mention, who has opened issues, suggested features, or just tried Emacs Solo and told me about it: thank you. Open source is a conversation, and every bit of feedback makes the project better.

There's a feature in Emacs that I've always loved: vc-git-region-history. You select a range of lines, call the command, and Emacs shows you how those exact lines evolved through git commits.

When I'm working in Neovim, I genuinely miss this. There are great git plugins out there, sure, but none of them gave me exactly this: select lines, see their history, navigate commits. And that's it. No extras. No repeated features I already have provided by other plugins and sometimes even fight between them.

The mini.nvim philosophy

Before I talk about what I built, I want to mention something that deeply influenced the approach: mini.nvim.

If you haven't seen it, mini.nvim is a collection of small, independent Neovim modules. Each one does one thing, and does it well. You don't have to install the whole collection, you can pick exactly the functionality you need.

This resonates with me. I don't want to install a massive git suite just to get one feature. I don't want a plugin that tries to be everything for everyone. I want a small, focused tool that does its job and gets out of the way.

That's the spirit behind what I made.

gitlineage.nvim

gitlineage.nvim: a small Neovim plugin that lets you view git history for selected lines.

What follows is largely based on the project's README.md. Since things may change over time, check the repository for the latest information.

How it Works

1. Select a range of lines in visual mode.

   

2. Press <leader>gl (all bindings are customizable). A new split window opens with the git history of the selected lines.

   

3. Advance through commits with ]c.

   

4. Quickly yank the commit SHA with yc.

   

5. Go back to previous commits with [c.

   

6. If diffview.nvim is installed, open the full commit diff by hitting <CR> on a commit line.

   

Requirements

Before install it, check the requirements:

Required:

• Neovim >= 0.7.0
• Git

Optional:

• diffview.nvim - for viewing full commit diffs

Installation

You can clone the repository and load everything manually, but it is highly recommended to use a plugin manager.

lazy.nvim

{
    "lionyxml/gitlineage.nvim",
    dependencies = {
        "sindrets/diffview.nvim", -- optional, for open_diff feature
    },
    config = function()
        require("gitlineage").setup()
    end
}

mini.deps

Using mini.deps:

local add = require("mini.deps").add

add("sindrets/diffview.nvim") -- optional, for open_diff feature
add("lionyxml/gitlineage.nvim")

require("gitlineage").setup()

vim.pack.add() (Neovim >= 0.12)

Using native vim.pack.add():

vim.pack.add({
    "https://github.com/sindrets/diffview.nvim", -- optional, for open_diff feature
    "https://github.com/lionyxml/gitlineage.nvim",
})

require("gitlineage").setup()

vim-plug

call plug#begin()

Plug 'lionyxml/gitlineage.nvim'
Plug 'sindrets/diffview.nvim' " optional, for open_diff feature

call plug#end()

lua require("gitlineage").setup()

Configuration

require("gitlineage").setup({
    split = "auto",       -- "vertical", "horizontal", or "auto"
    keymap = "<leader>gl", -- set to nil to disable default keymap
    keys = {
        close = "q",       -- set to nil to disable
        next_commit = "]c", -- set to nil to disable
        prev_commit = "[c", -- set to nil to disable
        yank_commit = "yc", -- set to nil to disable
        open_diff = "<CR>", -- set to nil to disable (requires diffview.nvim)
    },
})

| Option             | Default      | Description                                                                                  |
| ------------------ | ------------ | -------------------------------------------------------------------------------------------- |
| `split`            | `auto`       | How to open the history buffer. `auto` picks vertical for wide windows, horizontal for tall. |
| `keymap`           | `<leader>gl` | Visual mode keymap. Set to `nil` to define your own.                                         |
| `keys.close`       | `q`          | Close the history buffer.                                                                    |
| `keys.next_commit` | `]c`         | Jump to next commit.                                                                         |
| `keys.prev_commit` | `[c`         | Jump to previous commit.                                                                     |
| `keys.yank_commit` | `yc`         | Yank commit SHA when on a commit line.                                                       |
| `keys.open_diff`   | `<CR>`       | Open full commit diff (requires diffview.nvim).                                              |

Custom keymaps

require("gitlineage").setup({
    keymap = "<leader>gh",
    keys = {
        close = "<Esc>",
        next_commit = "<C-n>",
        prev_commit = "<C-p>",
        yank_commit = "y",
        open_diff = "d",
    },
})

Usage

1. Enter visual mode (v, V, or <C-v>)
2. Select the lines you want to inspect
3. Press <leader>gl (or your configured keymap)
4. A split window opens with the git history
5. Navigate using buffer keymaps:

| Key    | Action                                         |
| ------ | ---------------------------------------------- |
| `q`    | Close the history buffer                       |
| `]c`   | Jump to next commit                            |
| `[c`   | Jump to previous commit                        |
| `yc`   | Yank commit SHA (on commit line)               |
| `<CR>` | Open full commit diff (requires diffview.nvim) |

Health check

Verify your setup:

:checkhealth gitlineage

This checks:

➖ Neovim version

➖ Git availability

➖ Git repository status

➖ diffview.nvim availability (optional)

➖ Plugin configuration

Conclusion

If you're someone who moves between Emacs and Neovim, or if you've ever wanted a focused, minimal way to inspect line-level git history without installing a full git suite, give https://github.com/LionyxML/gitlineage.nvim a try.

It's small, it does one thing, and it stays out of your way. Just like a good plugin should.

I'll start by admitting something upfront: for a long time, I was very vocal about not recommending Eglot if you were working with a modern web development stack, especially things like React, TypeScript, ESLint, Tailwind, Vue, etc. I even said so publicly in GitHub issues and discussions.

That said, I always liked Eglot.

More than liked, actually. Eglot always felt closer to Emacs itself. So much so that it eventually became part of Emacs core. Its design philosophy: minimalistic, protocol-driven, no magic UI layers is very close to my way to tackle Emacs. In contrast, lsp-mode + lsp-ui behaves much more like a full-blown IDE, and yes, nothing wrong with that approach, you can use lsp-mode without the lsp-ui package, but you know, if I could, I'd rather stay within Emacs provided capabilities.

The real problem for me was simple: I couldn't use all the LSP servers I needed at the same time.

And in modern web development with Eglot, that's not optional anymore 😄.

Intro

It's been a few years now since LSP servers started absorbing responsibilities that once belonged exclusively to linters.

Linting today is faster, more precise, and far more interactive. Diagnostics, quick fixes, refactors, formatting, and even architectural hints are now part of the LSP ecosystem. Servers can recommend actions, explain problems, and react to changes in real time.

Because of that, there's less and less reason to:

• wrap a linter's API into a Flymake backend

• parse CLI output while developing

• reinvent glue code for every tool

The LSP protocol is well documented, standardized, and, at least in theory, every server speaks the same "language".

As time went on, something else became clear: some linters stopped being maintained as standalone tools, while new ones started life as LSP servers first. In some ecosystems, the only supported interface is LSP.

This imposed a brick wall for Eglot usage.

Eglot supports one server per buffer. That was fine when "one server did everything". But today, we often want:

• a language server for semantics and completion

• a linter server for diagnostics and code actions

• a (or some) framework-specific server(s) (Tailwind, Vue, Angular, etc.)

Solutions

For a long time, João (Eglot's maintainer) collected feedback around this limitation. Multiple issues, discussions, and experiments circled around the same idea:

"How do we support multiple LSP servers per buffer without turning Eglot into something it isn't?"

One important constraint was clear: Eglot itself should not be overhauled to manage multiple servers internally.

The proposed solution was elegant: an external multiplexer, a tool that looks like one LSP server to the client, but actually talks to many servers behind the scenes, merging and routing messages appropriately.

I'll admit that having designed hardware-level mux/demuxes in the past made me like this "software" idea.

One implementation which came from these discussions is lspx. I tested it before, and while promising, it wasn't quite mature enough for my daily workflow at the time.

So João did what he had been suggesting for some time.

He stepped in and built it himself.

What is Rassumfrassum

rassumfrassum is an LSP multiplexer, you can check its repository here: https://github.com/joaotavora/rassumfrassum/

From the client's perspective (Eglot, Neovim, anything), it behaves like a single stdio LSP server. Internally, it spawns and manages multiple real LSP servers, routing requests and merging responses.

You start it like this:

rass -- server-a [params-a] -- server-b [params-b] -- server-c [params-c]

Or, using presets, like:

rass python

Behind the scenes, Rassumfrassum:

• forwards requests to all relevant servers

• aggregates diagnostics

• merges code actions and completions

• handles timing, delays, and late responses

• optionally streams diagnostics incrementally

All of this is implemented in Python, with a clear separation between:

• JSON-RPC plumbing

• LSP semantics

• server-specific logic

This is also where Rassumfrassum introduces a non-standard but optional streaming diagnostics extension, which allows multiple diagnostic sources to coexist without stomping on each other.

See it in action from João's screencapture:

Bringing it to my React Web Dev workflow

My day job often involves a lot of React web development, from different repo sizes and ages, and this is where Rassumfrassum becomes a killer feature for me.

Let's take an example, a typical modern React stack needs, at minimum (as suggested by NextJS framework I'll present in a example below):

• typescript-language-server (types, navigation, refactors)

• ESLint (diagnostics, fixes)

• tailwindcss-language-server (class completion, validation)

Before this, with Eglot, you had to choose one.

To properly test this, I created a minimal but realistic example repository you can clone:

# **demo_react_ts_eslint_tailwind_app_for_lsp_debug**
git clone https://github.com/LionyxML/demo_react_ts_eslint_tailwind_app_for_lsp_debug

It's basically this so-called "default" modern React setup: TypeScript, ESLint, Tailwind.

To make this post not too long, I'm assuming the reader knows about npm, pnpm and other tools related to the javascript world.

Basically you need to clone the repo and install the app with:

pnpm install

And make sure you have the needed LSP servers installed, I did it with:

pnpm install -g typescript-language-server typescript @tailwindcss/language-server eslint-lsp

Note: Yep, I know about vscode-eslint-language-server being newer, but still I had problems with it, eslint-lsp worked, and I'm happy.

After fixing a broken Tailwind server installation on my side (user error 😄), this setup worked flawlessly with:

rass -- typescript-language-server --stdio \
	 -- eslint-lsp --stdio \
	 -- tailwindcss-language-server --stdio

You don't need to run this in your terminal, instead, visit your project file and fire up Eglot using:

C-u M-x eglot RET
rass -- typescript-language-server --stdio -- eslint-lsp --stdio -- tailwindcss-language-server --stdio RET

This project README provides you with directions on what is expected from each LSP server to "see". The only relevant file is app/page.tsx.

Well, I did all that and suddenly, everything was there:

• Flymake buffer listing diagnostics from all servers

• Code completion from both TypeScript and Tailwind

• Code actions

Fast, responsive, and clean. Here are some other screenshots:

• the example React code with Flymake marking diagnostics on margin and in-buffer:

• Flymake buffer showing messages from typescript, eslint and tailwind:

• Eldoc showing typescript + eslint warnings while also providing type description:

• Typescript completion:

• Tailwind completion:

• Code actions:

It feels fast. It feels correct. And most importantly: it feels like Emacs, not an IDE pretending to be Emacs.

And of course, if everything works for you when firing up Eglot manually, you can add something like this to your config:

(with-eval-after-load 'eglot
  (add-to-list
   'eglot-server-programs
   '((tsx-ts-mode typescript-ts-mode)
	 . ("rass"
		"--"
		"typescript-language-server" "--stdio"
		"--"
		"eslint-lsp" "--stdio"
		"--"
		"tailwindcss-language-server" "--stdio"))))

A small debugging tip: you can check eglot connections with M-x eglot-list-connections RET and be sure it is running your custom invocation command.

Conclusion

I want to sincerely thank João Távora for his continuous work for the Emacs community over the years.

Rassumfrassum solves a long-standing, real-world problem in a way that respects both:

• the LSP ecosystem

• Eglot's design philosophy

This is still a young project, and there will be bugs. That's expected. But the foundation is solid, the approach is elegant, and the impact is huge.

If you were, like me, holding back on Eglot for modern web development this changes everything.

Please try it, report issues, and support the project. This is not just a win for Eglot, it's a win for the entire LSP ecosystem.

One of the things that never stops fascinating me about Emacs is how deep the rabbit hole goes when your start exploring... well... anything!

You come for a text editor.

You stay because it quietly turns into a laboratory and eventually the custom interface for your entire computer experience.

Most people associate emojis with mobile keyboards, chat apps, or graphical pickers. Emacs takes a completely different approach: Unicode as a first-class citizen. And at the center of this philosophy lives a deceptively simple prefix C-x 8.

Altough not obligatory, In order to explore this feature, try enabling which-key with M-x which-key-mode RET, then issue C-x 8 and wait for the options.

If you've ever wondered how to compose, combine, and bend Unicode inside Emacs, this post is for you.

C-x 8

In Emacs, C-x 8 is the entry point to character composition.

It allows you to:

→ Insert Unicode characters by name

→ Compose accented characters manually

→ Combine multiple code points into a single visible glyph

→ Create emoji sequences using Zero Width Joiners

→ Abuse combining characters in ways that would scare typography purists

This is not about convenience, this is about control.

Inserting Unicode by Name

The most straightforward usage is:

C-x 8 RET

This prompts you for a Unicode character name.

Try typing:

LATIN SMALL LETTER A WITH ACUTE

→ á

Or:

GREEK SMALL LETTER LAMBDA

→ λ

Tip: If you have something like vertico-mode or icomplete-vertical-mode turned ON, you get a preview of your search.

You can also type the code directly, even if Emacs doesn't show it as a preview, like:

274C

Returns:

→ ❌

Composing Accents Manually (Base + Combining Marks)

Unicode doesn’t require precomposed characters like á or ç. Instead, it allows you to build them from base characters + combining marks.

This is where Emacs shines again:

Using M-x compose-region.

Start by tiping a and ' for example, you'll get:

a´

Mark the region (select) with both chars then and use M-x compose-region RET do get:

á

And even more layered:

c¸´

Becomes:

ḉ

These are not “single characters” in the traditional sense.

They are Unicode sequences rendered as one glyph.

If you try to delete from right to left, you'll get it decomposing, like:

ḉ
ç
c

Note: After I first published this post, Eli Zaretskii (Emacs maintainer) was kind enough to share his critique of this approach. Here are his remarks (original here):

The section about composing accents is, in my opinion,
misguided.  Emacs already handles this automatically by
default, without any need to invoke `compose-region`.

The reason the command appeared necessary in the earlier
example is that it used the wrong characters. It should have
used **COMBINING CEDILLA** and **COMBINING ACUTE ACCENT**
instead — which is exactly what the following section does.

I recommend staying away from `compose-region` in Emacs. It
does not fully support all display features and options
(such as bidirectional display), and it may cause problems
in certain corner cases.

Combining Characters

Let’s take a simple letter:

Z

Now, using C-x 8 RET, start adding combining marks:

COMBINING OGONEK
COMBINING TILDE
COMBINING DOT BELOW
COMBINING CEDILLA

→ …repeat as many times as your conscience allows

Result:

→ Ẓ̨̧̧̧̧̧̧̧̧̧̧̧̃

This is valid Unicode.

It may render differently depending on font and platform, but Emacs treats it as a perfectly legitimate text sequence. If you're not inside Emacs, try copying it into some buffer and/or change fonts.

At this point, hopefully you can see how text stops being "letters" and starts being stacked metadata.

Variation Selector-16 (U+FE0F): Forcing Emoji Presentation

Not every emoji-looking thing starts as an emoji.

Many Unicode characters exist in a neutral or text presentation form.

Whether they render as plain text or as colorful emoji depends on an invisible hint called a Variation Selector.

The most important one is:

VARIATION SELECTOR-16 (U+FE0F)

In Emacs:

C-x 8 RET VARIATION SELECTOR-16

VS16 explicitly tells the renderer:

"Treat the previous character as an emoji, not as text."

Let's start with this example:

❤   (HEAVY BLACK HEART)

Adding VARIATION SELECTOR-16, we get:

→ ❤️ (HEAVY BLACK HEART + VARIATION SELECTOR-16)

Same base character. Different semantic intent.

VS16 doesn’t draw anything. It changes meaning.

Another example, insert the digit:

1

That’s just ASCII text.

Now add:

COMBINING ENCLOSING KEYCAP

Result:

→ 1⃣

This might look like a keycap, or it might look broken. It depends on your font. That’s because we didn’t force emoji presentation.

Now do it properly:

Sequence:

1
VARIATION SELECTOR-16
COMBINING ENCLOSING KEYCAP

Result:

→ 1️⃣

Important note: that is not one character.

It’s a sequence of three code points:

→ 1 (DIGIT ONE)

→ U+FE0F (VARIATION SELECTOR-16)

→ U+20E3 (COMBINING ENCLOSING KEYCAP)

Without VS16, renderers are free to choose a text glyph. With VS16, you get the emoji version, consistently.

Zero Width Joiner (U+200D): Emoji Glue

If combining marks alter a single character by adding overlays, the Zero Width Joiner (ZWJ) works at the sequence level, telling the renderer to treat multiple characters as one visual unit — most notably in emoji composition.

Unicode code point:

U+200D

In Emacs:

C-x 8 RET ZERO WIDTH JOINER

ZWJ tells the renderer:

"These characters should be treated as a single semantic unit."

Here's an example:

❤  HEAVY BLACK HEART
❤️  HEAVY BLACK HEART + VARIATION SELECTOR 16
❤️‍🔥  HEAVY BLACK HEART + VARIATION SELECTOR 16 + ZERO WIDTH JOINER + FIRE

The "flaming heart" is not a single character. It’s a sequence:

• ❤️
• ZWJ
• 🔥

Another example is creating "Families" from "Individuals":

This emoji:

👨‍👩‍👦

Actually is the combination of:

• 👨
• ZWJ
• 👩
• ZWJ
• 👦

You can add more members to your "family" and change their appearance, this is only limited by your "font set", meaning some fonts might not render well an specific combination, but many will.

Note: After I first published this post, shipmints suggested that you can also create these sequences via Emacs Lisp (original here), like:

(concat "\N{WOMAN}"
		"\N{ZERO WIDTH JOINER}"
		"\N{HEAVY BLACK HEART}"
		"\N{VARIATION SELECTOR-16}"
		"\N{ZERO WIDTH JOINER}"
		"\N{MAN}"
		" ")

Result:

→ 👩‍❤️‍👨

Inspecting Unicode with C-x = (what-cursor-position)

Typing Unicode is only half the story.

Understanding what you actually typed is the another half.

Lucky us, Emacs users. Just place point over any character and press:

C-x =

You will have a description of the char in your minibuffer, with information like:

→ Character name

→ Unicode code point

→ Script

→ Charset

→ How Emacs internally represents it

This alone is already incredibly useful, but wait! There's more!

Deep Inspection: C-u C-x =

Now add the (universal-argument) prefix:

C-u C-x =

This is where things get serious.

For composed characters and emojis, Emacs will show:

→ The full Unicode sequence

→ Each individual code point

→ Combining characters

→ Zero Width Joiners

→ Text properties and composition details

This is essential when dealing with:

→ Accents built from combining marks

→ ZWJ emoji sequences

→ “Why does this look right but behave wrong?”

→ Copy/paste weirdness across platforms

Some examples:

C-x = on a simple accented character (á)

Char: á (225, #o341, #xe1, file ...) point=7495 of 8976 (83%) column=43

C-u C-x = on a simple accented character (á)

			 position: 7495 of 9102 (82%), column: 43
			character: á (displayed as á) (codepoint 225, #o341, #xe1)
			  charset: unicode (Unicode (ISO10646))
code point in charset: 0xE1
			   script: latin
			   syntax: w	which means: word
			 category: .:Base, L:Strong L2R, c:Chinese, j:Japanese, l:Latin, v:Viet
			 to input: type "C-x 8 RET e1" or "C-x 8 RET LATIN SMALL LETTER A WITH ACUTE"
		  buffer code: #xC3 #xA1
			file code: #xC3 #xA1 (encoded by coding system utf-8-unix)
			  display: by this font (glyph code):
	ftcrhb:-JB-JetBrainsMono Nerd Font-regular-italic-normal-*-14-*-*-*-m-0-iso10646-1 (#xA4)

Character code properties: customize what to show
  name: LATIN SMALL LETTER A WITH ACUTE
  old-name: LATIN SMALL LETTER A ACUTE
  general-category: Ll (Letter, Lowercase)
  decomposition: (97 769) ('a' '́')
...

This can be specially usefull in our emojis, let's try it on ❤️‍🔥:

			 position: 8529 of 10012 (85%), column: 61
			character: ❤ (displayed as ❤) (codepoint 10084, #o23544, #x2764)
			  charset: unicode (Unicode (ISO10646))
code point in charset: 0x2764
			   script: symbol
			   syntax: w	which means: word
			 category: .:Base, 5:symbol
			 to input: type "C-x 8 RET 2764" or "C-x 8 RET HEAVY BLACK HEART"
		  buffer code: #xE2 #x9D #xA4
			file code: #xE2 #x9D #xA4 (encoded by coding system utf-8-unix)
			  display: composed to form "❤️‍🔥" (see below)

Composed with the following character(s) "️‍🔥" using this font:
  ftcrhb:-GOOG-Noto Color Emoji-regular-normal-normal-*-14-*-*-*-m-0-iso10646-1
by these glyphs:
  [0 3 10084 1537 17 0 18 13 4 nil]
with these character(s):
  ️ (#xfe0f) VARIATION SELECTOR-16
  ‍ (#x200d) ZERO WIDTH JOINER
  🔥 (#x1f525) FIRE

Character code properties: customize what to show
  name: HEAVY BLACK HEART
  general-category: So (Symbol, Other)
  decomposition: (10084) ('❤')
 ...

Fonts Matter (A Lot)

One important caveat: fonts decide how far you can go.

Some fonts handle combining characters and emoji sequences beautifully. Others collapse under pressure.

If you see:

→ Misaligned accents

→ Overlapping glyphs

→ Missing emoji components

It’s almost always a font issue, probably not Emacs, not Unicode.

I'd recommend JetBrainsMono Nerd Font or Maple Mono NF. You can find a lot more fonts on nerd fonts site, or use my custom installer script (post, github).

Final Thoughts

Once you internalize C-x 8, unicode and emojis stop being “special”. If you explored it with which-keys as I recommended at the beginning of this post, you probably saw a lot more than C-x 8 RET, emojis even get the special C-x 8 e e sub-menu for convenience.

And I hope once you use C-u C-x =, special characters, block non visible (non printable with your font choice) chars stops being mysterious.

Unicode is a vast and deeply technical subject, but the goal here wasn't theory, it was to show how Emacs turns it into something you can actually use, inspect, and enjoy.

Thanks!

This is likely my final post for 2025, so it feels like a good moment to say thank you.

Thank you to everyone who read these posts, sent feedback, pointed out mistakes, shared them around, or just quietly followed along. This year was especially fun to write: lots of small discoveries, deep dives into Emacs internals, and many "oh wow, it already does that?" moments.

Happy hacking!

Edit

2025-12-28: Added Eli Zaretskii remarks. Added Shipmints code suggestion, typo fix and font recommendations.

In the world of text editing and programming, templating is a superpower. It saves keystrokes, reduces errors, and lets you focus on the bigger picture. For Emacs users, battle-tested packages like yasnippet and tempel are often the go-to solutions, offering powerful features and extensive libraries.

But what if you're in the mood for a little crafting? What if you want a solution that's built right into Emacs, requires no third-party installations, and can be easily copied and pasted into any configuration?

The all mighty built-in abbrev-mode is there for all of us Emacs users! In this post, we'll explore how you can leverage this humble, built-in minor mode to create a powerful, progressive, and deeply personal (for good or bad) snippet system.

What is Abbrev Mode?

At its core, abbrev-mode is a simple expansion system. You define an "abbreviation" (a short string) and an "expansion" (the text it should be replaced with). When the mode is active, it can automatically replace the abbrev with its expansion as you type.

However, I prefer a more deliberate approach. Instead of having abbrevs expand automatically, I like to trigger them manually with the command expand-abbrev, which is bound to C-x '. This gives me full control and avoids unintentional expansions. If you prefer the automatic method, you can always enable it with M-x abbrev-mode.

Level 1: Simple Text Replacements

Let's start with the basics. The simplest use of abbrevs is to replace a short string with a longer one. This is perfect for things you type often, like symbols, emojis, or special characters.

Here is a minimal configuration example (full nicer code on the end of this post):

(use-package abbrev
  :ensure nil
  :custom
  (save-abbrevs nil)
  :config
  (define-abbrev-table 'global-abbrev-table
	'(;; Arrows
	  ("ra" "→")
	  ("la" "←")
	  ("ua" "↑")
	  ("da" "↓")

	  ;; Emojis for context markers
	  ("todo"  "👷 TODO:")
	  ("fixme" "🔥 FIXME:")
	  ("note"  "📎 NOTE:")
	  ("hack"  "👾 HACK:")
	  ("smile"  "😄")
	  ("party" "🎉")
	  ("up"  "☝️")
	  ("applause" "👏")
	  ("manyapplauses" "👏👏👏👏👏👏👏👏")
	  ("heart" "❤️")

	  ;; NerdFonts
	  ("nerdfolder" " ")
	  ("nerdgit" "")
	  ("nerdemacs" ""))))

With these defined, I can type ra and then C-x ' to get a →, or fixme followed by C-x ' to get "🔥 FIXME:". It's simple, fast, and incredibly useful.

Level 2: Running Functions

What if you need more than just static text? What if you want to position the cursor in a specific spot after the expansion? Abbrevs can do that too, by executing an Emacs Lisp function as part of the expansion.

Let's look at a common use case: creating a Markdown code block and placing the cursor inside it.

;; Markdown
("cb" "```@\n\n```"
 (lambda () (search-backward "@") (delete-char 1)))

;; ORG
("ocb" "#+BEGIN_SRC @\n\n#+END_SRC"
 (lambda () (search-backward "@") (delete-char 1)))

When I expand cb, it first inserts the string ˋˋˋ @\n\n\ˋˋˋ . Then, it immediately runs the provided lambda function, which searches backward for the temporary @ marker, deletes it, and leaves the point (the cursor) right where I need it, ready to type. Or mabe we want to do the same for org-mode? No problem, just check ocb.

You could also make variations of these examples by adding your most used language to the template, maybe adding comments, and whathever else you need!

Level 3: The Big Guns - Interactive Templates

Now for the really powerful stuff. Simple text replacement is great, and cursor positioning is even better, but what about true, interactive templates with placeholders? With a simple helper function (check for emacs-solo/abbrev--replace-placeholders on the full code on the bottom of this post), we can make abbrev-mode do just that.

The core of this system is a function that searches for placeholders like ###1###, ###2###, and a special cursor marker ###@###. It prompts you in the minibuffer for the value of each placeholder and, at the end, places the cursor exactly where you told it to.

Here are a few examples that use this function:

;; part of the `global-abbrev-table'
;;
;; JS/TS snippets
("imp" "import { ###1### } from '###2###';"
 emacs-solo/abbrev--replace-placeholders)
("fn" "function ###1### () {\n ###@### ;\n};"
 emacs-solo/abbrev--replace-placeholders)
("clog" "console.log(\">>> LOG:\", {###@### })"
 emacs-solo/abbrev--replace-placeholders)
("cwarn" "console.warn(\">>> WARN:\", {###@### })"
 emacs-solo/abbrev--replace-placeholders)
("cerr" "console.error(\">>> ERR:\", {###@### })"
 emacs-solo/abbrev--replace-placeholders)

When I expand rfc with C-x ', Emacs first asks me for the value of ###1### (the component name). Then it asks for ###2### (the initial content). It replaces the placeholders with my input and creates the full component structure in seconds.

The Complete Configuration

As promised, here is the full use-package declaration that powers this system. You can copy and paste this directly into your Emacs configuration to get started.

(use-package abbrev
  :ensure nil
  :custom
  (save-abbrevs nil)
  :config
  (defun emacs-solo/abbrev--replace-placeholders ()
	"Replace placeholders ###1###, ###2###, ... with minibuffer input.
If ###@### is found, remove it and place point there at the end."
	(let ((cursor-pos nil))
	  (save-excursion
		(goto-char (point-min))
		(let ((loop 0)
			  (values (make-hash-table :test 'equal)))
		  (while (re-search-forward "###\\([0-9]+\\|@\\)###" nil t)
			(setq loop (1+ loop))
			(let* ((index (match-string 1))
				   (start (match-beginning 0))
				   (end (match-end 0)))
			  (cond
			   ((string= index "@")
				(setq cursor-pos start)
				(delete-region start end))
			   (t
				(let* ((key (format "###%s###" index))
					   (val (or (gethash key values)
								(let ((input (read-string (format "Value for %s: " key))))
								  (puthash key input values)
								  input))))
				  (goto-char start)
				  (delete-region start end)
				  (insert val)
				  (goto-char (+ start (length val))))))))))
	  (when cursor-pos
		(goto-char cursor-pos))))

  (define-abbrev-table 'global-abbrev-table
	'(;; Arrows
	  ("ra" "→")
	  ("la" "←")
	  ("ua" "↑")
	  ("da" "↓")

	  ;; Emojis for context markers
	  ("todo"  "👷 TODO:")
	  ("fixme" "🔥 FIXME:")
	  ("note"  "📎 NOTE:")
	  ("hack"  "👾 HACK:")
	  ("pinch"  "🤌")
	  ("smile"  "😄")
	  ("party" "🎉")
	  ("up"  "☝️")
	  ("applause" "👏")
	  ("manyapplauses" "👏👏👏👏👏👏👏👏")
	  ("heart" "❤️")

	  ;; NerdFonts
	  ("nerdfolder" " ")
	  ("nerdgit" "")
	  ("nerdemacs" "")

	  ;; HTML entities
	  ("nb" " ")
	  ("lt" "<")
	  ("gt" ">")

	  ;; Markdown
	  ("cb" "```@\n\n```"
	   (lambda () (search-backward "@") (delete-char 1)))

	  ;; ORG
	  ("ocb" "#+BEGIN_SRC @\n\n#+END_SRC"
	   (lambda () (search-backward "@") (delete-char 1)))
	  ("oheader" "#+TITLE: ###1###\n#+AUTHOR: ###2###\n#+EMAIL: ###3###\n#+OPTIONS: toc:nil\n"
	   emacs-solo/abbrev--replace-placeholders)

	  ;; JS/TS snippets
	  ("imp" "import { ###1### } from '###2###';"
	   emacs-solo/abbrev--replace-placeholders)
	  ("fn" "function ###1### () {\n ###@### ;\n};"
	   emacs-solo/abbrev--replace-placeholders)
	  ("clog" "console.log(\">>> LOG:\", { ###@### })"
	   emacs-solo/abbrev--replace-placeholders)
	  ("cwarn" "console.warn(\">>> WARN:\", { ###@### })"
	   emacs-solo/abbrev--replace-placeholders)
	  ("cerr" "console.error(\">>> ERR:\", { ###@### })"
	   emacs-solo/abbrev--replace-placeholders)
	  ("afn" "async function() {\n  \n}"
	   (lambda () (search-backward "}") (forward-line -1) (end-of-line)))
	  ("ife" "(function() {\n  \n})();"
	   (lambda () (search-backward ")();") (forward-line -1) (end-of-line)))
	  ("esdeps" "// eslint-disable-next-line react-hooks/exhaustive-deps"
	   (lambda () (search-backward ")();") (forward-line -1) (end-of-line)))
	  ("eshooks" "// eslint-disable-next-line react-hooks/rules-of-hooks"
	   (lambda () (search-backward ")();") (forward-line -1) (end-of-line)))

	  ;; React/JSX
	  ("rfc" "const ###1### = () => {\n  return (\n    <div>###2###</div>\n  );\n};"
	   emacs-solo/abbrev--replace-placeholders))))

Conclusion

abbrev-mode may not be the flashiest tool in the Emacs ecosystem, but it has something special: it’s yours to shape. With just a handful of lines of Elisp, you can transform it from a humble text expander into a personal snippet engine that’s fast, predictable, and tailored to the way you think and write.

By starting small, simple replacements and handy symbols and gradually layering in cursor control, minibuffer-driven placeholders, and dynamic templates, you build a system that grows with your workflow. No external dependencies, no syncing snippet collections across machines, no black-box magic. Just pure Emacs, bending to your will.

Whether you stick with this approach or eventually reach for heavier tools like yasnippet or tempel, I hope this post shows that sometimes the most powerful solutions are the ones hiding in plain sight. And with a little crafting, abbrev-mode can become one of the most quietly transformative parts of your everyday editing.

Happy hacking. And happy expanding!

I have a deep appreciation for both the Catppuccin and Modus themes. Having contributed to both projects in the past, I've grown to love their design principles. Catppuccin's popularity and my preference for a consistent theme across all my tools make it a natural choice. However, I also admire the clean, core-focused design of the Modus themes.

This led me to an exciting experiment: what if I could get the best of both worlds? A Catppuccin-Mocha-like theme, but lighter and built on top of the rock-solid foundation of the Modus themes. The result is a highly personalized Emacs setup that feels both familiar and fresh.

Here is the code that makes it all happen:

;;; ┌──────────────────── THEMES
;;; │ Catppuccin Mocha Based Theme (hacked Modus)
;;
;; This tries to follow: https://github.com/catppuccin/catppuccin/blob/main/docs/style-guide.md
;; With the colors from: https://github.com/catppuccin/catppuccin/ (Mocha)
(use-package modus-themes
  :ensure nil
  :defer t
  :custom
  (modus-themes-italic-constructs t)
  (modus-themes-bold-constructs t)
  (modus-themes-mixed-fonts nil)
  (modus-themes-prompts '(bold intense))
  (modus-themes-common-palette-overrides
   `((accent-0 "#89b4fa")
	 (accent-1 "#89dceb")
	 (bg-active bg-main)
	 (bg-added "#364144")
	 (bg-added-refine "#4A5457")
	 (bg-changed "#3e4b6c")
	 (bg-changed-refine "#515D7B")
	 (bg-completion "#45475a")
	 (bg-completion-match-0 "#1e1e2e")
	 (bg-completion-match-1 "#1e1e2e")
	 (bg-completion-match-2 "#1e1e2e")
	 (bg-completion-match-3 "#1e1e2e")
	 (bg-hl-line "#2a2b3d")
	 (bg-hover-secondary "#585b70")
	 (bg-line-number-active unspecified)
	 (bg-line-number-inactive "#1e1e2e")
	 (bg-main "#1e1e2e")
	 (bg-mark-delete "#443245")
	 (bg-mark-select "#3e4b6c")
	 (bg-mode-line-active "#181825")
	 (bg-mode-line-inactive "#181825")
	 (bg-prominent-err "#443245")
	 (bg-prompt unspecified)
	 (bg-prose-block-contents "#313244")
	 (bg-prose-block-delimiter bg-prose-block-contents)
	 (bg-region "#585b70")
	 (bg-removed "#443245")
	 (bg-removed-refine "#574658")
	 (bg-tab-bar      "#1e1e2e")
	 (bg-tab-current  bg-main)
	 (bg-tab-other    "#1e1e2e")
	 (border-mode-line-active nil)
	 (border-mode-line-inactive nil)
	 (builtin "#89b4fa")
	 (comment "#9399b2")
	 (constant  "#f38ba8")
	 (cursor  "#f5e0dc")
	 (date-weekday "#89b4fa")
	 (date-weekend "#fab387")
	 (docstring "#a6adc8")
	 (err     "#f38ba8")
	 (fg-active fg-main)
	 (fg-completion "#cdd6f4")
	 (fg-completion-match-0 "#89b4fa")
	 (fg-completion-match-1 "#f38ba8")
	 (fg-completion-match-2 "#a6e3a1")
	 (fg-completion-match-3 "#fab387")
	 (fg-heading-0 "#f38ba8")
	 (fg-heading-1 "#fab387")
	 (fg-heading-2 "#f9e2af")
	 (fg-heading-3 "#a6e3a1")
	 (fg-heading-4 "#74c7ec")
	 (fg-line-number-active "#b4befe")
	 (fg-line-number-inactive "#7f849c")
	 (fg-link  "#89b4fa")
	 (fg-main "#cdd6f4")
	 (fg-mark-delete "#f38ba8")
	 (fg-mark-select "#89b4fa")
	 (fg-mode-line-active "#bac2de")
	 (fg-mode-line-inactive "#585b70")
	 (fg-prominent-err "#f38ba8")
	 (fg-prompt "#cba6f7")
	 (fg-prose-block-delimiter "#9399b2")
	 (fg-prose-verbatim "#a6e3a1")
	 (fg-region "#cdd6f4")
	 (fnname    "#89b4fa")
	 (fringe "#1e1e2e")
	 (identifier "#cba6f7")
	 (info    "#94e2d5")
	 (keyword   "#cba6f7")
	 (keyword "#cba6f7")
	 (name "#89b4fa")
	 (number "#fab387")
	 (property "#89b4fa")
	 (string "#a6e3a1")
	 (type      "#f9e2af")
	 (variable  "#fab387")
	 (warning "#f9e2af")))
  :config
  (modus-themes-with-colors
	(custom-set-faces
	 `(change-log-acknowledgment ((,c :foreground "#b4befe")))
	 `(change-log-date ((,c :foreground "#a6e3a1")))
	 `(change-log-name ((,c :foreground "#fab387")))
	 `(diff-context ((,c :foreground "#89b4fa")))
	 `(diff-file-header ((,c :foreground "#f5c2e7")))
	 `(diff-header ((,c :foreground "#89b4fa")))
	 `(diff-hunk-header ((,c :foreground "#fab387")))
	 `(gnus-button ((,c :foreground "#8aadf4")))
	 `(gnus-group-mail-3 ((,c :foreground "#8aadf4")))
	 `(gnus-group-mail-3-empty ((,c :foreground "#8aadf4")))
	 `(gnus-header-content ((,c :foreground "#7dc4e4")))
	 `(gnus-header-from ((,c :foreground "#cba6f7")))
	 `(gnus-header-name ((,c :foreground "#a6e3a1")))
	 `(gnus-header-subject ((,c :foreground "#8aadf4")))
	 `(log-view-message ((,c :foreground "#b4befe")))
	 `(match ((,c :background "#3e5768" :foreground "#cdd6f5")))
	 `(modus-themes-search-current ((,c :background "#f38ba8" :foreground "#11111b" ))) ;; :foreground "#cdd6f4" -- Catppuccin default, not that visible...
	 `(modus-themes-search-lazy ((,c :background "#3e5768" :foreground "#cdd6f5")))     ;; :foreground "#cdd6f4" :background "#94e2d5" -- Catppuccin default, not that visible...
	 `(newsticker-extra-face ((,c :foreground "#9399b2" :height 0.8 :slant italic)))
	 `(newsticker-feed-face ((,c :foreground "#f38ba8" :height 1.2 :weight bold)))
	 `(newsticker-treeview-face ((,c :foreground "#cdd6f4")))
	 `(newsticker-treeview-selection-face ((,c :background "#3e5768" :foreground "#cdd6f5")))
	 `(tab-bar ((,c :background "#1e1e2e" :foreground "#bac2de")))
	 `(tab-bar-tab ((,c :background "#1e1e2e" :underline t)))
	 `(tab-bar-tab-group-current ((,c :background "#1e1e2e" :foreground "#bac2de" :underline t)))
	 `(tab-bar-tab-group-inactive ((,c :background "#1e1e2e" :foreground "#9399b2"))))
	 `(tab-bar-tab-inactive ((,c :background "#1e1e2e" :foreground "#a6adc8")))
	 `(vc-dir-file ((,c :foreground "#89b4fa")))
	 `(vc-dir-header-value ((,c :foreground "#b4befe"))))
  :init
  (load-theme 'modus-vivendi t))

With the cost of a few lines of code over the built-in theme, we now have our beloved modus-vivendi theme dressed as a nice catppucin-mocha theme.

How it looks?

Some Emacs Lisp Code:

VC-Diff:

Eshell:

Dired:

Some Typescript:

Gnus Mail:

Newsticker:

Some Help Buffer:

How It Works

The code is a use-package declaration for the modus-themes. Let's break it down:

• :custom: This is where the main customization happens.

  • We enable italic and bold constructs for better readability.

  • The modus-themes-common-palette-overrides is the heart of our theme. It's a list of color overrides that map the Modus theme's color variables to the Catppuccin-Mocha color palette. This is what gives us the Catppuccin look and feel.

• :config: After the theme is loaded, we use modus-themes-with-colors to apply some final, specific face customizations for various packages and UI elements like diff-mode, gnus, and the tab-bar. This allows for fine-tuning the theme.

• :init: Finally, we load the modus-vivendi-tinted theme.

Other Catppuccin Flavors?

Of course, this experiment was limited to the Mocha flavor, but my main goal was to show you how this can be done. Want to try some tokio colors? Want to create your own theme? Use Modus as a foundation for your creative freedom!

Conclusion

This experiment shows that you don’t need to build a theme from scratch to enjoy a familiar aesthetic in Emacs. By reusing the flexibility of the Modus themes, you can adapt them to match your favorite palettes, whether Catppuccin, Tokio, or something entirely your own.

Think of this as a blueprint rather than a finished product: a small example of how powerful Emacs theming can be when you combine solid foundations with your own creative touch.

Edit

2025-12-10: Since the release of this post, Protesilaos, the author of Modus, has started workin on ways for users to derive themes from Modus by using its internal tools. You can check his release post here: Emacs: new Modus themes tool to generate a complete palette.

Hey everyone! Following up on my last post about Web Workers with React, I'm excited to dive into another powerful browser API: Service Workers.

In this guide, we'll explore how Service Workers can make our React applications more resilient and engaging. We'll start with a basic online-only app and progressively enhance it with offline capabilities, background data synchronization, and real push notifications.

The complete source code for each step is available in my GitHub repository.

Part 1: The Problem - The App That Needs a Connection

Let's start with a standard React application. It's a simple app that fetches a random joke from an API and displays it.

// service-workers-demos/01-react-no-sw/src/App.jsx
function App() {
  const [quote, setQuote] = useState("Loading...");

  useEffect(() => {
    fetch("https://official-joke-api.appspot.com/random_joke")
      .then((r) => r.json())
      .then((j) => setQuote(`${j?.setup} - ${j?.punchline}`))
      .catch(() => setQuote("❌ Error fetching quote."));
  }, []);

  return (
    <>
      <h1>App1 - Common React App</h1>
      <div className="card">
        <p>{quote}</p>
      </div>
      <button onClick={() => window.location.reload()}>Reload Page</button>
    </>
  );
}

A quick note: you might notice we're fetching data directly inside useEffect. For this guide, I've simplified some patterns to keep the focus squarely on the Service Worker implementations themselves, avoiding more complex state management or data-fetching abstractions. Now, back to business.

This fetch works perfectly fine... as long as you're online. If you open your browser's DevTools, go to the "Network" tab, and simulate being offline, the app breaks completely upon reload. This is because it can't fetch its own assets or the joke from the API.

Hello dinosaur friend:

Part 2: The Solution - A Manual Service Worker

To solve the offline problem, we introduce a Service Worker. It acts as a proxy between our application and the network, allowing us to cache resources and serve them even when there's no internet connection.

First, we need to register the Service Worker. We do this in our application's entry point.

// service-workers-demos/02-react-sw-manual/src/sw-register.js
export function registerSW() {
  if ("serviceWorker" in navigator) {
    window.addEventListener("load", () => {
      navigator.serviceWorker
        .register("/service-worker.js")
        .then((reg) => console.log(" 🟢 Registered SW:", reg))
        .catch((err) => console.error(" 🔴 Error registering SW:", err));
    });
  }
}

Next, we define the Service Worker's behavior. In the install event, we cache our application's shell, the essential files needed for it to run. In the activate event, we clean up old caches.

// service-workers-demos/02-react-sw-manual/public/service-worker.js
const CACHE_NAME = "app-cache-v1";
const URLS_TO_PRECACHE = ["/", "vite.svg"];

self.addEventListener("install", (event) => {
  console.log("🔧 [SW] install");
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => cache.addAll(URLS_TO_PRECACHE)),
  );
  self.skipWaiting();
});

self.addEventListener("activate", (event) => {
  console.log("🔧 [SW] activate");
  event.waitUntil(
    caches
      .keys()
      .then((names) =>
        Promise.all(
          names.filter((n) => n !== CACHE_NAME).map((n) => caches.delete(n)),
        ),
      ),
  );
  self.clients.claim();
});

❗Important! Be friends with Dev Tools, you'll need them a lot!

With Dev Tools, you can view the Service Worker's status, inspect the cache, and perform manual resets or overrides. When working with Service Workers, you'll often need to manually clear loaded services and caches. Also, when following the examples in this post, make sure to start with a clean cache and no registered workers before testing.

Service Worker DevTools here:

Cache DevTools here:

Now back to business

The real magic happens in the fetch event. Here, we intercept every network request and implement a "cache-first" strategy.

// service-workers-demos/02-react-sw-manual/public/service-worker.js
self.addEventListener("fetch", (event) => {
  const req = event.request;
  event.respondWith(
    caches.match(req).then((cachedResp) => {
      if (cachedResp) return cachedResp; // Return from cache if found
      return fetch(req) // Otherwise, fetch from network
        .then((networkResp) => {
          // If the request is for our own origin, cache the response
          if (
            req.method === "GET" &&
            networkResp &&
            networkResp.status === 200 &&
            req.url.startsWith(self.location.origin)
          ) {
            const copy = networkResp.clone();
            caches.open(CACHE_NAME).then((cache) => cache.put(req, copy));
          }
          return networkResp;
        })
        .catch(() => {
          // If network fails, provide a fallback
          if (req.headers.get("accept").includes("text/html")) {
            return caches.match("/index.html");
          }
        });
    }),
  );
});

With this in place, our app now works offline! The app shell is served from the cache, and while the external API call might fail, the app itself remains functional.

Try changing the network status and then refresh the page:

This should be our new result!

You might notice how everything is served from the Network tab:

Part 3: Going Further with Background Sync and Push

Service Workers unlock more than just offline caching.

Background Sync

What if a user tries to submit a form while offline? With Background Sync, we can defer the action until the connection is restored.

In our app, we register a sync event:

// service-workers-demos/02-react-sw-manual/src/App.jsx
async function scheduleSendData() {
  if ("serviceWorker" in navigator && "SyncManager" in window) {
    const reg = await navigator.serviceWorker.ready;
    try {
      await reg.sync.register("send-form");
      alert("Scheduled sending. Will be executed when back online.");
    } catch (err) {
      alert("Error scheduling: " + err);
    }
  }
}

The Service Worker listens for this event and executes the task when the network is available.

// service-workers-demos/02-react-sw-manual/public/service-worker.js
self.addEventListener("sync", (event) => {
  if (event.tag === "send-form") {
    event.waitUntil(sendPendingData());
  }
});

function sendPendingData() {
  return fetch("/api/save", {
    method: "POST",
    body: JSON.stringify({ msg: "Example data!!!!" }),
    headers: { "Content-Type": "application/json" },
  });
}

Push Notifications

Service Workers can also receive push notifications from a server, even when the app's tab is closed. First, the app must request permission.

// service-workers-demos/02-react-sw-manual/src/App.jsx
function askPermission() {
  if ("Notification" in window) {
    Notification.requestPermission().then((perm) => {
      if (perm === "granted") alert("Notifications permission granted!");
      else alert("Notifications permissions denied.");
    });
  }
}

Then, the Service Worker handles the push event to display the notification.

// service-workers-demos/02-react-sw-manual/public/service-worker.js
self.addEventListener("push", (event) => {
  let title = "Default title";
  let body = "Hello from fake push";

  if (event.data) {
    try {
      const parsed = JSON.parse(event.data.text());
      title = parsed.title || title;
      body = parsed.body || body;
    } catch {
      body = event.data.text();
    }
  }
  const options = { body, icon: "/vite.svg" };
  event.waitUntil(self.registration.showNotification(title, options));
});

You can now simulate a push event from the browser's DevTools:

Note that not only you need permission you grant in your browser, but your OS should also grant permission. This means you might need to mess around giving your browser permission to send notifications before this step works.

This means the showing behaviour is also controlled by your OS, there's no guarantee it will work the same across every browser/OS combination, implement your icons, or even show the full message. This is what I get on macOS in my machine:

Part 4: Simplifying with Workbox

Writing a Service Worker from scratch can be verbose and error-prone. Workbox, a library from Google, simplifies this by providing production-ready strategies for caching and background tasks.

Here's how the fetch logic looks with Workbox:

// service-workers-demos/03-react-sw-workbox/public/sw.js
/* global workbox importScripts */
importScripts(
  "https://storage.googleapis.com/workbox-cdn/releases/6.5.4/workbox-sw.js",
);

// SPA navigation route (NetworkFirst)
workbox.routing.registerRoute(
  ({ request }) => request.mode === "navigate",
  new workbox.strategies.NetworkFirst({ cacheName: "html-shell" }),
);

// Jokes API: StaleWhileRevalidate
workbox.routing.registerRoute(
  ({ url }) => url.origin === "https://official-joke-api.appspot.com",
  new workbox.strategies.StaleWhileRevalidate({ cacheName: "api-jokes-cache" }),
);

// Static assets: StaleWhileRevalidate
workbox.routing.registerRoute(
  ({ request }) => ["style", "script", "worker"].includes(request.destination),
  new workbox.strategies.StaleWhileRevalidate({
    cacheName: "static-resources",
  }),
);

// Background Sync with a plugin
const bgSyncPlugin = new workbox.backgroundSync.BackgroundSyncPlugin(
  "form-queue",
);
workbox.routing.registerRoute(
  ({ url, request }) => request.method === "POST",
  new workbox.strategies.NetworkOnly({ plugins: [bgSyncPlugin] }),
  "POST",
);

Workbox makes the code much more declarative and less boilerplate, while providing robust, battle-tested caching strategies.

Part 5: Real Push Notifications with VAPID

To send real push notifications, our server needs to identify itself to the browser's push service. We use the VAPID protocol for this.

The flow is:

➖ The client requests a PushSubscription and sends it to our server.

➖ The server stores this subscription.

➖ The server uses the web-push library to send a message to the push service, which then delivers it to the correct Service Worker.

Here's the client-side code to subscribe:

// service-workers-demos/04-push-example/client/src/App.jsx
const PUBLIC_VAPID_KEY = "same as server"; // This should be your public VAPID key

async function subscribeUser() {
  const reg = await navigator.serviceWorker.register("/sw-push.js");
  const sub = await reg.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: urlBase64ToUint8Array(PUBLIC_VAPID_KEY),
  });

  // Send subscription to the server
  await fetch("http://localhost:4000/subscribe", {
    method: "POST",
    body: JSON.stringify(sub),
    headers: { "Content-Type": "application/json" },
  });
}

And the Node.js server that sends the push:

// service-workers-demos/04-push-example/server/server.js
const webpush = require("web-push");
// ... configure VAPID keys ...

let subscriptions = [];

app.post("/subscribe", (req, res) => {
  const sub = req.body;
  subscriptions.push(sub);
  res.status(201).json({ ok: true });
});

// Send a push to all subscribers
function sendToAll(payload) {
  subscriptions.forEach((sub) => {
    webpush.sendNotification(sub, JSON.stringify(payload)).catch(console.error);
  });
}

This setup provides a complete end-to-end push notification system.

Conclusion

Service Workers are a cornerstone of modern web development, enabling Progressive Web Apps (PWAs) that are reliable, fast, and engaging. We've seen how they can:

➖ Provide a seamless offline experience by caching resources.

➖ Defer actions until the network is available with Background Sync.

➖ Re-engage users with Push Notifications.

While manual implementation is possible, libraries like Workbox are highly recommended to simplify development and avoid common pitfalls.

A Quick Comparison: Web, Shared, and Service Workers

To recap, here's how the different types of workers compare:

| Feature / Capability            | Web Worker              | Shared Worker                    | Service Worker                               |
| ------------------------------- | ----------------------- | -------------------------------- | -------------------------------------------- |
| Scope                           | Single page/tab         | Shared across tabs (same origin) | Global (site-wide, independent of tabs)      |
| Shared across tabs              | No                      | Yes                              | Yes                                          |
| Communication                   | `postMessage` (1:1)     | `port.postMessage` (many:1)      | `postMessage`, `fetch`, Push API, etc.       |
| Persists after tab closes       | No                      | No                               | Yes (managed by browser)                     |
| Use case                        | Offload CPU-heavy tasks | Coordinate logic across tabs     | Background sync, caching, push notifications |
| DOM access                      | No                      | No                               | No                                           |
| Network interception            | No                      | No                               | Yes (`fetch` interception)                   |
| Requires secure context (HTTPS) | No                      | No                               | Yes (HTTPS required)                         |

I hope this guide has been a helpful introduction to using Service Workers with React! Feel free to explore the code on GitHub and experiment with these powerful features.

When I'm deep into developing a feature, I don't want to think about whether a file is already open in a buffer, or if I need to search the whole project to find it.

I just want to jump straight to the files I'm actively working on, the ones that Git tells me are modified, untracked, or even renamed.

Emacs already gives us great defaults for different contexts:

➡ C-x b (switch-to-buffer) → jump between open buffers.

➡ C-x p b (project-switch-to-buffer) → jump between buffers in the current project.

➡ C-x p f (project-find-file) → find any file inside the project.

Each of these has its value and time. But in the middle of a coding session, when iterating fast on a feature, none of them give me what I want: a list of just the files I've touched.

That's the itch that led me to write this command.

The Function and Binding

(defun emacs-solo/switch-git-status-buffer ()
  "Parse git status from an expanded path and switch to a file.
The completion candidates include the Git status of each file."
  (interactive)
  (require 'vc-git)
  (let ((repo-root (vc-git-root default-directory)))
	(if (not repo-root)
		(message "Not inside a Git repository.")
	  (let* ((expanded-root (expand-file-name repo-root))
			 (command-to-run (format "git -C %s status --porcelain=v1"
									 (shell-quote-argument expanded-root)))
			 (cmd-output (shell-command-to-string command-to-run))
			 (target-files
			  (let (files)
				(dolist (line (split-string cmd-output "\n" t) (nreverse files))
				  (when (> (length line) 3)
					(let ((status (substring line 0 2))
						  (path-info (substring line 3)))
					  ;; Handle rename specially
					  (if (string-match "^R" status)
						  (let* ((paths (split-string path-info " -> " t))
								 (new-path (cadr paths)))
							(when new-path
							  (push (cons (format "R %s" new-path) new-path) files)))
						;; Modified or untracked
						(when (or (string-match "M" status)
								  (string-match "\?\?" status))
						  (push (cons (format "%s %s" status path-info) path-info) files)))))))))
		(if (not target-files)
			(message "No modified or renamed files found.")
		  (let* ((candidates target-files)
				 (selection (completing-read "Switch to buffer (Git modified): "
											 (mapcar #'car candidates) nil t)))
			(when selection
			  (let ((file-path (cdr (assoc selection candidates))))
				(when file-path
				  (find-file (expand-file-name file-path expanded-root)))))))))))

(global-set-key (kbd "C-x C-g") 'emacs-solo/switch-git-status-buffer)

The command parses git status --porcelain=v1, collects the interesting files, and offers them through completing-read. This means it works with whichever completion frontend you already use, and it switches to the selected file's buffer (opening it first if it isn't already open).

Completion in Action

Here's how it looks in different completion UIs:

➡ Plain completion buffer

➡ Fido

➡ Fido vertical

➡ Icomplete vertical

➡ Vertico

No matter which you prefer, you get a filtered list of just the files that matter right now.

Why emacs-solo?

This command is part of my emacs-solo project, a collection of Emacs enhancements that stick to built-in tools and minimal glue code.

The goal is to show how far we can go without depending on a huge package ecosystem, while still making day-to-day workflows smoother.

Conclusion

When I'm developing a feature, I care about the files I've just modified, created, or moved.

This command scratches exactly that itch: fast navigation to Git-relevant files, without worrying if they're open or buried somewhere in the project tree.

Give it a try, and check out emacs-solo for more small, practical commands like this one. 🚀

Edit:

2025-09-04: Fixed the global binding to emacs-solo/switch-git-status-buffer, as pointed by u/jplindstrom on r/emacs (reddit).

When people hear "tabs" in an editor, they usually imagine something like browser tabs in Chrome, Firefox, or even VSCode. But Neovim's tabs are quite different, they are workspaces, each containing its own set of windows and splits. Think of them more like tmux's sessions or Emacs' tab-bar, rather than VSCode's tab-line that just lists files.

By default, Neovim’s tabline shows placeholders like [No Name] or full buffer names, but I find this neither attractive nor particularly useful. I prefer something more minimal, closer to how tmux presents workspaces: numbered slots with just enough styling to highlight the active one. This way, I avoid the distraction of long file names and can stay focused on the workspace itself.

In the screenshot below, at the top left, you can see three tabs: the first has three splits (indicated by the blue “3” along with the filename of the selected split), the second is empty, and the third contains another open file.

In this post, I’ll walk you through how I built a pill-style tabline in Lua, explain some of the design decisions, and show how it fits neatly into my tmux workflow.

Here’s a preview of the final result: three tabs, numbered, formatted, and highlighted for clarity.

Part 1: Why Customize the Tabline?

Here's the situation:

➖ Default Neovim tabs → Show file names and placeholders, often cluttering the screen.

➖ tmux tabs/panes → Show numbered workspaces, clean and efficient.

➖ Emacs → Has two modes: tab-bar (like Neovim's tabs) and tab-line (like VSCode's file tabs).

I wanted my Neovim tabline to look and feel closer to tmux and Emacs' tab-bar. Just numbered "workspaces," styled as pills for clarity.

Here's a preview:

Part 2: Keymaps for Managing Tabs

First, I set up a few keymaps to create, toggle, and navigate tabs:

-- Create a new tab
vim.keymap.set("n", "<leader>tn", ":tabnew<CR>", { desc = "New [t]ab" })

-- Exclude current tab
vim.keymap.set("n", "<leader>tx", ":tabclose<CR>", { desc = "E[x]clude tab" })

-- Toggle showing the tabline
vim.keymap.set("n", "<leader>tt", function()
  if vim.o.showtabline == 2 then
	vim.o.showtabline = 0
  else
	vim.o.showtabline = 2
  end
end, { desc = "Toggle [t]abs" })

-- Navigate tabs
vim.keymap.set("n", "]t", ":tabnext<CR>", { desc = "Next tab", silent = true })
vim.keymap.set("n", "[t", ":tabprevious<CR>", { desc = "Previous tab", silent = true })

This gives me a lightweight tmux-like navigation inside Neovim.

Part 3: Styling with Highlight Groups

I use custom Catppuccin highlight groups to create the "pill" effect (to match my Neovim, terminal, and tmux Catppuccin theme):

vim.api.nvim_set_hl(0, "TabLine", { bg = "NONE", fg = "#666666" })
vim.api.nvim_set_hl(0, "TabLineFill", { bg = "NONE" })

vim.api.nvim_set_hl(0, "TabLinePillActiveLeft",   { fg = "#8aadf4", bg = "#1e1e2e" })
vim.api.nvim_set_hl(0, "TabLinePillActiveText",   { fg = "#1e1e2e", bg = "#8aadf4" })
vim.api.nvim_set_hl(0, "TabLinePillActiveRight",  { fg = "#8aadf4", bg = "#1e1e2e" })

vim.api.nvim_set_hl(0, "TabLinePillInactiveLeft", { fg = "#737994", bg = "#1e1e2e" })
vim.api.nvim_set_hl(0, "TabLinePillInactiveText", { fg = "#1e1e2e", bg = "#737994" })
vim.api.nvim_set_hl(0, "TabLinePillInactiveRight",{ fg = "#737994", bg = "#1e1e2e" })

Each tab is enclosed by decorative glyphs ( on the left and  on the right). Inside, it shows a number, with styling that changes depending on whether the tab is active or inactive.

Note: your terminal font must support these glyphs. The screenshots use JetBrains Mono Nerd Font.

Part 4: The Lua Function for the Tabline

Finally, I define the tabline function:

vim.o.tabline = "%!v:lua.PillTabline()"

function _G.PillTabline()
  local s = ""
  local tabs = vim.api.nvim_list_tabpages()
  local current = vim.api.nvim_get_current_tabpage()

  for i, tab in ipairs(tabs) do
	local is_active = (tab == current)

	local hl_left  = is_active and "%#TabLinePillActiveLeft#"   or "%#TabLinePillInactiveLeft#"
	local hl_text  = is_active and "%#TabLinePillActiveText#"   or "%#TabLinePillInactiveText#"
	local hl_right = is_active and "%#TabLinePillActiveRight#"  or "%#TabLinePillInactiveRight#"

	s = s .. hl_left .. ""
	s = s .. hl_text .. " " .. i .. " "
	s = s .. hl_right .. ""
	s = s .. "%#TabLine# "
  end

  return s
end

Each tab gets a pill-shaped segment, numbered sequentially. No clutter, just a clear workspace indicator.

Part 5: Testing It

For your convinience, here is the full tabline.lua file:

-- Create a new tab
vim.keymap.set("n", "<leader>tn", ":tabnew<CR>", { desc = "New [t]ab" })

-- Exclude current tab
vim.keymap.set("n", "<leader>tx", ":tabclose<CR>", { desc = "E[x]clude tab" })

-- Toggle showing the tabline
vim.keymap.set("n", "<leader>tt", function()
  if vim.o.showtabline == 2 then
	vim.o.showtabline = 0
  else
	vim.o.showtabline = 2
  end
end, { desc = "Toggle [t]abs" })

-- Navigate tabs
vim.keymap.set("n", "]t", ":tabnext<CR>", { desc = "Next tab", silent = true })
vim.keymap.set("n", "[t", ":tabprevious<CR>", { desc = "Previous tab", silent = true })


vim.api.nvim_set_hl(0, "TabLine", { bg = "NONE", fg = "#666666" })
vim.api.nvim_set_hl(0, "TabLineFill", { bg = "NONE" })

vim.api.nvim_set_hl(0, "TabLinePillActiveLeft",   { fg = "#8aadf4", bg = "#1e1e2e" })
vim.api.nvim_set_hl(0, "TabLinePillActiveText",   { fg = "#1e1e2e", bg = "#8aadf4" })
vim.api.nvim_set_hl(0, "TabLinePillActiveRight",  { fg = "#8aadf4", bg = "#1e1e2e" })

vim.api.nvim_set_hl(0, "TabLinePillInactiveLeft", { fg = "#737994", bg = "#1e1e2e" })
vim.api.nvim_set_hl(0, "TabLinePillInactiveText", { fg = "#1e1e2e", bg = "#737994" })
vim.api.nvim_set_hl(0, "TabLinePillInactiveRight",{ fg = "#737994", bg = "#1e1e2e" })


vim.o.tabline = "%!v:lua.PillTabline()"

function _G.PillTabline()
  local s = ""
  local tabs = vim.api.nvim_list_tabpages()
  local current = vim.api.nvim_get_current_tabpage()

  for i, tab in ipairs(tabs) do
	local is_active = (tab == current)

	local hl_left  = is_active and "%#TabLinePillActiveLeft#"   or "%#TabLinePillInactiveLeft#"
	local hl_text  = is_active and "%#TabLinePillActiveText#"   or "%#TabLinePillInactiveText#"
	local hl_right = is_active and "%#TabLinePillActiveRight#"  or "%#TabLinePillInactiveRight#"

	s = s .. hl_left .. ""
	s = s .. hl_text .. " " .. i .. " "
	s = s .. hl_right .. ""
	s = s .. "%#TabLine# "
  end

  return s
end

You can test this file standalone without touching your main config with:

nvim --clean -u NONE -c 'luafile tabline.lua' -c 'tabnew' -c 'tabnew'

This opens Neovim clean, loads your tabline, and creates a couple of tabs so you can see the style right away. \ is the default leader key btw.

Conclusion

I like to think of this as a complement to tmux. tmux manages workspaces across the system, and inside each tmux pane, Neovim provides its own tabbed workspaces. By stripping away file names and fancy descriptions, I keep the focus on structure instead of distractions.

➖ Neovim tabs ≠ browser tabs. They're more like workspaces.

➖ My custom tabline ≈ tmux sessions, but inside Neovim.

➖ The pill design gives enough visual separation without being noisy.

I'll probably refine this over time (maybe adding icons or buffer names when I really need them), but for now this simple approach keeps my Neovim and tmux environments consistent and distraction-free.

Hey everyone! I recently gave a presentation to my team about using Web Workers with React, and the reception was so positive that I decided to turn the content into a blog post.

In this guide, we'll explore how Web Workers can help us keep our React interfaces responsive, even when dealing with heavy computational tasks. We'll go through a practical example, starting with a common problem and evolving to more robust solutions.

The complete source code for each step is available in my GitHub repository.

Part 1: The Problem - The UI That Freezes

Imagine you have a React application that needs to calculate the Fibonacci number for a relatively high value, like 42. The simplest way to implement the Fibonacci function is using recursion:

// src/App.tsx (part-01-heavy-work-lock-ui)
function fib(n: number): number {
  return n <= 1 ? n : fib(n - 1) + fib(n - 2);
}

Now, let's call this function when a button is clicked:

// src/App.tsx (part-01-heavy-work-lock-ui)
const handleClick = () => {
  setResults((results) => [
	...results,
	{ id: idRef.current++, result: fib(42) },
  ]);
};

What happens when we click the button? The user interface (UI) freezes. Buttons stop responding, transitions stutter, and the app feels like it’s crashed. This happens because JavaScript is single-threaded, the long-running Fibonacci calculation blocks the main thread, which also handles user interactions and rendering.

You might notice that the UI is in Portuguese, this demo was originally built for an internal presentation at work. I decided to keep it that way since the interface is simple enough to follow even if you don't speak the language. 😀

Also, if you’re wondering why the rotating icon keeps spinning even when everything else is frozen, that’s a neat detail! CSS animations (like transform: rotate) are handled by the browser’s compositor thread, not JavaScript, so they continue running smoothly even when the main thread is blocked.

Part 2: The Solution - Web Workers to the Rescue

To solve the UI freezing problem, we can move the heavy calculation to a Web Worker. A Web Worker runs JavaScript code in a separate thread, allowing the main thread to remain free to handle user interactions and UI updates.

First, let's create our worker:

// src/workers/fibWorker.ts (part-02-03-heavy-work-with-workers)
self.onmessage = ({ data }) => {
  const result = fib(data.n);
  self.postMessage({ id: data.id, result });
};

function fib(n: number): number {
  return n <= 1 ? n : fib(n - 1) + fib(n - 2);
}

Next, in our React component, we create an instance of the worker and communicate with it:

// src/App.tsx (part-02-03-heavy-work-with-workers)
useEffect(() => {
  workerRef.current = new Worker(
	new URL("./workers/fibWorker.ts", import.meta.url),
	{ type: "module" },
  );

  workerRef.current.onmessage = (e: MessageEvent<Result>) => {
	setResults((prev) => [...prev, e.data]);
  };
}, []);

const handleClick = () => {
  if (workerRef.current) {
	workerRef.current.postMessage({ id: idRef.current++, n: 42 });
  }
};

Now, when we click the button, the Fibonacci calculation runs in the background, and the UI remains responsive.

Part 3: Handling Multiple Tasks

What happens if we click the button multiple times in quick succession? With the current implementation, each click sends a new message to the worker, and it will process all requests concurrently, with no guaranteed order of completion.

If we, for example, change our fibWorker.ts to performe some asynchronous tasks:

// src/workers/fibWorker.ts (part-02-03-heavy-work-with-workers)
function fib(n: number): number {
  return n <= 1 ? n : fib(n - 1) + fib(n - 2);
}

function delay(ms: number) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

self.onmessage = async (e: MessageEvent<{ id: number; n: number }>) => {
  await delay(Math.random() * 2000);

  const result = fib(e.data.n);

  self.postMessage({ id: e.data.id, result });
};

This is the result, showing no "output order" is guaranteed.

Part 4: Controlling the Order with a Queue

To ensure that tasks are executed in the order they were requested, we can implement a queue inside our worker:

// src/workers/fibWorker.ts (part-04-heavy-work-with-workers-queue)
interface Task {
  id: number;
  n: number;
}

const queue: Task[] = [];
let processing = false;

self.onmessage = (e: MessageEvent<Task>) => {
  queue.push(e.data);
  if (!processing) processNext();
};

function processNext() {
  if (queue.length === 0) {
	processing = false;
	return;
  }

  processing = true;
  const task = queue.shift();
  if (task) {
	const result = fib(task.n);
	self.postMessage({ id: task.id, result });
  }

  setTimeout(processNext, 0);
}

With this queue, each task is enqueued and executed one at a time, ensuring order and control over the workflow.

Part 5: Sharing Workers Across Tabs with Shared Workers

What if we want to share the same worker across multiple components or even multiple browser tabs? That's where Shared Workers come in.

A Shared Worker can be accessed by different contexts (tabs, iframes, etc.) from the same origin. This is ideal for centralized tasks, like caching results or managing a WebSocket connection.

Let's create a Shared Worker with a cache for the Fibonacci results:

// src/workers/sharedFibWorker.ts (part-05-heavy-work-shared-workers)
const fibCache = new Map<number, number>();

onconnect = (e: MessageEvent) => {
  const port = e.ports[0];
  port.start();

  port.onmessage = (evt: MessageEvent) => {
	// ... (queue logic)
  };
};

function fib(n: number): number {
  if (fibCache.has(n)) return fibCache.get(n)!;
  const result = rawFib(n);
  fibCache.set(n, result);
  return result;
}

And in our React component, we connect to the Shared Worker:

// src/App.tsx (part-05-heavy-work-shared-workers)
useEffect(() => {
  sharedWorkerRef.current = new SharedWorker(
	new URL("./workers/sharedFibWorker.ts", import.meta.url),
	{ type: "module" },
  );
  sharedWorkerRef.current.port.start();
  sharedWorkerRef.current.port.onmessage = (e: MessageEvent<Result>) => {
	setResults((prev) => [...prev, e.data]);
  };
}, []);

Now, if you open the application in two different tabs and calculate the same Fibonacci number, the second tab will get the result from the cache instantly.

Conclusion

Web Workers are an incredibly powerful tool for improving the performance and responsiveness of web applications. We've seen how:

➖ Web Workers can prevent UI freezing by moving heavy tasks to a separate thread.

➖ A queue can be used to control the execution order of tasks in a worker.

➖ Shared Workers allow for state sharing and communication between different tabs or components.

It's important to remember that Web Workers do not have access to the DOM. Communication with the main thread is done through messages.

For more complex scenarios, you might want to explore libraries like Google's Comlink, which simplifies communication with workers, allowing you to call functions in the worker as if they were local functions.

A Quick Comparison: Web, Shared, and Service Workers

While this guide focused on Web Workers and Shared Workers, it's helpful to understand how they differ from Service Workers. Each has a distinct purpose.

| Feature / Capability            | Web Worker              | Shared Worker                    | Service Worker                               |
| ------------------------------- | ----------------------- | -------------------------------- | -------------------------------------------- |
| Scope                           | Single page/tab         | Shared across tabs (same origin) | Global (site-wide, independent of tabs)      |
| Shared across tabs              | No                      | Yes                              | Yes                                          |
| Communication                   | `postMessage` (1:1)     | `port.postMessage` (many:1)      | `postMessage`, `fetch`, Push API, etc.       |
| Persists after tab closes       | No                      | No                               | Yes (managed by browser)                     |
| Use case                        | Offload CPU-heavy tasks | Coordinate logic across tabs     | Background sync, caching, push notifications |
| DOM access                      | No                      | No                               | No                                           |
| Network interception            | No                      | No                               | Yes (`fetch` interception)                   |
| Requires secure context (HTTPS) | No                      | No                               | Yes (HTTPS required)                         |

Key Observations

➖ Web Workers are the simplest and most common choice. Their goal is to take a specific, computationally intensive task off the main thread to keep a single page responsive. Think of them as temporary helpers for a single view.

➖ Shared Workers are all about coordination. Use them when multiple tabs or windows of your application need to share a single resource, like a WebSocket connection, a shared cache (as in our example), or a centralized state.

➖ Service Workers are fundamentally different. They act as a network proxy for your entire site and are the foundation of Progressive Web Apps (PWAs). While they also run on a separate thread, their primary role is not to perform calculations for a specific page. Instead, they handle tasks that require a longer lifecycle, such as enabling offline functionality by intercepting network requests and serving cached assets, or managing push notifications even when the user doesn't have your site open.

So, while we didn't build a Service Worker today, it's a crucial tool for creating modern, resilient, and engaging web applications. For CPU-bound tasks, stick with Web Workers; for cross-tab communication, use Shared Workers; and for offline capabilities and push notifications, the Service Worker is your go-to.

I hope this guide has been helpful! Feel free to explore the code on GitHub and try it out for yourself.

PS: If you're ready to take the ne step in building resilient web applications, I've written a follow-up post. In Exploring Service Workers with React: From Offline to Push Notifications, we'll go beyond th CPU-bound tasks of Web Workers and dive into the world of offline-first architecture, background sync, and push notifications that only Service Workers can provide.

The 0.3.0 release of Emacs Kick lands today, bringing quiet but quality-of-life improvements while paving the way for future support in Emacs 31.

Gone is the company-mode UI. Enter: corfu, floating tooltips, rich font support, and more predictable behavior. Whether you use Emacs in GUI or terminal, the UX feels tighter, more modern, and (if you're on Emacs 31) frankly beautiful.

Let’s walk through what changed, and why this matters.

✨ What's New in 0.3.0

This release is focused on simplifying and modernizing the core experience—particularly completion and inline documentation.

🧠 Corfu replaces Company

company-mode has served us well, but it’s showing its age. In 0.3.0, it’s replaced with corfu.

This:

➖ Easily supports Nerd Fonts icons on TUI.

➖ Provides info about completion candidate on TUI (Emacs >31).

➖ Feels native and snappy.

➖ Integrates beautifully with cape, vertico, orderless, the modern minibuffer stack.

➖ Plays nice with LSP and non-LSP backends alike.

Corfu stays out of your way until you need it. Completion is now manual by default, triggered via TAB. No more random popups mid-thought.

You can re-enable auto-completion if you prefer, but the default now gives you back control.

💡 Floating Eldoc (with eldoc-box) on Emacs 31

If you're running the bleeding-edge Emacs 31, you now get floating documentation (via child-frame) out of the box using eldoc-box.

That means pressing K (uppercase!) shows a clean, floating doc tooltip right next to your point.

No more jumping to temporary buffers to read type signatures or docstrings. It feels like a native IDE. And if you’re still on Emacs 30? No problem, the fallback is still the eldoc buffer.

✨ Smaller Tweaks That Matter

True to the Emacs spirit, small details make a big difference. This release includes several subtle but impactful visual and behavioral changes:

➖ Company Mode Removed: All company-mode related packages have been fully removed for a cleaner, Corfu-native experience.

➖ Consistent TAB Behavior: TAB is now exclusively for completion, removing the ambiguity where it might trigger indentation instead.

➖ Quicker Dired: <leader> e d now opens dired on current working directory. This complements <leader> e e which opens the side explorer.

➖ Cleaner Diffs: The markers used by diff-hl in the margin have been updated to clearer box-drawing characters (┃, ┆), making it easier to see new, modified, and saved changes.

➖ Iconic Magit: When you have Nerd Fonts enabled, your Magit status buffer now includes file-type icons, giving it a richer, modern feel.

➖ Less Noise: The automatic highlighting of the current line (global-hl-line-mode) is now off by default to reduce visual distraction.

🚀 What This Means for You

Remember this:

Emacs-Kick isn’t a full-fledged distribution
but rather a starting point for building your
own Emacs configuration. It’s designed to be
especially accessible for Vim/Neovim users,
letting you explore the power of Emacs without
committing to its entire ecosystem.

This release doubles down on that. It gets out of your way. It gives you just enough: snappy completions, modern visuals, but no monolithic frameworks.

📦 How to Upgrade

Check install instructions on the official Github Repository: https://github.com/LionyxML/emacs-kick

💬 Final Thoughts

This release makes Emacs Kick feel... well, kick-ass. It’s smoother, quieter, and more intentional. If you value clean defaults, fast completion, and less cognitive noise. You’ll feel the difference.

Let me know what you think, what broke, and what could improve. PRs and issues welcome as always.

Happy hacking! ⚡️

Explore how to turn Emacs' native tab-bar and tab-bar-groups into a powerful, tmux-like window and session management experience—no external packages needed. Organize your workflows with tabs, group them by project or context, and navigate with ease inside your Emacs session, all while keeping tmux nearby for when it still shines.

Here I'm traversing an open session using this concept of organization by simply issuing C-TAB.

If you prefer not to show the group name, want to display buffer names, use other custom decorations, jump right into your group, don’t worry, we’ll explore all these possibilities step by step.

Now, how do we achieve this! 🤩

Motivation

It’s no secret that many Emacs users take advantage of its excellent window management capabilities, like: splitting windows, saving layouts, undoing and redoing them and even use tab-bar as a sort of tmux-like workflow.

What I’m presenting here takes it a step further: bringing in a "split by session" feature, just like tmux UI. In other words, we’re expanding our window management arsenal with:

➖ Tabs, as in Emacs we call it tab-bar (not to be confused with the VSCode-like tab-line mode): which can hold splits of different buffers, either in the same file, different files, terminals, and everything else Emacs can print in a buffer.

➖ Tab Groups, which can hold groups of tabs, mimicking sessions as we call them in tmux, or perspectives if you know this concept from persp-mode or perspective-el, or even activities if you use Doom Emacs.

Also, did I mention we're going to do it without any external package dependencies?

With the provided configuration, we're going to organize our current running Emacs session in "two levels":

The 'tab-bar-groups'

This level holds the tab-group. This might contain a "topic" like "Chat", "Mail" or "News", or simply your project name like "My Project", or if you're working with multiple projects at the same time, one level that might be organized by "Your Workflow". And of course, you can have all of this at the same time, like:

The 'tab-bars'

This level contains your tabs, which can hold all sorts of window arrangements (for the uninitiated, from Emacs's point of view, the OS- level 'window' that holds the Emacs application is called a 'frame', while 'windows' are the inner splits that hold our buffers).

So, first things first. I'm reproducing here the steps to the final form I just showed. But of course, it is all customizable. Want to do another sort of decorations? Want to hide the group name? Want to show filenames? Want to navigate differently? Go for it! It is all transparent to you!

Variables configurations

This is personal taste, take a look at each variable's documentation and tweak it yourself, basically:

➖ I do not want the close button, nor the new button, as I seldom use mouse navigation.

➖ I do want tab-hints, which are numbers on each tab-name for better navigation. I do override the internal function, though, to get it "decorated" my way.

➖ I want a clean separator, so, a single space.

➖ We want the tab-group name shown, hence we add to tab-bar-format the tab-bar-format-tabs-groups option.

All of this can be defined with:

(setq tab-bar-close-button-show nil)
  (setq tab-bar-new-button-show nil)
  (setq tab-bar-tab-hints t)
  (setq tab-bar-auto-width nil)
  (setq tab-bar-separator " ")
  (setq tab-bar-format '(tab-bar-format-tabs-groups
					tab-bar-format-tabs tab-bar-separator
					tab-bar-format-add-tab))

A few (IMHO justified) overrides

Tab bar doesn't allow us many customizations. Fortunately, we can override a couple of functions as they're small and easy to keep up with. Of course, this is totally optional; I'm just trying to mimic a more tmux-like UI feel.

First, tab-bar-tab-name-format-hints: I want to put some arrows around the hints number, and NOT show the buffer name.

(defun tab-bar-tab-name-format-hints (name _tab i)
	  (if tab-bar-tab-hints (concat (format "»%d«" i) "") name))

Second, tab-bar-tab-group-format-default: By default, groups show the hint of the first tab under it. I want a clean group name, so:

(defun tab-bar-tab-group-format-default (tab _i &optional current-p)
	(propertize
	 (concat (funcall tab-bar-tab-group-function tab))
	 'face (if current-p 'tab-bar-tab-group-current 'tab-bar-tab-group-inactive)))

Nice QoL Utility functions

With the above config, we can already do something like C-x t G, setting a group name for your current tab and start organizing your life!

You could also have automatically groups created by setting tab-group in your display-buffer-alist, like:

(add-to-list 'display-buffer-alist
			   '("\\*scratch\\*"
				 (display-buffer-in-tab display-buffer-full-frame)
				 (tab-group . "[EMACS]")))

We're not focusing on automatically tab-grouping stuff in this post though.

Truth is, yes, I want groups for my News, Mail, Chat, but most of my work is done in the form of Projects.

And yes, I want these settings to be manually issued. I can recall the pain of having to sneak-peak another project utility function or doc, just to have my crazy custom persp-mode pulling a new persp and messing with everything.

Function to set tab to group based on project

So, I want a function that can "promote" my current tab to the group [ProjectName], creating it if there are none. Of course, if the current buffer is part of a project. This allows me to switch projects, open new splits, without automagic jumps.

Here we have a function to do so, and a suggested bind:

(defun emacs-solo/tab-group-from-project ()
	"Call `tab-group` with the current project name as the group."
	(interactive)
	(when-let* ((proj (project-current))
				(name (file-name-nondirectory
					   (directory-file-name (project-root proj)))))
	  (tab-group (format "[%s]" name))))

  (global-set-key (kbd "C-x t P") #'emacs-solo/tab-group-from-project)

So, recap: I can C-x t G and "add" my tab to a group, and now I can also simply C-x t P and "add" my tab to the project group.

😎 Workflow?

➖ C-x t p p: starts a new tab selecting a project

➖ Select a file, dired or shell...

➖ C-x t P: add your new tab to the project group, creating it

Want some more tabs?

C-x t 2 will automatically add tabs to your current group.

Isn't it nice? Now, you can feel the power in your hands, you open 10 projects, you create a bunch of groups for your inner Emacs is my OS workflow, how do you traverse all this madness?

Function to jump to group

I found my self abusing of the default C-TAB and C-S-TAB to quickly "jump" between closer tabs. Now, I wanna quickly check my Mail, I'd like something more "precise" jumping than eye balling everything.

This is were our second utility function comes to hand:

(defun emacs-solo/tab-switch-to-group ()
  "Prompt for a tab group and switch to its first tab.
Uses position instead of index field."
  (interactive)
  (let* ((tabs (funcall tab-bar-tabs-function)))
	(let* ((groups (delete-dups (mapcar (lambda (tab)
										  (funcall tab-bar-tab-group-function tab))
										tabs)))
		   (group (completing-read "Switch to group: " groups nil t)))
	  (let ((i 1) (found nil))
		(dolist (tab tabs)
		  (let ((tab-group (funcall tab-bar-tab-group-function tab)))
			(when (and (not found)
					   (string= tab-group group))
			  (setq found t)
			  (tab-bar-select-tab i)))
		  (setq i (1+ i)))))))
  (global-set-key (kbd "C-x t g") #'emacs-solo/tab-switch-to-group)

This allows us to "list all available groups", select and switch to the first tab of that group.

Packing the entire config

The code here presented by parts is now part of my emacs-solo config (hence the prefix on the function names), I usually keep my configuration somewhat organized by use-package blocks, they keep everything in the right place and I suggest you do the same. Also it is a lot faster to grab this code, copy and paste to your config and make it work!

(use-package tab-bar
  :ensure nil
  :defer t
  :custom
  (tab-bar-close-button-show nil)
  (tab-bar-new-button-show nil)
  (tab-bar-tab-hints t)
  (tab-bar-auto-width nil)
  (tab-bar-separator " ")
  (tab-bar-format '(tab-bar-format-tabs-groups
					Tab-bar-format-tabs tab-bar-separator
					tab-bar-format-add-tab))
  :init
  ;;; --- OPTIONAL INTERNAL FN OVERRIDES TO DECORATE NAMES
  (defun tab-bar-tab-name-format-hints (name _tab i)
	  (if tab-bar-tab-hints (concat (format "»%d«" i) "") name))

  (defun tab-bar-tab-group-format-default (tab _i &optional current-p)
	(propertize
	 (concat (funcall tab-bar-tab-group-function tab))
	 'face (if current-p 'tab-bar-tab-group-current 'tab-bar-tab-group-inactive)))


  ;;; --- UTILITIES FUNCTIONS
  (defun emacs-solo/tab-group-from-project ()
	"Call `tab-group` with the current project name as the group."
	(interactive)
	(when-let* ((proj (project-current))
				(name (file-name-nondirectory
					   (directory-file-name (project-root proj)))))
	  (tab-group (format "[%s]" name))))

  (defun emacs-solo/tab-switch-to-group ()
  "Prompt for a tab group and switch to its first tab.
Uses position instead of index field."
  (interactive)
  (let* ((tabs (funcall tab-bar-tabs-function)))
	(let* ((groups (delete-dups (mapcar (lambda (tab)
										  (funcall tab-bar-tab-group-function tab))
										tabs)))
		   (group (completing-read "Switch to group: " groups nil t)))
	  (let ((i 1) (found nil))
		(dolist (tab tabs)
		  (let ((tab-group (funcall tab-bar-tab-group-function tab)))
			(when (and (not found)
					   (string= tab-group group))
			  (setq found t)
			  (tab-bar-select-tab i)))
		  (setq i (1+ i)))))))

  ;;; --- EXTRA KEYBINDINGS
  (global-set-key (kbd "C-x t P") #'emacs-solo/tab-group-from-project)
  (global-set-key (kbd "C-x t g") #'emacs-solo/tab-switch-to-group)

  ;;; --- TURNS ON BY DEFAULT
  (tab-bar-mode 1))

Customizations on tab-bar-properties

You might want to customize the tab-bar line, what I am using in these screenshots is:

(custom-set-faces
  '(tab-bar
	((t (:background "#232635" :foreground "#A6Accd"))))
  '(tab-bar-tab
	((t (:background "#232635" :underline t))))
  '(tab-bar-tab-inactive
	((t ( ;; :background "#232635" ;; uncomment to use this
		  ;; :box (:line-width 1 :color "#676E95")
		  ))))
  '(tab-bar-tab-group-current
	((t (:background "#232635" :foreground "#A6Accd" :underline t))))
  '(tab-bar-tab-group-inactive
	((t (:background "#232635" :foreground "#777")))))

So, time to ditch tmux?

I wish...

This functionality is indeed very useful, the UI mimics tmux-like power. And if this is enough for you, go for it! Ditch tmux!

For my use cases, the sheer possibility of any of my emacs-lisp code locking the one and only Emacs process means my beautifully designed and crafted Emacs session is going bye-bye with it. And yes, while emacs --daemon and restarting clients helps a lot here, let’s not pretend Emacs never goes sideways.

There are still solid reasons to keep tmux around:

➖ Fault tolerance. When you’re SSH’d into a remote machine and something crashes, tmux is still there, your shell lives on. Emacs tabs don’t protect you from network drops or X11/Wayland hiccups.

➖ Shell multiplexing. Sometimes you just want 3 quick shells, nothing fancy, don’t even want to boot up Emacs. tmux wins here. Fast, lightweight, and scriptable. You just install tmux, no fancy config needed to 'just use it'.

➖ System-level process separation. I like to keep long-running REPLs, tailing logs, or even a docker attach session in tmux. If Emacs dies, they don’t.

➖ Startup time. Emacs with heavy configuration can still take a second to feel "fully alive". When I want to attach to a ready-to-go shell session instantly, tmux a is just faster.

➖ Better separation. While the whole tab-bar and tab-group approach is super flexible, sometimes you just need the hard boundary of a terminal session completely isolated from the rest. There are things you do outside Emacs for good reason.

And let’s be honest, you don’t need to choose. These tools complement each other. What this configuration gives you is a powerful Emacs-as-an-OS experience, with clarity, agility, and a clean mental model. Use Emacs for your inner workflows, and tmux as your outer shell guardian.

Wrapping Up

With just a few lines of Elisp, no external packages, and some clever overriding, Emacs’ tab-bar and tab-bar-groups become serious productivity tools. If you’re someone juggling multiple projects, workflows, or simply enjoy clean organization inside your Emacs session, this setup gives you control and clarity.

While we might not throw tmux out of the toolbox just yet, we now have a native Emacs experience that feels modern, fast, and surprisingly intuitive. Use what’s best for your workflow, but know that Emacs is more than capable of stepping up its game.

So go ahead, give it a try, tweak it, theme it, and make Emacs your tmux... and more.

Happy hacking. ✨💻🤓🚀

Terminal Emacs users often face an annoying limitation: copying and pasting between Emacs and the system clipboard doesn’t "just work." While graphical Emacs integrates with the OS clipboard by default, the terminal version leaves that responsibility to you, especially if you're inside tmux, ssh, or simply prefer living in the terminal.

Thankfully, there are excellent packages like: xclip and clipetty, as well as guides like Emacswiki: CopyAndPaste that tackle this. They offer elegant solutions, often with additional features and broader compatibility.

But sometimes, you just want something small and direct, something you can copy-paste into your config and tweak per OS, with no external Emacs dependencies.

That’s what I present here.

✂️ emacs-solo-clipboard: A Minimal Clipboard Bridge

This snippet is part of my emacs-solo configuration. It gives terminal Emacs clipboard support using native system tools (which, of course, you need installed in your system):

➖ pbcopy / pbpaste for macOS

➖ clip.exe / powershell.exe for WSL

➖ wl-copy / wl-paste for Wayland

➖ xclip for X11

It hooks into Emacs' standard interprogram-cut-function and interprogram-paste-function APIs.

;;; EMACS-SOLO-CLIPBOARD
;;
;;  Allows proper copy/pasting on terminals
;;
(use-package emacs-solo-clipboard
  :ensure nil
  :no-require t
  :defer t
  :init
  (cond
   ;; macOS: use pbcopy/pbpaste
   ((eq system-type 'darwin)
	(setq interprogram-cut-function
		  (lambda (text &optional _)
			(let ((process-connection-type nil))
			  (let ((proc (start-process "pbcopy" "*Messages*" "pbcopy")))
				(process-send-string proc text)
				(process-send-eof proc)))))
	(setq interprogram-paste-function
		  (lambda ()
			(shell-command-to-string "pbpaste"))))

   ;; WSL (Windows Subsystem for Linux): Use clip.exe for copy and powershell.exe for paste
   ((and (eq system-type 'gnu/linux)
		 (getenv "WSLENV"))
	(setq interprogram-cut-function
		  (lambda (text &optional _)
			(let ((process-connection-type nil))
			  (let ((proc (start-process "clip.exe" "*Messages*" "clip.exe")))
				(process-send-string proc text)
				(process-send-eof proc)))))
	(setq interprogram-paste-function
		  (lambda ()
			(string-trim (shell-command-to-string "powershell.exe -command Get-Clipboard")))))

   ;; Linux with wl-copy/wl-paste (Wayland)
   ((and (eq system-type 'gnu/linux) (executable-find "wl-copy"))
	(setq interprogram-cut-function
		  (lambda (text &optional _)
			(let ((process-connection-type nil))
			  (let ((proc (start-process "wl-copy" "*Messages*" "wl-copy")))
				(process-send-string proc text)
				(process-send-eof proc)))))
	(setq interprogram-paste-function
		  (lambda ()
			(shell-command-to-string "wl-paste -n"))))

   ;; Linux with xclip (X11)
   ((and (eq system-type 'gnu/linux) (executable-find "xclip"))
	(setq interprogram-cut-function
		  (lambda (text &optional _)
			(let ((process-connection-type nil))
			  (let ((proc (start-process "xclip" "*Messages*" "xclip" "-selection" "clipboard")))
				(process-send-string proc text)
				(process-send-eof proc)))))
	(setq interprogram-paste-function
		  (lambda ()
			(shell-command-to-string "xclip -selection clipboard -o"))))))

⚠️ This Is Hacky, and That's the Point

This is not a library or polished package. It's a minimal Emacs Lisp snippet that works well if your system already provides the right clipboard utilities. It doesn't abstract anything and won't handle edge cases. But that also means:

✅ Easy to audit

✅ Easy to tweak

✅ Easy to share small pieces

You can literally just copy the macOS or Wayland part and ignore the rest.

🖥️ Bonus: OSC 52 Might Be All You Need

If you’re using a modern terminal emulator that supports OSC 52 (like Kitty, Windows Terminal, or Xterm with proper settings), you might not need any of the above clipboard setup.

Emacs has built-in support for OSC 52 clipboard integration via this simple line:

(setq xterm-extra-capabilities '(getSelection setSelection modifyOtherKeys))

This tells Emacs to assume your terminal supports some extra features, including:

• getSelection: paste from the system clipboard
• setSelection: copy to the system clipboard
• modifyOtherKeys: unlock more reliable keybindings (like C-,)

This works without any external tools as long as your terminal supports OSC 52 and your Emacs was built with Xterm support (most builds are).

💡 Tip: Try it! Copy something in Emacs with M-w and paste outside. If it works, you’re set. Otherwise, fallback to one of the system-specific setups above.

🔒 tmux users: OSC 52 support may require this to your ~/.tmux.conf:

set-option -s set-clipboard on
set -g allow-passthrough on

✅ Wrap-Up

If you’re running Emacs in the terminal and want clipboard support without extra layers or packages, this might be just what you need.

It’s not pretty. It might be not that smart. But it works.

And sometimes, that’s exactly the kind of config you want.

Let me know if you run into clipboard quirks I didn’t cover here, or if you’ve built your own minimalist setup, I’m always curious about tiny hacks that punch above their weight. 🧠🛠️🔥

Edit:

2025-06-20: Added the Bonus section reffering to xterm-extra-capabilities as suggested by user u/passkyw on r/emacs.

A practical quick-reference for the JJ (Jujutsu) version control system: not a tutorial, but a ready-to-use guide with the most essential commands and workflows.

🧠 Heads-Up: This Is Not a Tutorial!

If you're expecting a walkthrough on how to use Jujutsu (JJ) from scratch, this post probably isn't what you're looking for.

There are already some great tutorials out there, including the excelent official one.

While this post serves as a cheat sheet and not a beginner tutorial, if you're looking for a video walkthrough to complement it, check out DevOps Toolbox awesome video:

» Also available here

🐦 Why JJ?

Jujutsu is a powerful version control system for software projects. You use it to get a copy of your code, track changes to the code, and finally publish those changes for others to see and use. It is designed from the ground up to be easy to use, whether you're new or experienced, working on brand new projects alone, or large scale software projects with large histories and teams.

What sets JJ apart is its focus on automatic working commits, which track your changes continuously without the usual manual commit overhead. This design makes JJ extremely fast, highly scriptable, and encourages maintaining a cleaner, more intuitive project history.

That said, JJ introduces new workflows and concepts that may feel unfamiliar at first. Common operations like merge or rebase behave differently, so keeping a quick reference or cheat sheet handy can make your transition smoother and more productive.

📎 The cheat sheet!

Basic Commands

Time Traveling

Branchless Workflow

More on log

Merging

Note: there's no jj checkout nor jj merge, those used to exist but are now deprecated. We use jj new ... for everything.

Rebasing

Notice: rebase always succeeds even with conflicts pending.

Merge Conflicts

If a conflict is present, jj st will tell you on which files you need to look for conflicts and solve.

Just save your file after solving and nothing else, no need to continue anything.

Log - Template Language

A bunch of options are provided to go with templates, some examples:

Format log to have commit-id, new line, description and ---- before next log entry.

jj log -T 'commit-id ++ "\n" ++ description ++ "\n------\n"'

Get short commit IDs of the working-copy parents:

jj log --no-graph -r @ -T 'parents.map(|c| c.commit_id().short()).join(",")'

Show machine-readable list of full commit and change IDs:

jj log --no-graph -T 'commit_id ++ " " ++ change_id ++ "\n"'

Log - Revset Language

A bunch of options are provided to go with templates, some examples:

Show the parent(s) of the working-copy commit (like git log -1 HEAD):

jj log -r @-

Show all ancestors of the working copy (like plain git log):

jj log -r ::@

Show commits not on any remote bookmark:

jj log -r 'remote_bookmarks()..'

Show commits not on `origin` (if you have other remotes like `fork`):

jj log -r 'remote_bookmarks(remote=origin)..'

Show the initial commits in the repo (the ones Git calls "root commits"):

jj log -r 'root()+'

Show some important commits (like git --simplify-by-decoration):

jj log -r 'tags() | bookmarks()'

Show local commits leading up to the working copy, as well as descendants of those commits:

jj log -r '(remote_bookmarks()..@)::'

Show commits authored by "martinvonz" and containing the word "reset" in the description:

jj log -r 'author(martinvonz) & description(reset)'

Diff - Fileset Language

A bunch of options are provided to go with templates, some examples:

Show diff excluding Cargo.lock.

jj diff '~Cargo.lock'

List files in src excluding Rust sources.

jj file list 'src ~ glob:"**/*.rs"'

Split a revision in two, putting `foo` into the second commit.

jj split '~foo'

JJ & Git - Co-locate

This means jj side by side with git.

Your project will have on its root, both a .jj and a .git directory.

Simple workflow to main branch:

jj log
jj commit -m "msg"
jj bookmark set --revision @- main
jj git push -r @-
jj op log

Workflow to push to a 'new git branch'

jj
jj bookmark set -r @ 'feat/blahk'
jj git push -r @ --allow-new --remote origin

To the next pushes, simply:

jj git push -r @

Some other useful commands since jj/git colocated relies heavily on bookmarks:

jj bookmark move --from=@- --to=@
jj bokmark delete '...'
jj bookmark track main@origin
jj git push --all --deleted

A complete set and more examples with:

jj help -k bookmarks

Note, after performing jj motions, probably the git part of the thing will be HEADLESS or in a detached state.

If you wish to perform "regular" git operations, most probably you need to first "git checkout" to a branch.

Stageless Workflow

Jujutsu has no traditional staging area like Git. This means changes you make in your working copy are immediately part of your current change (also called a working commit). So what if you’ve modified 10 files but only want to “commit” 2 of them?

💡 You can mimic partial commits with a few simple commands.

Special thanks to @Cassiano for for pointing this out to me!

🪄 The trick: jj split

Use jj split to break your current change into two:

jj split

This opens a TUI (Text User Interface) where you can select which files or even hunks to split into a new change.

What happens:

• The selected changes go into a new change (on top of your current one)

• The rest stay in the original change

💬 Think of it like “staging” part of your work and “committing” it, without ever touching an index.

🧪 Example Workflow

1. You edit fileA.ts, fileB.ts, and fileC.ts.
2. But you only want to commit the changes to fileA.ts.
3. Run:

jj split

4. Select only fileA.ts in the UI.
5. Give the new change a description with:

jj describe -m "Refactor fileA logic"

Now your fileA.ts changes are safely committed. You're still on the remaining changes for fileB.ts and fileC.ts.

🔄 You can repeat the process to incrementally split off changes until you're happy.

🏁 Wrapping Up

This cheat sheet is not a comprehensive tutorial, as said before, it’s a quick reference, a jumping-off point, and a distilled guide for navigating jj. Whether you're exploring jj out of curiosity or looking to speed up your workflow without staging overhead, I hope this post gave you enough to get started with confidence.

Remember: tools don’t define your flow, your habits and clarity do. If jj helps you think more clearly about your changes, then it’s doing its job. And if not? That’s fine too, there’s always git or even hg right around the corner.

If you have tweaks, corrections, or your own tricks, I’d love to hear them!

Thanks for reading! 🧠💻🔥

⚠️ WARNING: EMOJI HEAVY CONTENT AHEAD ⚠️

🚨📢 Pro Tip: Need more emoji in your life? Emacs C-x 8 RET is magic 🪄✨

There are many ways to enhance Dired in Emacs. From full-featured packages like diff-hl, all-the-icons-dired and nerd-icons-dired to built-in solutions. There's absolutely nothing wrong with using well-maintained packages (I do for many things!), but sometimes you might want something more minimal or tailored to your workflow.

These are my personal implementations from Emacs Solo that follow a specific philosophy:

🛠️ No dependencies: beyond Emacs itself

📋 Copy/paste installable: into any config

🧰 Hacky but practical: they solve my needs first and small imperfections are ok

🔧 Easily modifiable: if you know basic Elisp

Some screenshots of what were are talking about:

What These Do

1️⃣ Git Status Gutter: Left-margin indicators for file status (modified/added/deleted)

2️⃣ File Type Icons: Unicode symbols instead of heavy icon fonts

Note: These aren't trying to replace full packages. They're alternatives for those who prefer lightweight solutions.

1. File Icons Using Unicode

A font-free alternative to icon packages:

;;; EMACS-SOLO-DIRED-ICONS
;;
(use-package emacs-solo-dired-icons
  :ensure nil
  :no-require t
  :defer t
  :init
  (defvar emacs-solo/dired-icons-file-icons
	'(("el" . "📜")      ("rb" . "💎")      ("js" . "⚙️")      ("ts" . "⚙️")
	  ("json" . "🗂️")    ("md" . "📝")      ("txt" . "📝")     ("html" . "🌐")
	  ("css" . "🎨")     ("scss" . "🎨")    ("png" . "🖼️")    ("jpg" . "🖼️")
	  ("jpeg" . "🖼️")   ("gif" . "🖼️")    ("svg" . "🖼️")    ("pdf" . "📄")
	  ("zip" . "📦")     ("tar" . "📦")     ("gz" . "📦")      ("bz2" . "📦")
	  ("7z" . "📦")      ("org" . "📝")    ("sh" . "💻")      ("c" . "🔧")
	  ("h" . "📘")       ("cpp" . "➕")     ("hpp" . "📘")     ("py" . "🐍")
	  ("java" . "☕")    ("go" . "🌍")      ("rs" . "💨")      ("php" . "🐘")
	  ("pl" . "🐍")      ("lua" . "🎮")     ("ps1" . "🔧")     ("exe" . "⚡")
	  ("dll" . "🔌")     ("bat" . "⚡")      ("yaml" . "⚙️")    ("toml" . "⚙️")
	  ("ini" . "⚙️")     ("csv" . "📊")     ("xls" . "📊")     ("xlsx" . "📊")
	  ("sql" . "🗄️")    ("log" . "📝")     ("apk" . "📱")     ("dmg" . "💻")
	  ("iso" . "💿")     ("torrent" . "⏳") ("bak" . "🗃️")    ("tmp" . "⚠️")
	  ("desktop" . "🖥️") ("md5" . "🔐")     ("sha256" . "🔐")  ("pem" . "🔐")
	  ("sqlite" . "🗄️")  ("db" . "🗄️")
	  ("mp3" . "🎶")     ("wav" . "🎶")     ("flac" . "🎶")
	  ("ogg" . "🎶")     ("m4a" . "🎶")     ("mp4" . "🎬")     ("avi" . "🎬")
	  ("mov" . "🎬")     ("mkv" . "🎬")     ("webm" . "🎬")    ("flv" . "🎬")
	  ("ico" . "🖼️")     ("ttf" . "🔠")     ("otf" . "🔠")     ("eot" . "🔠")
	  ("woff" . "🔠")    ("woff2" . "🔠")   ("epub" . "📚")    ("mobi" . "📚")
	  ("azw3" . "📚")    ("fb2" . "📚")     ("chm" . "📚")     ("tex" . "📚")
	  ("bib" . "📚")     ("apk" . "📱")     ("rar" . "📦")     ("xz" . "📦")
	  ("zst" . "📦")     ("tar.xz" . "📦")  ("tar.zst" . "📦") ("tar.gz" . "📦")
	  ("tgz" . "📦")     ("bz2" . "📦")     ("mpg" . "🎬")     ("webp" . "🖼️")
	  ("flv" . "🎬")     ("3gp" . "🎬")     ("ogv" . "🎬")     ("srt" . "🔠")
	  ("vtt" . "🔠")     ("cue" . "📀"))
	"Icons for specific file extensions in Dired.")

  (defun emacs-solo/dired-icons-icon-for-file (file)
	(if (file-directory-p file)
		"📁"
	  (let* ((ext (file-name-extension file))
			 (icon (and ext (assoc-default (downcase ext) emacs-solo/dired-icons-file-icons))))
		(or icon "📄"))))

  (defun emacs-solo/dired-icons-icons-regexp ()
	"Return a regexp that matches any icon we use."
	(let ((icons (mapcar #'cdr emacs-solo/dired-icons-file-icons)))
	  (concat "^\\(" (regexp-opt (cons "📁" icons)) "\\) ")))

  (defun emacs-solo/dired-icons-add-icons ()
	"Add icons to filenames in Dired buffer."
	(when (derived-mode-p 'dired-mode)
	  (let ((inhibit-read-only t)
			(icon-regex (emacs-solo/dired-icons-icons-regexp)))
		(save-excursion
		  (goto-char (point-min))
		  (while (not (eobp))
			(condition-case nil
				(when-let ((file (dired-get-filename nil t)))
				  (dired-move-to-filename)
				  (unless (looking-at-p icon-regex)
					(insert (concat (emacs-solo/dired-icons-icon-for-file file) " "))))
			  (error nil))  ;; gracefully skip invalid lines
			(forward-line 1))))))

  (add-hook 'dired-after-readin-hook #'emacs-solo/dired-icons-add-icons))