Mike Olson - Blog Posts

Fixing HDMI Audio After Suspend on Linux

Mike Olson — Tue, 17 Feb 2026 00:00:00 GMT

The Problem
Why Kernel Fixes Haven’t Stuck
The Other Power Problem: Idle Suspend
The Workaround: Profile Cycling
Automating It
Installation
Options
Links

The Problem

If you use HDMI or DisplayPort audio on a Linux desktop, you’ve probably hit this: you suspend your machine, wake it up, and your audio is gone. The HDMI output shows up as disconnected or silent. The most reliable fix is to open your audio settings and manually toggle the card profile off and back on.

This has been a persistent issue for years. It affects AMD and Intel GPUs across multiple kernel versions and desktop environments. The root cause is that when the system resumes, the kernel re-initializes the GPU but the HDMI audio codec doesn’t always come back cleanly. WirePlumber ends up holding references to stale audio nodes that no longer work.

Why Kernel Fixes Haven’t Stuck

There have been multiple attempts to fix this at the kernel level. In Linux 6.11, a patch was merged that conditionally disabled ALSA snooping for AMD HDMI↗ hardware when IOMMU wasn’t in play. The idea was to work around DMA coherency issues that caused crackling, dropouts, and post-suspend silence.

That patch was reverted↗ because it broke audio on other hardware configurations. The same pattern has repeated several times: a fix goes in, it helps some systems, it causes regressions on others, and it gets pulled. The Arch Linux forums have extensive threads documenting this cycle, including this one on ELD info being empty after resume↗.

The fundamental issue is that HDMI audio depends on a coordination chain between the GPU driver, the HDA controller, the ALSA layer, and the user-space audio server. Suspend/resume interrupts that chain, and rebuilding it reliably across all hardware combinations has proven difficult.

The Other Power Problem: Idle Suspend

System suspend isn’t the only power-related audio issue on Linux. PipeWire’s WirePlumber also suspends audio nodes after a few seconds of silence to save power. On paper this saves about 100mW on mobile devices, but on desktops it causes two problems: an audible pop when audio starts, and a constant hum on connected amplifiers because the unpowered output leaves the line floating, picking up electrical noise.

A popular r/linux thread↗ in December 2025 highlighted how frustrating this is. The configuration has changed across PulseAudio, WirePlumber 0.4 (Lua), and WirePlumber 0.5+ (SPA JSON), so most solutions you find online are outdated. The current fix is a WirePlumber config drop-in:

# ~/.config/wireplumber/wireplumber.conf.d/50-no-suspend.conf
monitor.alsa.rules = [
  {
    matches = [
      {
        node.name = "~alsa_output.*"
      }
    ]
    actions = {
      update-props = {
        session.suspend-timeout-seconds = 86400
      }
    }
  }
]

One interesting detail from that thread: setting the timeout to 0 disables suspend entirely, but this breaks audio device sharing on multi-user systems. Setting it to a high value like 86400 (one day) avoids both the pop/hum and the multi-user issue.

For HDMI specifically, I hit both problems: the idle suspend pop between tracks, and complete audio loss after system suspend. The WirePlumber config above handles the idle suspend pop; audio-profile-manager handles the post-suspend audio loss.

The Workaround: Profile Cycling

The manual fix that always works is cycling the PipeWire/PulseAudio card profile off and back on. This forces a full teardown of the audio nodes and rebuilds them from scratch against the current hardware state:

pactl set-card-profile alsa_card.pci-0000_01_00.1 off
sleep 1
pactl set-card-profile alsa_card.pci-0000_01_00.1 pro-audio

The specific profile name varies by system — pro-audio is common for HDMI cards on PipeWire, but yours might be different.

Automating It

I wrote audio-profile-manager↗ to automate this. It’s a bash script that monitors D-Bus for systemd-logind’s PrepareForSleep signal and runs the profile cycle automatically on wake.

The core of it is a dbus-monitor loop that watches for resume events:

