I used Emacs for about a decade and then switched to VS Code about eight years ago. I was curious about the state of Claude Code integration with Emacs, so I installed it to try out a couple of the Claude packages. My old .emacs.d that I toiled many hours to build is somewhere on some old hard drive, so I decided to just use Claude code to configure Emacs from scratch with a set of sane defaults.
I proceeded to spend about 45 minutes configuring Emacs. Not because Claude struggled with it, but because Claude was amazing at it and I just kept pushing it well beyond sane default territory. It was weirdly enthralling to have Claude nail customizations that I wouldn't have even bothered trying back in the day due to my poor elisp skills. It was a genuinely fun little exercise. But I went back to VS Code.
Came to post exactly this, except it’s got me using emacs again. I led myself into some mild psychosis where I attempted to mimic the Acme editor’s windowing system, but I recovered
Yeah, and all the little quirks here and there I had with emacs or things that I wish I had in workflow, I can just fix/have it without worrying about spending too much time (except sometimes maybe). The full Emacs potential I felt I wasn't using, I'm doing it and now I finally get it why Emacs is so awesome.
E.g. I work on a huge monorepo at this new company, and Emacs TRAMP was super slow to work with. With help of Claude, I figured out what packages are making it worse, added some optimizations (Magit, Project Find File), hot-loaded caching to some heavyweight operations (e.g. listing all files in project) without making any changes to packages itself, and while listing files I added keybindings to my mini buffer map to quickly just add filters for subproject I'm on. Could have probably done all this earlier as well, but it was definitely going to take much longer as I was never deep into elisp ecosystem.
> Emacs TRAMP was super slow to work with. With help of Claude, I figured out [...]
Out of curiosity, did it advise you to configure auto-save and backup such that they write their files under ~/.emacs.d, rather than in the same directory alongside the (with Tramp, potentially remote) file they're about? Especially with vanilla Emacs, that's always the first place you want to look when you see freezes doing file operations on a remote host over a slow or flaky link.
I believe I first added that change to my .emacs in 2010 or 2011, and as far as I can recall, it was the only change I ever needed to make to address Tramp being slow sometimes.
Hooking up Emacs to ECA with emacs-eval MCP is fantastic - Claude can make changes in my active Emacs session, run the profiler, unload/reload things, log some computation or embark-export search results and show it in a buffer; It can play tetris and drive itself crazy with M-x doctor - it's complete and utter bonkers. I can tell it to make some face color brighter/darker on the spot, the other day I fixed a posframe scaling issue that bugged me for a long time - it's not even about "I don't know elisp", this specific thing requires you to sit down and calculate geometry of things - mechanical, boring stuff. AI did it in minutes. VS Code, IntelliJ, any other shit that has no Lisp REPL? What are you even talking about? It's like a different world.
I proceeded to spend about 45 minutes configuring Emacs. Not because Claude struggled with it, but because Claude was amazing at it and I just kept pushing it well beyond sane default territory. It was weirdly enthralling to have Claude nail customizations that I wouldn't have even bothered trying back in the day due to my poor elisp skills. It was a genuinely fun little exercise. But I went back to VS Code.