Published 2026-07-17
tag(s): #failures #programming #overblown-minor-annoyances
Here is a link to part 1. If you don't feel like reading it: I had an LLM write a minimal MCP server to expose Emacs, and I figured if I am going to use these tools, at least make them work in a way that I enjoy. So I kept iterating on that initial setup.
A couple weeks ago I felt like I needed to change the name of the mincp
repository. For starters, it wasn't minimal anymore.
And also, it morphed so much. It went from "let Claude run an couple Emacs commands"
to a complete workflow that uses Emacs as the duck tape connecting file system and database
access, code reviews, and even JIRA connectors.
It really is a unique setup, not unlike my """blogging platform""".
Someone looking at the repo might encounter ideas to copy, but I would find it hard to believe
that anyone else in this planet could use it as-is. That's how tailored it is.
But before disclosing the name (which is in the title of the post, anyway.
And the new repository name, too), let's
talk about how it works.
I really like ediff, and I found a while ago that it has an interface for
multiple-file reviews.
Having mincp running find and grep via Emacs, it
occurred to me that I could also get the agent to edit code directly via elisp, and I review
the changes in ediff, deciding what to apply and live editing the merged version.
Turns out that this wasn't a great idea, for a number of reasons. One is simply that the
multi-file patch support in ediff isn't very mature. For example it doesn't deal
with new files in Windows very well[1]. Also since Claude edited
files while I was using Emacs we would run into each other moving point and changing
buffers.
The solution to the latter was simply to let the agent work on the dev servers, and keep my
laptop Emacs for other tasks. And the GREAT idea for my ediff woes, was asking
the agent to generate diff patches instead. I can still easily edit the code, and then apply
hunk by hunk with diff-mode.
At work, a few people were fond of the idea of allowing an agent access to a Linux storage
that has TONS of files we receive daily to process.
Doing it with the Claude Code app is a bit challenging, since it runs in our local laptops.
Doing it from Linux implies some sort of MCP server that should use the user's credentials,
since the files cannot be access anonymously.
This was a non-issue for me. Emacs runs on the Linux dev server, under my user, and the agent
is connected to my Emacs instance.
Is it dangerous? Yes. In practice, the agent never did any destructive operation in any of the
files in the network storage. I just ask it (or do it myself) to put a copy of any file I want
to manipulate in my home directory, to be safe.
But the "find a needle in a haystack" type of problems, can be perfectly solved by the
agent via find-name-dired, rgrep and friends.
Instead of using SSMS or Toad or Aqua Studio, I connect to databases using Emacs.
Another long story, but I wrote Datum a few
years ago to access any database via ODBC using sql-interactive-mode.
I manage my DB passwords via an encrypted authinfo file, and open any connections
that I need myself. After that, I simply tell Claude "you can find XYZ dabatase in the
buffer ABC" and we are good to go. It usually realizes on its own if the DB is Oracle or
MSSQL or MariaDB, sometimes I tell it in advance just make things quicker.
A realistic example, I open a new agent-shell and I tell the agent "Look at
so and so config section, it is called from XYZ module in this repo. The tables it queries are
in the database connected in buffer *SQL: <somedb>*. We need another config section to
ingest files at /some/vendor_directory/dataset and output to the same tables".
Does it give me perfectly usable code? Rarely. But the way it connects the dots is useful
and gives me a head start.
Is this enough to justify all the ethical and resources usage (and probably other) problems
with LLMs? I have my own opinions on this (in short: no).
Is it a "time saver", or (nebulously defined) "more productive"? I can argue
that yes, it is useful and productive. 🤷
I realize the way I use Claude is not the way most people use it.
Or at least, not the way the most vocal members of the community do.
But this setup works for me. It makes dealing with these tools fun, and yes, sometimes the fact that something is fun justifies its existence (talking about, my tooling, not LLMs...)
One morning, I took a long, hard look at the Emacs MCP server. The way it uses elisp
evaluation to query DBs via a CLI tool. How it generates patches for me to slowly review,
instead of quickly spitting out tons of code.
And I thought That's a really complicated setup...but it is not complex just because, it
gives me useful things, just in a very roundabout way that works. For me at least.
I thought about it some more, looked for synonyms for "complicated", and when I
saw it. Byzantine.
The one word to describe my LLM tooling: Byzantine.