dbus-monitor --system --monitor \
  "interface=org.freedesktop.login1.Manager,member=PrepareForSleep" \
  | while read -r line; do
    # On wake (boolean false), wait for HDMI renegotiation, then cycle profile
done

On startup it auto-detects both the HDMI audio card and the active profile, so it knows what to restore to after cycling. Both can be overridden with --card and --profile if needed. Then it sits in the background waiting for suspend/resume events.

Installation

The repo includes a systemd user service and an install script:

git clone https://github.com/mwolson/audio-profile-manager.git
cd audio-profile-manager
./install.sh
systemctl --user start audio-profile-manager.service

This installs the script to ~/.local/bin/ and enables the systemd user service (the install script handles systemctl --user enable for you). It uses graphical-session.target, which is desktop-agnostic — it works with KDE, GNOME, COSMIC, and any other desktop that properly integrates with systemd.

You can verify it’s working by checking the journal before and after a suspend cycle:

journalctl --user -u audio-profile-manager.service -f

You should see log lines like:

Waking from sleep, waiting 3s for HDMI to renegotiate...
Cycling profile on alsa_card.pci-0000_01_00.1: pro-audio -> off -> pro-audio
Profile restored to pro-audio.

Options

The defaults work for most HDMI setups, but you can customize:

--card CARD_NAME to target a specific audio card
--profile PROFILE to override the target profile (default: auto-detected)
--wake-delay SECONDS to adjust the post-wake delay (default: 3 seconds)

Find your card name with pactl list cards short.

Markdown for Agents on the Cloudflare Free Plan

Mike Olson — Sat, 14 Feb 2026 00:00:00 GMT

In February 2026, Cloudflare announced Markdown for Agents↗, a feature that automatically converts HTML pages to Markdown when AI agents request it via Accept: text/markdown. It’s a great idea, but it requires a Pro plan or higher. And even if you have one, the edge conversion includes your navigation chrome, footers, and other layout elements that aren’t useful to an agent.

If you author content in Markdown already (as most static site generators do), you can serve curated Markdown directly from your origin and get better results. Here’s how I set this up for my Astro site behind Cloudflare’s free plan, including a caching trick that took some digging to figure out.

The Idea
Build: Generating Markdown
Serve: Caddy Content Negotiation
Cache: The Cloudflare Free Plan Problem
The Fix: Transform Rules
Results
Trade-offs vs. Edge Conversion
What’s Next

The Idea

AI coding tools like Claude Code and OpenCode already send Accept: text/markdown when fetching URLs. The Markdown for Agents spec↗ defines the protocol: the client sends an Accept header, and the server responds with clean Markdown plus a Content-Signal header indicating how the content may be used.

Since my blog posts and guides are authored in MDX, the source Markdown is already available at build time. Rather than converting HTML back to Markdown at the CDN edge, I can generate purpose-built Markdown files during the Astro build and serve them from the origin when an agent asks for them.

Build: Generating Markdown

During astro build, a post-build script walks the content collections (blog posts and guides), strips MDX-specific syntax like JSX components and import statements, and writes clean Markdown files to a dist-md/ directory that mirrors the URL structure of the HTML site.

Each generated file gets proper YAML frontmatter with the title, publication date, and description, followed by the content body. For index pages (the blog listing, guide listing, homepage), I maintain template files with an  marker that gets replaced with a sorted, linked listing of entries during generation.

The result is two parallel directory trees in the build output:

dist/ — the regular HTML site
dist-md/ — Markdown variants for agents

Serve: Caddy Content Negotiation

Both directories are served from the same container. Caddy handles the content negotiation with a named matcher that checks for Accept: text/markdown and verifies a Markdown file exists for the requested path:

@wantsMarkdown {
    header Accept *text/markdown*
    file {
        root /srv/site/dist-md
        try_files {path}index.md {path}/index.md
    }
}
handle @wantsMarkdown {
    root * /srv/site/dist-md
    header Content-Type "text/markdown; charset=utf-8"
    header Content-Signal "ai-input=yes, search=yes"
    header Cache-Control "public, max-age=3600, s-maxage=86400"
    header Vary Accept
    rewrite {file_match.relative}
    file_server
}

