Mike Olson - Emacs Blog Posts

Fixing typescript-ts-mode in Emacs 30.2

Mike Olson — Mon, 20 Apr 2026 00:00:00 GMT

The Symptom
The Root Cause
The Approach
How to Use It
Caveats
Removal Plan

The Symptom

After a recent Arch update, my Emacs 30.2 + typescript-ts-mode combination started dying the first time I opened a .ts or .tsx file:

Error: treesit-query-error ("Invalid predicate" "match")

The file would still display, but without any syntax highlighting. python-ts-mode exhibited the same failure. js-ts-mode and c-ts-mode worked in the main buffer but had their own breakages around JSDoc ranges and C’s emacs-specific range queries.

The Root Cause

This is Emacs bug#79687↗, an interaction between how Emacs 30.2 serializes tree-sitter query predicates and what libtree-sitter 0.26 (the version shipped by Arch) accepts.

Tree-sitter queries can embed predicates like (:match "^foo" @name) to filter captures at query-evaluation time. Emacs 30.2 serializes these s-expression predicates to strings that look like #match (no trailing ?), but libtree-sitter 0.26 became strict about predicate naming and rejects unknown names at query-parse time. The fix on Emacs master (commit b0143530) switches serialization to #match?, which libtree-sitter accepts. That fix has not been backported to the emacs-30 branch as of 30.2.

Rewriting the strings yourself doesn’t help either, because Emacs 30.2’s own predicate dispatcher hardcodes bare match/equal/pred and rejects match?/equal?/pred? at evaluation time. So any rewrite that satisfies libtree-sitter breaks Emacs, and vice versa.

The Approach

Since neither side accepts a string-level rewrite, I work at a higher level instead: strip the predicates entirely from queries, and move the predicate logic into capture-name-is-a-function fontifiers.

A tree-sitter font-lock rule like:

((identifier) @font-lock-keyword-face
 (:match "\\`\\(break\\|continue\\)\\'" @font-lock-keyword-face))

gets rewritten to:

((identifier) @my-ts-rw--fn-font-lock-keyword-face-abc12345)

where the auto-generated function my-ts-rw--fn-font-lock-keyword-face-abc12345 applies font-lock-keyword-face to the node only if the node’s text matches the original regex. The resulting query contains no predicates, so libtree-sitter is happy; the fontifier applies the face only when the original predicate would have matched, so the semantics are preserved.

The rewrite happens via :filter-args advice on three Emacs functions:

treesit-font-lock-rules is the main call path for font-lock rules and covers nearly all modes.
treesit-range-rules is used by js-ts-mode (and others) to embed a JSDoc parser inside comment nodes.
treesit-query-compile catches modes like c-ts-mode that compile queries directly with an s-expression containing :match.

How to Use It

The workaround lives in a single file in my emacs-shared↗ repo: init/treesit-predicate-rewrite.el↗.

Drop the file somewhere on your load path and load it early, before any tree-sitter mode runs its font-lock setup:

(load "/path/to/treesit-predicate-rewrite" nil nil nil t)

It self-activates via define-advice, so there’s no setup call to make. The advice is a no-op on queries that don’t contain predicates, so it’s safe to leave on even after the bug is fixed upstream.

Caveats

The rewriter handles three cases:

Predicate targets a face capture. Rewrites into a fontifier as shown above. This applies to the vast majority of uses in typescript-ts-mode, python-ts-mode, and friends.
An outer group wraps an inner scratch capture, a pattern used by ruby-ts-mode where the face lives on the outer group and the predicate tests a scratch capture inside. Flattened and then handled as case 1.
Predicate targets a non-face capture. The predicate is silently stripped, which means the fontifier will over-match. elixir-ts-mode uses this pattern heavily. In practice the visual regression is minor, but if it bothers you, set my-ts-rw-verbose to t to log strips.

:equal predicates are handled for cases 1 and 2. :pred falls back to strip (case 3) since replicating an arbitrary user function inside a fontifier is more trouble than it’s worth.

I’ve verified the fix on typescript-ts-mode, tsx-ts-mode, python-ts-mode, js-ts-mode, c-ts-mode, rust-ts-mode, java-ts-mode, go-ts-mode, and lua-ts-mode. All load and fontify without errors.

Removal Plan

Once I upgrade to an Emacs that carries the bug#79687 fix (Emacs 31, or a backport into a future 30.x), I’ll delete the file and the load line. Until then, it’s one file and one load line, so the maintenance cost is low.

eglot-python-preset and eglot-typescript-preset: Now on MELPA

Mike Olson — Thu, 02 Apr 2026 00:00:00 GMT

Introduction
What Changed
Installation
- Python
- TypeScript
Out-of-the-Box Multi-LSP
Per-Project Configuration
Links

Introduction

A quick follow-up to my earlier posts on eglot-python-preset and the beta multi-LSP release: both packages are now available on MELPA with full rassumfrassum↗ (rass) support included.

When I wrote the beta post in March, eglot-typescript-preset wasn’t on MELPA at all, and eglot-python-preset’s MELPA version didn’t include rass support. That’s no longer the case. You can install both with a standard use-package :ensure t and get multi-LSP out of the box.

What Changed

The main thing that landed since the beta: MELPA now ships the rass backend for both packages. This means the rass LSP server option and all the preset generation machinery are available without cloning repos or managing load paths manually.

Both packages also now set up Eglot integration automatically when Eglot loads, so you no longer need an explicit (eglot-python-preset-setup) or (eglot-typescript-preset-setup) call in your config. Just install and go.

Installation

Python