If no Markdown file exists for a given path, the file matcher fails and the request falls through to the default HTML handler. This means agents get Markdown for content pages and HTML for everything else, with no 404s or broken behavior.

You can test it with curl:

# HTML (default)
curl -sI https://mwolson.org/blog/

# Markdown
curl -sI -H 'Accept: text/markdown' https://mwolson.org/blog/

Cache: The Cloudflare Free Plan Problem

This is where it gets interesting. Caddy sends Vary: Accept on Markdown responses, which should tell any standards-compliant cache to store separate variants keyed on the Accept header. Cloudflare’s free plan doesn’t do this. It caches a single variant per URL regardless of Vary.

The practical consequence: if an HTML response gets cached first, subsequent Markdown requests return the cached HTML. If a Markdown response gets cached first, regular browsers get Markdown. Neither is acceptable.

My first workaround was setting s-maxage=0 on Markdown responses to prevent Cloudflare from caching them. This solved the correctness issue but meant every Markdown request hit the origin, defeating the point of having a CDN.

The Fix: Transform Rules

The solution uses Cloudflare’s Transform Rules↗, which are available on the free plan (up to 10 rules). Transform Rules run at phase 3 in Cloudflare’s request pipeline, well before cache lookup at phase 19.

The rule appends a query parameter to requests that include Accept: text/markdown, which gives them a different cache key from regular HTML requests:

Rule name: Markdown for Agents cache key
Filter expression: any(http.request.headers["accept"][*] contains "text/markdown")
Query rewrite (static): _fmt=md

With this rule active, a request to /blog/ with Accept: text/markdown becomes /blog/?_fmt=md internally before cache lookup. Cloudflare now stores two cache entries: one for the HTML variant and one for the Markdown variant. The origin may see the ?_fmt=md query parameter, but Caddy matches on the Accept header as before, so no origin changes are needed.

Once I confirmed this was working, I raised s-maxage on Markdown responses to match the HTML caching policy. Both variants are now edge-cached with a 1-day TTL.

Results

After deploying and purging the Cloudflare cache, both variants cache independently:

# First HTML request
content-type: text/html; charset=utf-8
cf-cache-status: MISS

# Second HTML request
content-type: text/html; charset=utf-8
cf-cache-status: HIT

# First Markdown request
content-type: text/markdown; charset=utf-8
cf-cache-status: MISS

# Second Markdown request
content-type: text/markdown; charset=utf-8
cf-cache-status: HIT

The Markdown responses include Content-Signal: ai-input=yes, search=yes as specified by the Markdown for Agents protocol, and the content is clean Markdown without navigation elements, script tags, or layout chrome.

Trade-offs vs. Edge Conversion

There are real trade-offs to the origin approach compared to Cloudflare’s edge conversion:

You have to maintain a build step that generates the Markdown files. If your content changes frequently or comes from a CMS, this adds complexity.
You need to handle content negotiation at the origin (Caddy, NGINX, or similar).
The free plan Transform Rule trick uses one of your 10 available rules.

On the other hand:

You control exactly what the Markdown output looks like. No navigation chrome, no footer links, no cookie banners converted to Markdown.
The Markdown can include proper YAML frontmatter with structured metadata that agents can parse.
It works on any Cloudflare plan, including free.
For static sites where the content is already in Markdown, the build step is straightforward.

What’s Next

I might extract the build script into a reusable Astro integration so that other Astro sites can add origin-level Markdown for Agents support without writing custom build scripts. If I do, that will be the subject of a future post.

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.

Managing AI Like You Manage People

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

With the release of Claude Opus 4.5 (and the pace of improvement in frontier models), we’ve reached the point where AI coding assistants can handle tasks that would previously require a team of skilled developers. The capabilities are impressive enough that drawing parallels between managing AI agents and managing human teams feels less like a thought experiment and more like practical advice.

As someone who has spent years in engineering management and who has more recently been working extensively with AI coding tools, I’ve noticed that the skills transfer remarkably well in both directions. Here are some patterns that work for both.

Documentation as Team Knowledge
Continuous Improvement Through Retrospectives
Automated Guardrails and the Dev Loop
Technical Specifications and Writing Things Down
Context Management as Cognitive Load Reduction
Mental Flexibility and Decision-Making
Looking Forward

Documentation as Team Knowledge

The most effective engineering teams I’ve managed have had copious (but targeted) documentation: onboarding guides, coding standards, architecture decision records (ADRs). For AI agents, this manifests as AGENTS.md files that live in your repository.

The parallels are striking:

Onboarding docs tell new team members how the codebase works, what conventions to follow, and where to find things. AGENTS.md serves the exact same purpose for AI agents. Since AI agents otherwise start each coding session with a nearly blank slate about your codebase, it can’t be overstated how helpful this is.
Style guides ensure consistency across human contributors. For AI, you specify formatting preferences, naming conventions, and patterns to follow or avoid.
What we call tribal knowledge often lives in people’s heads and gets shared through pairing or code review. Writing it down in AGENTS.md makes it accessible to AI agents too.
Meeting notes help humans have more efficient meetings with less repeated discussion of settled topics. They’re equally valuable for AI agents, providing clarity on what the “North Star” is for projects being worked on, and highlighting areas of most recent concern.

Just as you wouldn’t expect a new hire to be productive without proper documentation, you can’t expect an AI agent to work effectively without clear instructions about your codebase’s conventions and constraints.

Continuous Improvement Through Retrospectives

Good teams run retrospectives. They ask: What worked? What didn’t? What should we change? The output often becomes updated process documentation or new team agreements.

With AI agents, the same cycle applies:

You notice the AI making a repeated mistake or missing context
You update AGENTS.md with clearer instructions
Future sessions benefit from that improvement

This creates a virtuous cycle where your AI instructions get better over time, much like how team processes improve through regular retrospectives. I’ve found myself treating AGENTS.md updates as a form of “retro action item” after most AI coding sessions, and agents are capable of enough reflection to propose those updates themselves when asked to do so.

The key insight is that both processes require intentional reflection. You have to actually notice what’s not working and take the time to document the fix rather than just working around it each time.

Automated Guardrails and the Dev Loop

One of the most effective ways to improve any team’s velocity is to automate the boring stuff: linting, formatting, type checking, test running. These tools catch issues before code review, reducing back-and-forth and cognitive load.

For AI agents, these same tools provide even more value:

Auto-formatting (Oxfmt, Biome, Prettier) means the AI doesn’t need to worry about code style, and neither do you when reviewing its output
Linting (Oxlint, Biome, ESLint) catches common mistakes that might otherwise require a conversation round-trip to fix
Type checking ensures the AI’s code actually compiles and integrates correctly
Running unit tests provides immediate feedback on whether changes broke existing functionality

Each automated check that catches an issue is one fewer back-and-forth cycle with the AI. Since AI interactions have latency costs (and sometimes token costs), this directly translates to faster iteration.

The Dev Loop: Autonomous Iteration

What makes these guardrails truly powerful is when they enable what’s sometimes called the “dev loop” or “closed-loop development”: an autonomous cycle where the AI can write code, run validation, diagnose failures, fix issues, and retry without human intervention between iterations.

Consider a typical workflow without a dev loop: you ask the AI to implement a feature. It writes code. You run the tests. They fail. You paste the error back. The AI proposes a fix. You run the tests again. Still failing. More back-and-forth. Each iteration requires you to be present, running commands, copying output, and providing feedback.

With a well-configured dev loop, the AI can execute that entire cycle autonomously. It writes code, runs bun run check, sees type errors, fixes them, runs again, sees test failures, reads the test output, adjusts the implementation, runs once more, and finally succeeds, all without waiting for you.

This is transformative for longer tasks. An AI agent can iterate dozens of times in the span of minutes, exploring approaches, hitting dead ends, backtracking, and eventually converging on a solution. Without the dev loop, each of those iterations would require your attention.

The Human Parallel: Ways of Work