(use-package eglot-python-preset
  :ensure t
  :custom
  (eglot-python-preset-lsp-server 'ty)) ; or 'basedpyright or 'rass

With the default ty backend, this gives you type checking for standard Python projects and PEP-723 scripts with no further configuration. Switch to rass to run ty and Ruff simultaneously:

(use-package eglot-python-preset
  :ensure t
  :custom
  (eglot-python-preset-lsp-server 'rass)
  (eglot-python-preset-rass-tools '(ty ruff)))

TypeScript

(use-package eglot-typescript-preset
  :ensure t)

That’s it. The defaults configure typescript-language-server for TS/JS files and use rass to combine language servers with Tailwind CSS support for CSS, Astro, Vue, and Svelte buffers. If your project uses any of those frameworks, the corresponding language server starts automatically when you open a file in that mode.

To add linting alongside the TypeScript language server, switch the TS/JS backend to rass:

(use-package eglot-typescript-preset
  :ensure t
  :custom
  (eglot-typescript-preset-lsp-server 'rass)
  (eglot-typescript-preset-rass-tools
   '(typescript-language-server eslint)))

Out-of-the-Box Multi-LSP

The part I’m most pleased with is how much works without any rass-specific configuration on the TypeScript side. The default settings for CSS, Astro, Vue, and Svelte all use rass, combining each framework’s language server with Tailwind CSS support automatically.

For Astro, this means astro-ls runs alongside ESLint and tailwindcss-language-server in a single Eglot session. Vue gets hybrid mode where vue-language-server handles template features and typescript-language-server with @vue/typescript-plugin provides type checking, plus Tailwind. Svelte works similarly.

On the Python side, the rass backend lets you run ty for type checking and Ruff for linting in the same buffer. PEP-723 scripts work too: the generated rass preset includes the script’s cached uv environment so both tools resolve imports.

All of this resolves executables from project-local directories first (node_modules/.bin for JS/TS, .venv for Python), falling back to your PATH.

Per-Project Configuration

Both packages support per-project overrides via .dir-locals.el or dir-locals-set-directory-class. The preset variables are declared as safe local variables, so Emacs applies them without prompting. For example, if one project uses Biome instead of ESLint:

;;; .dir-locals.el
((typescript-ts-mode
  . ((eglot-typescript-preset-lsp-server . rass)
     (eglot-typescript-preset-rass-tools
      . (typescript-language-server biome)))))

Beta: Emacs Multi-LSP support for Python and Typescript frameworks

Mike Olson — Mon, 16 Mar 2026 00:00:00 GMT

Introduction
Why rass?
Python: ty + Ruff in One Buffer
TypeScript: Multi-Framework LSP Support
- Astro + ESLint + oxlint
- Supported Frameworks
Per-Project Configuration
- In-repo: .dir-locals.el
- Out-of-repo: dir-locals-set-directory-class
Installation
Feedback Welcome
Links

Introduction

Back in January I announced eglot-python-preset, an Emacs package that simplifies Python LSP configuration with Eglot. At the time, I mentioned rass support as a future direction. That future has arrived, and it brought a companion package along with it.

Both eglot-python-preset↗ and the new eglot-typescript-preset↗ now support rassumfrassum↗ (rass), an LSP multiplexer written by Eglot’s author. This means you can run multiple language servers simultaneously through a single Eglot connection, such as a type checker alongside a linter or a language server alongside a formatter, with minimal configuration.

The eglot-typescript-preset package covers Astro, Vue, Svelte, Deno, and CSS/Tailwind out of the box. On the linting side, it integrates with ESLint, oxlint, Biome, and oxfmt through rass, so you can combine a type checker with one or more linters in the same Eglot session.

This is a beta release. The rass backend works well in my day-to-day use, but the MELPA packages don’t support rass yet. I have pending PRs with MELPA for both packages, and eglot-typescript-preset isn’t on MELPA at all yet. For now, manual installation (cloning the repos) is the way to go if you want to try rass support.

Why rass?

Eglot is designed around one language server per major mode. If you want type checking from ty and linting from Ruff in the same Python buffer, or TypeScript diagnostics alongside ESLint, you’d normally have to choose one or run a separate tool outside the LSP workflow.

rass solves this by acting as a stdio multiplexer: it presents itself as a single LSP server to Eglot while dispatching requests to multiple backend tools. From Eglot’s perspective, nothing changes. From your perspective, you get diagnostics, completions, and code actions from all your tools in one place.

The preset packages handle the rass configuration for you. You declare which tools you want, and the package generates the appropriate rass preset file automatically. When your project has tools installed locally (in .venv or node_modules), those executables are preferred over global installations.

Python: ty + Ruff in One Buffer

To use rass with eglot-python-preset, set the LSP server to rass and list your tools:

(use-package eglot-python-preset
  :ensure t
  :after eglot
  :custom
  (eglot-python-preset-lsp-server 'rass)
  (eglot-python-preset-rass-tools '(ty ruff))
  :config
  (eglot-python-preset-setup))

This gives you ty’s type checking and Ruff’s linting diagnostics in every Python buffer, with zero per-project setup for standard projects. PEP-723 scripts work too: the generated rass preset includes the script’s cached uv environment so both tools resolve imports correctly.

You can also use basedpyright instead of ty, or pass literal command vectors for custom tools:

(setopt eglot-python-preset-rass-tools
        '(basedpyright
          ruff
          ["custom-lsp" "--stdio"]))

TypeScript: Multi-Framework LSP Support

eglot-typescript-preset is brand new. It configures Eglot for TypeScript, JavaScript, CSS, and several frontend frameworks, with rass support for combining tools like ESLint, Biome, oxlint, and oxfmt alongside the TypeScript language server.

The default setup requires no rass and works out of the box:

(use-package eglot-typescript-preset
  :ensure t
  :after eglot
  :config
  (eglot-typescript-preset-setup))

This configures typescript-language-server for TS/JS files, astro-ls for Astro files, and vscode-css-language-server with tailwindcss-language-server for CSS, all automatically.

Astro + ESLint + oxlint

One setup I’m particularly happy with is a fully-working Astro project with both ESLint and oxlint. The idea is that oxlint handles the fast, low-level lint rules while ESLint covers the Astro-specific and framework-aware rules. To avoid duplicate diagnostics, the eslint-plugin-oxlint↗ package disables ESLint rules that oxlint already covers.

On the Emacs side, the configuration is straightforward:

(setopt eglot-typescript-preset-lsp-server 'rass)
(setopt eglot-typescript-preset-rass-tools
        '(typescript-language-server eslint oxlint))
(setopt eglot-typescript-preset-astro-lsp-server 'rass)
(setopt eglot-typescript-preset-astro-rass-tools
        '(astro-ls eslint oxlint))

All three tools contribute diagnostics to the same Eglot session, and the preset handles executable resolution from your project’s node_modules automatically.

Supported Frameworks

Beyond plain TypeScript and JavaScript, eglot-typescript-preset supports:

Astro via astro-ls, with automatic TypeScript SDK detection
CSS support via vscode-css-language-server, optionally combined with tailwindcss-language-server
Deno as an alternative backend for Deno-based projects
Svelte via svelte-language-server, with TypeScript SDK path forwarding
Vue via vue-language-server in hybrid mode, where Vue handles template features and typescript-language-server with @vue/typescript-plugin provides type checking

Per-Project Configuration

Both packages support per-project overrides, so different projects can use different tools. There are two approaches.

In-repo: `.dir-locals.el`

Drop a .dir-locals.el in the project root. The preset packages declare their variables as safe with appropriate values, so Emacs applies them without prompting:

;;; .dir-locals.el for a Python project using basedpyright + ruff
((python-ts-mode
  . ((eglot-python-preset-lsp-server . rass)
     (eglot-python-preset-rass-tools . (basedpyright ruff)))))

;;; .dir-locals.el for a TypeScript project using biome instead of eslint
((typescript-ts-mode
  . ((eglot-typescript-preset-lsp-server . rass)
     (eglot-typescript-preset-rass-tools
      . (typescript-language-server biome)))))

Out-of-repo: `dir-locals-set-directory-class`

If you’d rather not add Emacs-specific files to a project, configure it from your init file:

(dir-locals-set-class-variables
 'my-python-project
 '((python-ts-mode
    . ((eglot-python-preset-lsp-server . rass)
       (eglot-python-preset-rass-tools . (ty ruff))))))

(dir-locals-set-directory-class
 (expand-file-name "~/devel/my-python-project") 'my-python-project)

(dir-locals-set-class-variables
 'my-astro-project
 '((typescript-ts-mode
    . ((eglot-typescript-preset-lsp-server . rass)
       (eglot-typescript-preset-rass-tools
        . (typescript-language-server eslint oxlint))))
   (astro-ts-mode
    . ((eglot-typescript-preset-astro-lsp-server . rass)
       (eglot-typescript-preset-astro-rass-tools
        . (astro-ls eslint oxlint))))))

(dir-locals-set-directory-class
 (expand-file-name "~/devel/my-astro-project") 'my-astro-project)

Installation

Of note:

The rass backend works and has fairly extensive tests.
MELPA packages don’t support rass yet. I have pending PRs with MELPA for both packages. Until those land, you need to install from source.
The eglot-typescript-preset package isn’t on MELPA at all yet. A submission is pending.

To install manually:

mkdir -p ~/devel
git clone https://github.com/mwolson/eglot-python-preset ~/devel/eglot-python-preset
git clone https://github.com/mwolson/eglot-typescript-preset ~/devel/eglot-typescript-preset

(add-to-list 'load-path (expand-file-name "~/devel/eglot-python-preset"))
(add-to-list 'load-path (expand-file-name "~/devel/eglot-typescript-preset"))

(require 'eglot-python-preset)
(setopt eglot-python-preset-lsp-server 'rass)
(setopt eglot-python-preset-rass-tools '(ty ruff))
(eglot-python-preset-setup)

(require 'eglot-typescript-preset)
(setopt eglot-typescript-preset-lsp-server 'rass)
(setopt eglot-typescript-preset-rass-tools '(typescript-language-server eslint))
(eglot-typescript-preset-setup)

Both packages require Emacs 30.2 or later and rass↗ v0.3.3 or later.

Feedback Welcome

If you try either package, I’d appreciate hearing about your experience. The best way to reach me is through GitHub Discussions on the respective repos:

In particular, I’d love to hear from people using the JS/TS frameworks we support (Astro, Vue, Svelte, and Deno) as well as anyone working with CSS and Tailwind. If there’s a commonly-used framework or tool you’d like to see supported, please open a discussion. The more real-world usage these packages get, the more confident I’ll be promoting them from beta.

First Week with Jujutsu VCS

Mike Olson — Thu, 22 Jan 2026 00:00:00 GMT

I’ve spent my first week using Jujutsu↗ (jj), a Git-compatible version control system that takes a different approach to managing commits and branches. Here are my impressions and some configuration tips I’ve picked up along the way.

Configuring Immutable Bookmarks
Emacs Integration with Majutsu
Rebasing Stacked Branches
Cleaning Up After Rebases
Magit and jj - Conflict Resolution
Magit and jj - ’@’ Branch
Overall Impressions

Configuring Immutable Bookmarks

One of the first things I changed was the default immutability settings. Jujutsu’s default configuration locks down remote bookmarks (which are “branches” in Git terms) as immutable, which prevents accidental modifications but can be overly restrictive.

I added this to ~/.config/jj/config.toml:

[revset-aliases]
"immutable_heads()" = "present(trunk()) | tags()"

This relaxes the immutability rules to only protect the trunk (the default branch, typically main or master from the backing Git repo) and tags, giving me more flexibility to work with feature branches that have been pushed to remotes.

Emacs Integration with Majutsu

For Emacs integration, I’m using majutsu↗, which provides a Magit-like interface for Jujutsu. I configured it to start in a log buffer showing the branches I care about, with the ability to hit Enter to visit a commit or O to start a new commit at that point.

Here’s my configuration from my shared Emacs init↗:

(defun my-replace-cdrs-in-alist (old-el new-el alist)
  "Replace cdr instances of OLD-EL with NEW-EL in ALIST."
  (mapc #'(lambda (el)
            (when (eq (cdr el) old-el)
              (setcdr el new-el)))
        (symbol-value alist)))

;; Set up majutsu
(with-eval-after-load "majutsu"
  ;; Replace pop-to-buffer with switch-to-buffer for same-window behavior
  (my-replace-cdrs-in-alist 'pop-to-buffer 'switch-to-buffer
                            'majutsu-display-functions)
  (setopt majutsu-default-display-function #'switch-to-buffer))

(defun my-majutsu-log ()
  (interactive)
  (majutsu-log (or (my-project-root) default-directory)))

;; Set up keybinds
(with-eval-after-load "project"
  (keymap-set project-prefix-map "j" #'my-majutsu-log))

(keymap-global-set "C-x V j" #'my-majutsu-log)

The key customizations here:

Same-window display: I replaced pop-to-buffer with switch-to-buffer so that majutsu buffers open in the current window rather than splitting. This matches my preferred Magit workflow.
A project-aware log: The my-majutsu-log function opens the log at the detected project root, which I bind to C-x V j in my global keymap, or j when visiting a project. It will also offer to initialize jj if I haven’t done so yet.

Rebasing Stacked Branches

Rebasing stacked branches onto an updated main branch is quite nice with Jujutsu:

jj git fetch

# Rebase all commits on feature-branch that aren't already in main
jj rebase -b feature-branch -o main

The -b flag specifies the branch to rebase, and -o specifies the new base. Jujutsu handles the rebase intelligently, only moving commits that aren’t already part of main, and automatically brings over multiple bookmarks that may be on that branch.

I also have a script fragment that can update all tracked bookmarks on all Git submodules:

# excerpt - assume $d is current submodule
main_branch=$(git config -f "$topdir"/.gitmodules submodule.$d.branch || echo main)

jj bookmark track "${main_branch}" --remote=origin 2>/dev/null || true
jj git fetch

# Check for bookmark conflicts after fetch
if jj bookmark list -t 2>/dev/null | grep -q "conflict"; then
    echo "Warning: Bookmark conflicts detected in $d"
    echo "Run 'cd $d && jj bookmark list -t' to see details"
    echo "Use 'jj bookmark track <bookmark> --remote=origin' to resolve"
fi

# Rebase all tracked bookmarks (except main) onto updated main
# Get list of tracked bookmarks, excluding the main branch and @origin suffixes
other_bookmarks=$(jj bookmark list -t 2>/dev/null | \
    grep -v "^  " | \
    awk '{print $1}' | \
    sed 's/:$//' | \
    grep -v "^${main_branch}\$" || true)

if [[ -n "$other_bookmarks" ]]; then
    for bookmark in $other_bookmarks; do
        # Skip if bookmark name is empty or contains @origin
        [[ -z "$bookmark" || "$bookmark" == *"@"* ]] && continue

        # Check if bookmark has commits not in main
        if jj log -r "${main_branch}..${bookmark}" --limit 1 2>/dev/null | grep -q .; then
            echo "Rebasing ${bookmark} onto ${main_branch}"
            if ! jj rebase -b "${bookmark}" -o "${main_branch}" 2>&1; then
                echo "Warning: Failed to rebase ${bookmark} - may have conflicts"
                echo "Run 'cd $d && jj log -r \"conflict()\"' to see conflicted commits"
            fi
        fi
    done
fi

Cleaning Up After Rebases

One minor annoyance: after rebasing, you may end up with orphaned bookmarks in your jj log output that clutter the view. You’ll need to manually clean these up with jj abandon to keep a tidy log. It can be a bit tedious, but so far I’m finding that it’s worth the effort to maintain a clear picture of which stacks haven’t been merged yet.

Magit and jj - Conflict Resolution

Here’s an important gotcha I discovered: if you’re in the middle of resolving a Jujutsu merge and you run magit-status, Emacs can slow to a crawl. Magit will show hundreds of conflicting symlinks (which is how jj represents conflicts in the working directory), overwhelming the buffer.

The best practice is to stay in Jujutsu’s tooling once you start resolving conflicts there. Don’t switch to Magit mid-resolution.

This situation commonly arises when squash-merging PRs for a branch that is stacked on another. GitHub’s squash merge creates a new commit that doesn’t match the commits jj knows about, which can leave your local branch in a state where jj thinks it needs to merge.

When this happens, it can save significant time to rebase using a specific commit ID rather than a bookmark name:

# Find the commit ID of main after the squash merge
jj log -r <bookmark>

# Rebase your bookmark starting at that specific commit onto main
jj rebase -s <earliest-commit-id-of-bookmark> -o main

This explicitly tells jj which commit to move and where, avoiding the merge conflicts that arise from the squash merge mismatch. I do something similar with subset-rebases in Magit when using Git.

Magit and jj - ’@’ Branch

Using jj and then using Magit can cause Magit to be confused about what branch it’s on. Unfortunately because of the existence of @ as a branch, which comes before the typical name of the branch when showing a revision, Magit treats @ as the one that’s meaningful and doesn’t show the merge/push target for the branch I actually care about. I haven’t yet found a good solution, other than manually specifying where to push. Maybe Magit could be advised to ignore that branch at some point.

Overall Impressions

After a week, I’m finding Jujutsu’s model fairly intuitive once you get past the initial learning curve, though I’m still using Git most of the time. The automatic tracking of the working copy as a commit, the powerful revset language, and the Git compatibility does make jj an interesting alternative to keep learning.

Announcing eglot-python-preset

Mike Olson — Sun, 11 Jan 2026 00:00:00 GMT

Introduction
What eglot-python-preset Does
Basic Setup
Key Commands
Future Directions
Links

Introduction

I’m happy to announce the release of eglot-python-preset↗, a new Emacs package that simplifies Python LSP configuration with Eglot. It’s now available on MELPA.

The package was born from a discussion on r/emacs↗ about using Emacs for Python development with uv and basedpyright. The original poster had a common pain point: they were writing standalone Python scripts with PEP-723↗ inline dependencies, using uv run script.py to execute them. Everything worked fine from the command line, but their LSP (basedpyright) couldn’t resolve the imports because it had no awareness of uv’s cached environments.

This is a gap in the tooling. uv manages isolated environments for PEP-723 scripts automatically, but there was no bridge between those environments and the editor’s language server. You’d get reportMissingImports errors for packages that were clearly installed and working at runtime.

What eglot-python-preset Does

The package handles the glue between uv, PEP-723 scripts, and your LSP server. When you open a Python file containing PEP-723 metadata:

It detects the script metadata automatically
It locates the cached uv environment for that script (or prompts you to create one)
It configures the LSP server to use that environment for type checking

For standard Python projects with pyproject.toml or requirements.txt, the package handles project root detection so Eglot starts from the right directory.

Basic Setup

Installation from MELPA:

(use-package eglot-python-preset
  :ensure t
  :after eglot
  :custom
  (eglot-python-preset-lsp-server 'ty) ; or 'basedpyright
  :config
  (eglot-python-preset-setup))

The package supports both ty↗ (Astral’s new Rust-based type checker) and basedpyright↗. See my earlier post on ty for why you might want to try ty — it’s dramatically faster than the alternatives.

Key Commands

M-x eglot-python-preset-sync-environment - Sync dependencies for a PEP-723 script using uv sync --script, then restart Eglot. Use this after adding or modifying dependencies in your script’s metadata block.
M-x eglot-python-preset-remove-environment - Remove the cached environment to force a clean reinstall.
M-x eglot-python-preset-run-script - Run the current script using uv run in a compilation buffer.

Future Directions

There are two potential follow-ups I’m considering:

Autodetecting tools: Currently you choose between ty and basedpyright manually. It would be useful to detect the appropriate LSP server automatically based on project configuration or installed tools.

rass support: The rassumfrassum↗ project (an LSP multiplexer by Eglot’s author) could integrate with eglot-python-preset to run multiple servers like ty and Ruff simultaneously. rass might eventually handle autodetection itself, or it could be done on the elisp side. Either way, better integration with rass may be worth exploring.

ty: A Fast Python Type Checker and LSP for Emacs

Mike Olson — Wed, 17 Dec 2025 00:00:00 GMT

Introduction
Setting Up ty with Eglot
The Multi-LSP Question
Current Status

Introduction

Recently Astral↗ (the team behind Ruff↗ and uv↗) announced the beta release of ty↗, an extremely fast Python type checker and language server written in Rust.

The performance numbers are impressive. Without caching, ty is consistently 10-60x faster than mypy and Pyright. In an editor context, the gap is even more dramatic: after editing a load-bearing file in the PyTorch repository, ty recomputes diagnostics in 4.7ms, which is 80x faster than Pyright (386ms) and 500x faster than Pyrefly (2.38s).

Beyond raw speed, ty includes some sophisticated type system features like first-class intersection types, advanced type narrowing, and best-in-class diagnostic messages inspired by Rust’s compiler. The diagnostics can pull context from multiple files to explain not just what’s wrong, but why.

Setting Up ty with Eglot

Since ty implements the Language Server Protocol, it’s straightforward to use with Emacs. Here’s my configuration using Eglot, the built-in LSP client:

(defun my-project-find-python-project (dir)
  (when-let ((root (locate-dominating-file dir "pyproject.toml")))
    (cons 'python-project root)))

(with-eval-after-load "project"
  (cl-defmethod project-root ((project (head python-project)))
    (cdr project))

  (add-hook 'project-find-functions #'my-project-find-python-project))

(add-to-list 'auto-mode-alist '("/uv\\.lock\\'" . toml-ts-mode))
(add-to-list 'major-mode-remap-alist '(python-mode . python-ts-mode))
(add-to-list 'eglot-server-programs
             '((python-ts-mode python-mode)
               . ("ty" "server")))
(add-hook 'python-ts-mode-hook #'eglot-ensure)

The project-find-functions hook ensures that Eglot starts ty from the correct directory in monorepos, picking up the right paths for code references. This is particularly important when you have multiple Python projects with different virtual environments.

If you’re using uv to manage your tools, you can use uvx instead:

(add-to-list 'eglot-server-programs
             '((python-ts-mode python-mode)
               . ("uvx" "ty" "server")))

The Multi-LSP Question

A question that sometimes comes up in the Emacs community is whether multi-LSP support is needed. For Python specifically, you might want both a type checker (ty, Pyright) and a linter/formatter (Ruff) running simultaneously on the same file.

How Other Editors Handle This

VSCode handles this transparently. Multiple language servers can attach to the same file type, and the editor merges their capabilities. This is largely invisible to users.

Neovim also has built-in support for multiple LSP clients per buffer. You can attach as many language servers as you want to a buffer, and Neovim will aggregate their diagnostics, completions, and other features.

Zed has built-in support for multiple language servers per language. You can enable or disable servers in your settings using a simple array syntax, and Zed already includes ty as a built-in option alongside basedpyright, Pyright, Ruff, and PyLSP.

lsp-mode (for Emacs) supports running multiple servers for the same file type. You can register a server with the :add-on? t flag to start it in parallel with other servers.

OpenCode (the AI coding agent) also handles multiple LSP servers natively. When a file is opened, OpenCode checks the file extension against all enabled LSP servers and starts each applicable one. Diagnostics from all servers are aggregated into a single collection, which is then provided to the LLM as context. The implementation is straightforward: each server runs in its own process, and diagnostics are merged by file path.

Eglot’s Approach

Eglot currently doesn’t support multiple language servers per buffer out of the box. The primary solution being developed by Eglot’s author is rassumfrassum↗, an external LSP multiplexer that presents multiple LSP servers as a single server to the client.

rassumfrassum works by spawning multiple LSP server subprocesses and merging their capabilities, diagnostics, and responses. For Python with ty and Ruff, you can run it directly from the command line:

rass -- ty server -- ruff server

Then configure Eglot to use that command:

(add-to-list 'eglot-server-programs
             '((python-ts-mode python-mode)
               . ("rass" "--" "ty" "server" "--" "ruff" "server")))

For the ty + Ruff use case specifically: these tools are complementary, not overlapping. ty is a type checker (replacing mypy/Pyright), while Ruff is a linter and formatter (replacing Flake8/Black/isort). If you want both type checking and linting/formatting, you’d need both servers running. That said, ty does include some features that overlap with linting, like dead code elimination and unused dependency detection, so the boundary may blur somewhat as ty matures.

Aside - Is an External Multiplexer Needed?

It’s worth asking whether an external tool like rassumfrassum is the right approach when most other editors have built-in multi-LSP support.

While this may keep Eglot’s codebase simpler and promote reusability, it’s also very much not aligned with what other popular editors are doing, as we’ve shown earlier.

One could argue that rass makes it easier to customize server combinations per-project via its Python preset files. But this is really just trading one config format for another - Eglot already supports per-project configuration via .dir-locals.el. I also like the competing idea of autodetecting what’s needed: my emacs-shared↗ configuration has this, albeit just for JS/TS projects currently.

Further pain points with rass:

Extra complexity for users (another tool to install and configure)
Potential performance overhead from the proxy layer, especially given the implementation in Python
I’d expect multi-LSP to “just work” like it does in other editors
lsp-mode already handles this natively
The documentation emphasizes Python config files (.py presets) over command-line arguments, which makes the tool feel more complex than it needs to be for simple use cases

One caveat: the approach of splitting up multiple LSP servers using a -- separator seems reasonably ergonomic to use with eglot-server-programs, but I wish that it were brought forward a bit more in the docs.

I think I have to conclude that if rass continues to be the way forward with Eglot, I may well end up switching to lsp-mode in the future. This may especially be the case for JS/TS projects, which will likely have fun combinations of eslint, oxlint, and biome for a while due to the evolving nature of those tools and the performance vs functionality trade-offs.

Current Status

ty is in beta, so some LSP features may not be fully implemented yet. The official docs↗ list supported capabilities including Go to Definition, Symbol Rename, Auto-Complete, Auto-Import, Semantic Syntax Highlighting, and Inlay Hints.

A patch to add ty to Eglot’s default server list has already been submitted by Steve Purcell (the MELPA maintainer), so it should be included in a future Emacs release.

If you’re doing Python development in Emacs, ty is worth trying out. The speed improvements alone make it compelling, and the diagnostic quality is excellent.

My Emacs AI Setup

Mike Olson — Wed, 03 Dec 2025 00:00:00 GMT

I’ve been evolving my Emacs AI workflow over the past year since releasing gptel-fn-complete, and I’m happy with where it’s currently landed. This post describes most of the AI tools that I use with Emacs and how they fit together.

A high-level overview:

I pare down and simplify minuet↗’s functionality quite a bit, and control which files and kinds of buffers it can act on.
I tend to use gptel↗ as the source of truth for which providers and models to use, as well as any common arguments like temperature or amount of thinking.
I tend to use OpenCode↗ outside of Emacs for most AI work, and then rely on auto-revert-mode (as implicitly enabled by Magit↗) to have Emacs catch up and review the changes.

Inline completions with minuet

minuet↗ provides automatic inline AI auto-completions in Emacs. I like that Minuet includes just the right amount of buffer context with the completions API, which improves the quality of the results.

By default, it shows multiple suggestions that you can cycle through, but I prefer the Cursor-style approach of showing just one suggestion at a time. This keeps the experience very simple and low-friction.

I’ll explain how to achieve that over the next few sections.

Basic configuration

After installing minuet and gptel from MELPA, I configure Minuet like so:

(with-eval-after-load "minuet"
  (setopt minuet-add-single-line-entry nil
          minuet-auto-suggestion-debounce-delay 0.3
          minuet-n-completions 1)

  (keymap-set minuet-active-mode-map "C-c C-c" #'minuet-accept-suggestion)
  (keymap-set minuet-active-mode-map "C-c C-n" #'minuet-next-suggestion)
  (keymap-set minuet-active-mode-map "C-c C-p" #'minuet-previous-suggestion)
  (keymap-set minuet-active-mode-map "C-g" #'minuet-dismiss-suggestion)
  (keymap-set minuet-active-mode-map "<tab>" #'minuet-accept-suggestion-line))

The settings are:

minuet-add-single-line-entry: Don’t clutter the completion menu too much with extra single-line versions of the suggestions
minuet-auto-suggestion-debounce-delay: How long to wait before requesting a suggestion
minuet-n-completions: Set to 1 for Cursor-style single suggestions

Once a code complete suggestion is presented, the following keys are available, in order of importance:

TAB: Complete just the first line of the suggestion
C-c C-c: Insert the entire multi-line suggestion
C-g: Remove the suggestion
C-n and C-p: Cycle through the next or previous suggestions

I’ll now describe a few other customizations that I think make Minuet a bit more ergonomic.

Blocking some suggestions within buffers

I make sure that suggestions only happen at the end of non-empty lines, to avoid having them trigger in cases where I’m reading through the file quickly or editing existing code. It’s also important to not attempt suggestions when the buffer is read-only, since that will never be helpful.

(defun my-minuet-block-suggestions ()
  "Return nil if we should show suggestions, t (blocked) otherwise.

Criteria:
- File must be writable
- Cursor must not be at beginning of line
- Cursor must be at the end of line (ignoring whitespace)."
  (not (and (not buffer-read-only)
            (not (bolp))
            (looking-at-p "\s*$"))))

(with-eval-after-load "minuet"
  (add-hook 'minuet-auto-suggestion-block-predicates
            #'my-minuet-block-suggestions -100))

Enabling Minuet at file-level

I enable Minuet’s auto-suggestion mode in programming buffers, with some exclusions:

;; kill switch for minuet functionality, currently allowed:
(defvar my-minuet-auto-suggest-p t)
;; my shared Emacs settings have this (disabled on every file by default):
(defvar my-minuet-exclude-file-regexps '(".*"))
;; my personal configuration has something like this:
(setq my-minuet-exclude-file-regexps '(".emacs.d/" ".gnupg/" ".ssh/"))

(defun my-minuet-exclude ()
  (let* ((filename (buffer-file-name)))
    (or (not filename)
        (when-let* ((lst my-minuet-exclude-file-regexps))
          (string-match-p
           (string-join (mapcar (##concat "\\(?:" % "\\)") lst) "\\|")
           filename)))))

(defun my-minuet-maybe-turn-on-auto-suggest ()
  (when (and my-minuet-auto-suggest-p (not (my-minuet-exclude)))
    (minuet-auto-suggestion-mode 1)))

(add-hook 'prog-mode-hook #'my-minuet-maybe-turn-on-auto-suggest t)

You’ll want to customize my-minuet-exclude-file-regexps to make sure any other sensitive directories are excluded from having their buffers sent to AI.

Provider configuration

I sync minuet’s provider settings from my gptel↗ configuration, which lets me use the same API keys and model settings across both tools. This part is a bit complex, but I switch between models often enough that it ended up being useful to have.

The code for this is available separately on my Emacs AI Setup Guide since it was getting a bit too long for a blog post. The gist is that I only configure API keys once in my auth-source file, and both gptel and minuet can use them.

For AI models within Emacs:

I currently use Kimi K2 for Minuet suggestions.
I use Claude Opus 4.5 for one-off gptel prompts and gptel-fn-complete.

I currently use OpenCode Zen↗ exclusively, for several reasons:

They have a tasteful selection of models.
It’s easy to switch between different models with the same API credit pool, which can be configured to automatically reload when below a threshold.
When they run a model, it’s almost certain to be stable, unlike my prior experience with some Openrouter providers.
They have models that have been no-cost for a while, and they recently started offering GPT 5.1 (one of my primary writing, coding, and task-following models) at a lower price than OpenAI does.

Keybinds

I have the following other keybinds to manually trigger minuet or gptel-fn-complete, in addition to some other useful xref bindings:

(defvar my-xref-map
  (let ((map (make-sparse-keymap)))
    (keymap-set map "c" #'minuet-show-suggestion)
    (keymap-set map "f" #'gptel-fn-complete)
    (keymap-set map "." #'xref-find-definitions)
    (keymap-set map "," #'xref-go-back)
    (keymap-set map "/" #'xref-find-references)
    (keymap-set map "RET" #'embark-act)
    map)
  "My key customizations for AI and xref.")

(keymap-global-set "C-c ." my-xref-map)
(keymap-global-set "C-c C-." my-xref-map)
(keymap-global-set "C-x ." my-xref-map)
(keymap-global-set "C-x C-." my-xref-map)

Since these get called somewhat frequently, I like to bind a few adjacent keys to the same thing, in case I miss a keypress or hold down Ctrl for too long.

Completing functions with gptel-fn-complete

Earlier in the year I wrote gptel-fn-complete↗. It uses gptel↗ under the hood, and is helpful for completing entire functions or regions. It makes a reasonable attempt to automatically find the bounds of the function at point, and if you’re using a treesit-compatible mode, it will always succeed at that. This was nice to pair with local AI, since the context sent to the AI did not have to be very large.

Now that the tooling and remote AI models have improved to such a large degree, I find myself using OpenCode almost exclusively instead.

Agentic workflows with OpenCode

I use OpenCode↗ for larger tasks that benefit from an agentic approach, such as exploring codebases, making multi-file changes, or debugging complex issues.

OpenCode runs in the terminal and has access to tools for reading files, searching code, and making edits. I typically run it in a Ghostty↗ terminal rather than inside Emacs; if I change my mind about that, I’d likely pick up agent-shell↗ to manage OpenCode.

One helpful (and perhaps unexpected) side effect of using Magit↗ is that it has an automatically activated major mode named magit-auto-revert-mode that automatically turns on auto-revert-mode when an open Emacs buffer is tracked using Git.

In practice this means that if OpenCode is making changes, Emacs will pick those up and refresh the buffer contents automatically. This ends up being a great workflow for me, since I can review in Emacs what the AI model did, without having to bring in any specialized Emacs modes to help. I especially don’t want to review diffs in any tool other than Magit.

Wrapping up

This three-layer approach covers my AI needs well:

minuet for seamless inline completions while typing
gptel-fn-complete for quick, targeted code actions at point
OpenCode for almost every kind of other task

In case any of the above doesn’t work as-is (which is quite possible), it may also be helpful to refer to my shared Emacs settings↗ repo.

Automatic Arrow Characters in Emacs

Mike Olson — Sun, 23 Nov 2025 00:00:00 GMT

Intro
Quail Setup
Markdown Mode Activation
Handling Indirect Buffers
Why Not Use Abbrevs?
- Alternative: abbrev-mode
- Alternative: auto-activating-snippets

Intro

While adding technical writing to my new website↗ using Emacs, I realized I was used to working with software that automatically converted the character - followed by > to the Unicode arrow character →. I decided to add the same behavior to my Emacs setup, and I’d like to describe how I did it.

Emacs has a library called quail that allows defining custom character mappings. If the left side of the mapping has multiple characters, and you type them consecutively, Emacs replaces them with the right side.

Quail Setup

(quail-define-package
 "Arrows" "UTF-8" "→" nil
 "Arrow input mode"
 nil t t nil nil nil nil nil nil nil t)

(quail-define-rules
 ("->" ?→))

This creates a new input method called “Arrows” that converts -> to → as you type. I have to caveat that the arguments to quail-define-package are a bit unergonomic, and having quail-define-rules not refer to the “Arrows” method explicitly is a bit odd (it applies its rules to the most recently defined quail input method/package), but it gets the job done.

Markdown Mode Activation

To use this input method specifically in Markdown mode, I have the following:

(defun my-turn-on-arrow-input ()
  "Turn on arrow input mode."
  (interactive)
  (set-input-method 'Arrows))

(add-hook 'markdown-mode-hook #'my-turn-on-arrow-input t)

Handling Indirect Buffers

The above is already enough to accomplish what’s needed, but I’ll explain one other edge case that I cover for Markdown specifically.

I use (setopt markdown-fontify-code-blocks-natively t) to fontify code blocks within Markdown buffers using their native major modes. Previously I used poly-markdown-mode for that, but the built-in markdown-mode approach seems more robust lately.

One precaution that I ported over from polymode is the ability to exclude certain hooks from running in the indirect buffers associated with those code blocks, in case they cause slowdowns or problems. I’ll present those here:

(defun my-in-indirect-md-buffer-p ()
  "Return non-nil if the current buffer is an indirect buffer created from a Markdown buffer."
  (when-let* ((buf (buffer-base-buffer)))
    (and (buffer-live-p buf)
         (with-current-buffer buf
           (derived-mode-p 'markdown-mode)))))

(defun my-inhibit-in-indirect-md-buffers (orig-fun &rest args)
  "Don't run ORIG-FUN (with ARGS) in indirect markdown buffers.
Use this to advise functions that could be problematic."
  (unless (my-in-indirect-md-buffer-p)
    (apply orig-fun args)))

(defun my-around-advice (fun advice)
  "Apply around ADVICE to FUN.
If FUN is a list, apply ADVICE to each element of it."
  (cond ((listp fun)
         (dolist (el fun) (my-around-advice el advice)))
        ((and (symbolp fun)
              (not (advice-member-p advice fun)))
         (advice-add fun :around advice))))

I then ensure that the Arrows input method only activates in the main Markdown buffers, not indirect ones:

(my-around-advice #'my-turn-on-arrow-input
                  #'my-inhibit-in-indirect-md-buffers)

This implementation, along with quite a few other customizations, is also available in my shared .emacs setup↗.

Some inspiration was taken from this Mastering Emacs post↗ which describes how to make your own emoji input method with Quail.

Why Not Use Abbrevs?

After publishing this post, someone suggested using a local abbrev instead, which would remove the need to inhibit activation in non-Markdown buffers. This seemed like a reasonable alternative, so I investigated.

Alternative: abbrev-mode

It turns out that abbrevs aren’t quite as ergonomic for this use case. The reason comes down to how Emacs categorizes characters into syntax classes↗. Abbrevs expand when you type a non-word-constituent character after a sequence of word-constituent characters. The problem is that - is typically a punctuation character in most modes, not a word constituent. This means:

You can’t define an abbrev -> that works normally, because - itself would trigger expansion of whatever word came before it.
To make abbrevs work, you’d need to either modify the syntax table to make - and > word constituents, or implement a custom abbrev-expand-function to handle symbol syntax.

If you wanted to pursue the abbrev approach anyway, here’s a working example that modifies the syntax table:

(define-abbrev gfm-mode-abbrev-table "->" "→")

(defun my-markdown-abbrev-setup ()
  "Make `-' and `>' word constituents so that `->` abbrev works."
  (modify-syntax-entry ?- "w")
  (modify-syntax-entry ?> "w")
  (abbrev-mode 1))

(add-hook 'markdown-mode-hook #'my-markdown-abbrev-setup)

Note: the gfm-mode-abbrev-table is specific to gfm-mode. If you use plain markdown-mode, substitute markdown-mode-abbrev-table instead.

However, this approach has several trade-offs compared to Quail:

Changing the syntax class of - and > affects word motion commands (M-f, M-b), so foo-bar would now be treated as a single word rather than two.
You must type a space (or other non-word character) after -> to trigger expansion, rather than having it expand immediately as you type.
There’s no visual feedback while typing. Quail highlights the first character when a potential expansion is in progress, but abbrev-mode has no equivalent preview feature.

The Quail input method approach avoids these trade-offs. It operates at a different level, matching literal character sequences regardless of syntax class, and expands immediately as you type - which matches the Notion-like behavior I was after.

Alternative: auto-activating-snippets

If you’d prefer a package-based solution that behaves more like Quail, auto-activating-snippets↗ (available on MELPA as aas) expands snippets as you type without requiring a trigger key.

This gives you immediate expansion like Quail, without syntax table modifications. The main difference from Quail is that aas doesn’t provide visual feedback during typing - you won’t see highlighting on the first character when an expansion is possible.

Also at the time of this writing, it hasn’t been updated since 2023-03-03 and may have byte-compilation warnings.

gptel-manual-complete: AI function completion in Emacs

Mike Olson — Mon, 19 May 2025 00:00:00 GMT

This is an example of how the existing gptel-rewrite.el file can be used to perform completion on an entire function, replacing what’s already written so far in that function.

Setup

To use:

Install gptel↗, configure it, and provide the appropriate API keys
Install gptel-fn-complete↗

Now choose which key you’d like to bind it to. I typically add something like this to my Emacs config:

(defvar my-xref-map
  (let ((map (make-sparse-keymap)))
    (define-key map (kbd "c") #'gptel-manual-complete)
    (define-key map (kbd ".") #'xref-find-definitions)
    (define-key map (kbd ",") #'xref-go-back)
    (define-key map (kbd "/") #'xref-find-references)
    map)
  "My key customizations for AI and xref.")

(global-set-key (kbd "C-c .") my-xref-map)

Restart Emacs

Usage

If you’ve used the above keybinds, they work like this (the only with AI is the first one):

C-c . c to complete the code at point using Claude AI; if you have a comment near the end, that will better inform the completion
C-c . . to visit the definition of the thing at point
C-c . , to return to the original point after visiting something
C-c . / to find references to the thing at point

Example

When I write this code in a sample.el file:

(defun my-code ()
  "AI should not modify this."
  (message "Sample 1"))

(defun my-say-hello
;; print a welcoming message in a window off to the right
)

(defun my-other-code ()
  "AI should not modify this either."
  (message "Sample 2"))

Move the cursor into the body of my-hello and hit C-c . c then gptel will rewrite that my-hello function to something like this, without touching the other functions or deleting lines around it (results may vary, I used Claude 3.5 Sonnet in this example):

(defun my-hello ()
  "Print a welcoming message in a window off to the right."
  (let ((buf (get-buffer-create "*Hello*")))
    (with-current-buffer buf
      (erase-buffer)
      (insert "Welcome to Emacs!\n\nHave a productive session."))
    (display-buffer buf
                    '((display-buffer-reuse-window
                       display-buffer-in-side-window)
                      (side . right)
                      (window-width . 40)))))

From here, you can use the standard gptel-rewrite keys like C-c C-a on that code to accept it and remove the overlay on it.

Note that the function must have balanced parentheses, otherwise the code will throw an error. This is to make it easier to locate the beginning and end of the function to send to gptel’s context.

Inspiration

After adding a function to gptel’s context, I was using gptel-rewrite and accidentally hit Enter twice. This resulted in just the basic “Rewrite: ” text being sent, and to my surprise that was very effective at having Claude fix the problem I was going to ask about.

I decided to see if Claude could also do code completions this way, with a very terse kind of prompt on top of the standard gptel-rewrite prompt, and it turns out that it can!

Notes

For automatically identifying the entire current function to complete, you may have the best luck with either Emacs Lisp or files with major modes that have a tree-sitter grammar installed, as otherwise we have to guess. In general it should err on the side of sending too little rather than too much.
My Emacs setup is available at https://github.com/mwolson/emacs-shared↗ which has this and other features
- Note that the install doc might take a while to get through, and may have opinionated settings
- The additional AI features which have more bindings on C-c . than in the above example are described here↗

Mike Olson - Emacs Blog Posts

Fixing typescript-ts-mode in Emacs 30.2

Contents

The Symptom

The Root Cause

The Approach

How to Use It

Caveats

Removal Plan

eglot-python-preset and eglot-typescript-preset: Now on MELPA

Contents

Introduction

What Changed

Installation

Python

TypeScript

Out-of-the-Box Multi-LSP

Per-Project Configuration

Links

Beta: Emacs Multi-LSP support for Python and Typescript frameworks

Contents

Introduction

Why rass?

Python: ty + Ruff in One Buffer

TypeScript: Multi-Framework LSP Support

Astro + ESLint + oxlint

Supported Frameworks

Per-Project Configuration

In-repo: .dir-locals.el

Out-of-repo: dir-locals-set-directory-class

Installation

Feedback Welcome

Links

First Week with Jujutsu VCS

Contents

Configuring Immutable Bookmarks

Emacs Integration with Majutsu

Rebasing Stacked Branches

Cleaning Up After Rebases

Magit and jj - Conflict Resolution

Magit and jj - ’@’ Branch

Overall Impressions

Announcing eglot-python-preset

Contents

Introduction

What eglot-python-preset Does

Basic Setup

Key Commands

Future Directions

Links

ty: A Fast Python Type Checker and LSP for Emacs

Contents

Introduction

Setting Up ty with Eglot

The Multi-LSP Question

How Other Editors Handle This

Eglot’s Approach

Aside - Is an External Multiplexer Needed?

Current Status

My Emacs AI Setup

Inline completions with minuet

Basic configuration

Blocking some suggestions within buffers

Enabling Minuet at file-level

Provider configuration

Keybinds

Completing functions with gptel-fn-complete

Agentic workflows with OpenCode

Wrapping up

Automatic Arrow Characters in Emacs

Contents

Intro

Quail Setup

Markdown Mode Activation

Handling Indirect Buffers

Why Not Use Abbrevs?

Alternative: abbrev-mode

Alternative: auto-activating-snippets

gptel-manual-complete: AI function completion in Emacs

Setup

In-repo: `.dir-locals.el`

Out-of-repo: `dir-locals-set-directory-class`