Teams have their own version of this: established “ways of work” that let engineers operate autonomously within known boundaries. A senior engineer doesn’t need to ask permission for every decision. They know the coding standards, understand the testing requirements, and can iterate independently until they have something worth reviewing.

Good team process creates the same kind of autonomous loop:

Engineer picks up a task
They implement, test locally, and refine
CI runs automated checks
If checks fail, they fix and retry
When everything passes, they open a PR for review

The human isn’t blocked waiting for feedback at every step. They have the tools and knowledge to iterate independently. The same principle applies to AI agents: give them the guardrails and validation tools to iterate autonomously, and they’ll be dramatically more effective.

I’ve noticed that projects with strong automated guardrails tend to have much smoother AI-assisted development. The AI can focus on the actual problem rather than getting tripped up by style inconsistencies or type errors, and it can self-correct when the tools tell it something’s wrong.

A Note on Code Review and Desk Checks

There’s more to say here that I may expand on in a future post, but briefly: code review remains the final guardrail for both human and AI-generated code. Automated checks catch many problems, but the judgment of a human (potentially augmented by a different AI model with enough iterations) is still essential for evaluating design decisions, identifying subtle bugs, and ensuring the code actually solves the right problem.

Similarly, the traditional “desk check” (where you manually walk through scenarios before calling something done) has an AI parallel. Describing integration scenarios or one-off test cases in markdown can be surprisingly effective. Sometimes this works better than reaching for a prescriptive automation framework like Playwright, especially for exploratory validation or scenarios that don’t justify the overhead of formal test automation.

Technical Specifications and Writing Things Down

There’s a reason senior engineers emphasize writing technical specs before diving into implementation. The act of writing clarifies thinking, surfaces edge cases, and creates a shared understanding of what’s being built.

I do have to caveat that there’s certainly a time and a place to do exploratory work with minimal documentation. But if that work turns into a more established product, then it absolutely starts to be worth the time to create documentation.

This applies doubly when working with AI:

API schemas (OpenAPI, GraphQL schemas, TypeScript types) give the AI precise contracts to work with
Technical specs help the AI understand not just what to build, but why, and what constraints exist
Having architecture diagrams and/or explanations provides context that might otherwise require extensive codebase exploration

When I give an AI agent a well-defined spec, the results are dramatically better than when I give vague instructions. This mirrors my experience with human teams: clear requirements lead to better outcomes, and the discipline of writing them down forces you to think through the problem properly.

While AI certainly can reproduce some of this knowledge on demand, it’s very important to keep in mind that usable (and useful) context sizes are currently quite small. As such, concise and informative docs are very imporant to help increase the amount of useful work that can be completed before running out of context.

Context Management as Cognitive Load Reduction

Good managers protect their teams from unnecessary distractions. They filter information, provide relevant context, and shield the team from organizational noise that would reduce focus.

With AI agents, context management is even more critical:

Trimming context to relevant files and information improves response quality and reduces costs
Focused problem statements rather than dumping entire codebases lead to better solutions
Large tasks should be broken into smaller chunks to prevent the AI from getting overwhelmed (and prevents you from getting overwhelmed reviewing massive changes), and allows for better continuity when AI context limits are reached and you have to start a new session or undergo compaction for the current one
Offloading longer AGENTS.md sections into separate runbooks can help keep baseline context short; with an explicit instruction to consult those runbooks when needed, the AI can still solve situational problems (like working on a particular submodule) effectively

Just as you wouldn’t CC your entire team on every email thread, you shouldn’t feed your AI agent every file in your repository. Curate the context thoughtfully.

Mental Flexibility and Decision-Making

Effective managers balance openness to new information with the ability to make decisions and move forward. They’re willing to be proven wrong but don’t endlessly waffle. They examine data, consider options, and then commit to a direction.

Working with AI requires the same disposition:

Be exploratory: The AI might suggest approaches you hadn’t considered. Sometimes they’re better than your original plan.
Be willing to be proven wrong: Your initial assumptions about the problem might be incorrect. Let the AI’s analysis (especially when validated with follow-up questions) inform your understanding.
But still make calls: At some point you need to decide whether to accept the AI’s suggestion, modify it, or reject it. Don’t get stuck in endless iteration.

As they used to say at one of my previous jobs, the sweet spot is confident humility: strong opinions, weakly held.

Looking Forward

We’re at an interesting inflection point. The management practices that work well for human teams are proving to be directly applicable to AI workflows. This suggests that as AI capabilities continue to improve, the skills gap between “good at managing people” and “good at working with AI” will continue to narrow.

It also suggests that investing in these foundational practices pays double dividends: they make your human team more effective today, and they prepare you for increasingly AI-augmented workflows tomorrow.

The engineers and managers who thrive will likely be those who recognize that clear communication, good documentation, automated guardrails, and thoughtful context management aren’t just soft skills or process overhead. They’re the infrastructure that makes both human and artificial intelligence work better.

New CachyOS Guides for Gaming and Server Setup

Mike Olson — Sat, 03 Jan 2026 00:00:00 GMT

I’ve published two new guides for CachyOS↗, the performance-focused Arch Linux distribution that I’ve been using for over a year now on both desktop and server workloads.

CachyOS Gaming Quick Start

The CachyOS Gaming Quick Start guide covers everything you need to get a gaming-ready CachyOS installation up and running. It includes:

Installation and dual-boot setup with Windows, including tips for avoiding sleep issues with the Windows Fast Startup feature
Post-installation configuration covering the CachyOS Hello welcome app, Ghostty as a terminal, and KDE Plasma desktop tweaks
Using Paru for package management, including how to find and install packages from the official repos and the AUR
Gaming-specific optimizations for sound latency (pipewire with realtime-privileges), process priorities, and keyboard bindings that won’t interrupt gameplay
Game setup instructions for WoW (via Lutris with proton-cachyos-slr) and FFXIV (via xivlauncher-rb), including DPI scaling tips for 4k monitors
Companion app installation for CurseForge, Warcraft Logs Uploader, WowUp, and Discord

CachyOS Server Setup Guide

The CachyOS Server Setup Guide walks through setting up a secure CachyOS server from scratch, targeting Hetzner dedicated servers but applicable to other VPS providers with minor adjustments. It covers:

Why CachyOS for servers - the linux-cachyos-server kernel variant with 300Hz tickrate, no preemption, and optimized package repositories compiled for modern CPU architectures (x86-64-v3, x86-64-v4, Zen4)
Installation from an Arch ISO since CachyOS doesn’t yet have a dedicated server edition, including both direct ISO boot and rescue system bootstrap methods
Using btrfs with subvolumes matching the CachyOS desktop installer layout for Timeshift snapshot compatibility
SSH key-based authentication with passwords disabled for security hygiene
Network configuration for both IPv4 and IPv6, with Hetzner-specific instructions and notes for other providers
UFW firewall setup for controlling incoming connections and avoiding open-port surprises when package upgrades are done

Both guides reflect my actual configurations and workflows, and are a fairly complete and low-friction way to get started with CachyOS in gaming and server settings.

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.

Improving Performance by Reducing API Data Size

Mike Olson — Fri, 28 Nov 2025 00:00:00 GMT

In a recent consulting engagement, I worked on improving performance for a ticketing e-commerce website. This is the first of a series of posts about what helped. I’ll discuss what led to the decision to reduce data size, the degree to which that change helped, and other adjacent ideas like Backend-for-Frontend (BFF).

Diagnosis
Solution
Opportunity: BFF Endpoints
Conclusion
What’s Next

Diagnosis

One of the first things I did to diagnose the website’s performance was to use Chrome DevTools to observe a page load with the Network tab open. I noticed that one particular API call took 5+ seconds, with the page being blocked from a contentful paint until that call completed. The API included multiple megabytes of content for one month of an ongoing event series - for example: river cruises and museum tours.

Because the payload was so large, the browser was forced to tie up the main thread while parsing JSON, causing “micro-stutters” where the UI could briefly look like it’s frozen and not respond to user input. This is especially noticeable on underpowered devices such as kiosks.

Further, there’s an interesting performance opportunity that happens when you can fit the payload size in under 14–15kB↗ that can significantly help page load and API performance, due to the implementation details of the TCP slow start algorithm. Without getting into too much technical detail, this happens because the initial TCP congestion window (and the convention for the number of TCP packets that a server will send at one time) limits how much data can be sent in the first round trip.

In practice, staying under this window can often make the first response arrive up to roughly twice as fast compared to slightly larger payloads. Missing the ~14kB window by even 1kB can increase the response time of that network call by 600ms or more, especially on higher-latency connections. Relatedly, for webpage content that can’t be made that small, it can be helpful to stream in meaningful “above-the-fold” content within the first 14kB, focusing on what is most important for the user to see when they visit your website. This can include headers, titles, and key CSS styling.

Solution

Returning to the earlier example: since we control both the frontend and the backend code, and the product requirements only necessitate showing the complete details of one day at a time, it made sense to provide different API calls where we segmented the data based on the part that applied to each day, with the YYYY-MM-DD date value being part of the path of the new API calls. Requesting these only took around 900ms, which significantly sped up the page load.

In general, the split point doesn’t necessarily have to be by date - other criteria could make sense depending on the use case. Reducing data might even require multiple split points, in which case the API path could be modified to include both of those (either in clear text or hashed form).

Opportunity: BFF Endpoints

One architectural idea that biases toward implementing these ideas is Backend-for-Frontend (BFF). A Backend-for-Frontend is a backend whose only consumer is a single frontend product. It sits between the client and other backend services, and is expected to be developed alongside the frontend. Ideally, the BFF and the frontend are even developed within the same monorepo, where a single pull request can span changes to both.

This pattern can be especially helpful when there are dependencies between different individual existing backend API calls. Rather than waiting for one API to complete in the frontend before making the next, bundle all that into one combined BFF API call that will return all of the needed attributes and/or related entities instead of just IDs.

One can imagine a progression where gradual improvements are made to the existing architecture.

As a first step, implement a single BFF API call for the data needed on the page, or perhaps for one section of a complex page. Within that API, include each kind of data as a top-level (or nearly top-level) payload, ideally scoping that data appropriately to keep API response payload size under control.

Remember: Don’t worry about having perfect levels of abstraction, as the only consumer of this call is the frontend.
Later, implement other optimizations.
- Potentially allow the BFF to automatically render HTML server-side for the part of the page that it controls instead of returning JSON response payloads, leveraging tools like Next.js↗, TanStack Start↗, and React Compiler↗.
- For the backend APIs that the BFF calls, potentially adjust these to provide smaller data payloads and/or more ways to filter response data using query parameters or POST parameters.
- Potentially allow the BFF to have a bit more direct access to the data sources to skip a few layers, as long as rate limits and other controls are properly implemented.

Conclusion

APIs that are designed for general consumption by any kind of frontend or backend provide helpful flexibility, but they can lead to poor webpage performance without further data segmentation. When your API calls start dragging past the 1-second mark, look at the payload size. Are you sending the entire history when the page only needs a smaller subset?

A BFF can be an interesting further idea that allows treating your API payload as part of the UI design. By restricting data to the current context (specific dates, active items, or relevant categories), your application can, as a general rule, remain performant and flexible.

What’s Next

Our segmented API calls in this example now take 900ms each instead of 5+ seconds. But there’s more to be done.

What can be done to reduce that 900ms even further?
What can cause temporary mysterious latency spikes of 10+ seconds?
And what if users in other regions are noticing slowdowns that seem much worse than what the primary region experiences?

Stay tuned to future blog posts in this series for answers to those questions.

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.

Ghostty + tmux uniform copy and paste

Mike Olson — Tue, 11 Nov 2025 00:00:00 GMT

This set of configuration changes achieves the following:

Disable automatic copying to clipboard while using the mouse to select text. Instead, the selection is copied when the user types either Ctrl+Shift+c or Super+c (on macOS only) after using the mouse to select text.
The Super+c keybinding works by remapping it to Ctrl+Shift+c in ghostty.
Ghostty will ignore those keybindings so that tmux can handle them. This allows tmux to copy text cleanly even when scrolling through history and using split panes.
Ghostty will still handle pasting with Ctrl+Shift+v or Super+v (on macOS only).
The r key can be pressed while selecting text to toggle rectangular selection on or off.
Clicking outside the selection will clear the selection.
The selection will be displayed as inverse text on both tmux and ghostty for consistency.

Files

ghostty-mac.conf

Apply these changes to ~/.config/ghostty/ghostty.conf if you’re on macOS:

copy-on-select = false
keybind = performable:ctrl+shift+c=copy_to_clipboard
# remap super+c to ctrl+shift+c, use `bash -i -c cat` to see keycodes
# as you type them
keybind = super+c=csi:99;6u
selection-invert-fg-bg = true
shell-integration-features = no-cursor

ghostty-linux.conf

Apply these changes to ~/.config/ghostty/ghostty.conf if you’re on Linux:

copy-on-select = false
keybind = performable:ctrl+shift+c=copy_to_clipboard
selection-invert-fg-bg = true
shell-integration-features = no-cursor

tmux.conf.local

Add these changes to ~/.tmux.conf.local, assuming that you’re using oh-my-tmux↗:

# increase history size
set -g history-limit 10000

# start with mouse mode enabled
set -g mouse on

# don't yank mouse selection on release; instead use alt+w
# or ctrl+shift+c
unbind -T copy-mode MouseDragEnd1Pane
unbind -T copy-mode MouseDown1Pane
bind-key -T root DoubleClick1Pane select-pane -t = \; \
  if-shell -F "#{||:#{pane_in_mode},#{mouse_any_flag}}" { \
    send-keys -M \
  } { \
    copy-mode -H ; \
    send-keys -X select-word \
  }
bind-key -T root TripleClick1Pane select-pane -t = \; \
  if-shell -F "#{||:#{pane_in_mode},#{mouse_any_flag}}" { \
    send-keys -M \
  } { \
    copy-mode -H ; \
    send-keys -X select-line \
  }
bind -T copy-mode MouseDown1Pane select-pane \; send-keys -X clear-selection
bind -T copy-mode DoubleClick1Pane select-pane \; send-keys -X select-word
bind -T copy-mode TripleClick1Pane select-pane \; send-keys -X select-line
bind -T copy-mode C-S-c send-keys -X copy-pipe
bind -T copy-mode R send-keys -X refresh-from-pane
bind -T copy-mode r send-keys -X rectangle-toggle

# selection style
setw -g mode-style "reverse" #!important

Note that the location of .tmux.conf.local might be different depending on how you’ve configured oh-my-tmux.

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 - Blog Posts

Fixing HDMI Audio After Suspend on Linux

Contents

The Problem

Why Kernel Fixes Haven’t Stuck

The Other Power Problem: Idle Suspend

The Workaround: Profile Cycling

Automating It

Installation

Options

Links

Markdown for Agents on the Cloudflare Free Plan

Contents

The Idea

Build: Generating Markdown

Serve: Caddy Content Negotiation

Cache: The Cloudflare Free Plan Problem

The Fix: Transform Rules

Results

Trade-offs vs. Edge Conversion

What’s Next

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

Managing AI Like You Manage People

Contents

Documentation as Team Knowledge

Continuous Improvement Through Retrospectives

Automated Guardrails and the Dev Loop

The Dev Loop: Autonomous Iteration

The Human Parallel: Ways of Work

A Note on Code Review and Desk Checks

Technical Specifications and Writing Things Down

Context Management as Cognitive Load Reduction

Mental Flexibility and Decision-Making

Looking Forward

New CachyOS Guides for Gaming and Server Setup

CachyOS Gaming Quick Start

CachyOS Server Setup Guide

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

Improving Performance by Reducing API Data Size

Contents

Diagnosis

Solution

Opportunity: BFF Endpoints

Conclusion

What’s Next

Automatic Arrow Characters in Emacs