A Beginner's Guide to Extending Emacs

I’ve also never been able to get over the hump from “configuration” to “extending” (if that makes sense). This was a really interesting read.

Emacs also has a lot of inbuit tools to help you understand what's going on under the hood.

- `info` lets you read the emacs manual

- `apropos` lets you search for various elisp symbols in the editor, so if you're looking for something vaguer than a direct function or command you can search via apropos.

- The in-built `describe` (though I use a fantastic package called `helpful`) lets you figure out what the definition of a given variable, function, or command is. You can even look at what command a given key binding calls.

- Claude does a great job at teaching details of the editing/programming model of emacs which helps if you'd rather not read through the entire emacs manual

Things like this make emacs a joy to hack on (until you're trying to debug some slightly annoying behavior or crufty event loop thing ;)

  > My experience extending a core emacs function was an instructive and 
  > interesting exercise. I don't know what the future of emacs looks like in an
  > increasingly LLM-crazed world, but I hope that future  includes an open and
  > powerful way to extend and customize the tools we use to write software.

I have gptel configured with Claude 4.1 via API. Claude generates an org-mode file. I ask it questions about Emacs packages, Emacs configuration, and Emacs customization. It responds w/ Elisp snippets that I can eval immediately and see the effect. Claude knows a lot about Emacs. All these chats are version controlled into git so I can easily pull, consult-ripgrep, and pickup where I left off from any of my machines.

I can add my `.emacs` to the Claude context to get more precise answers. If it falls over on some package I can `M-x find-library` to add that library's source to the context. If the code it wrote doesn't work, I add the `Messages` buffer and the `Backtrace` buffer for errors. I eval the snippet, reprompt, rinse and repeat.

With this fast feedback loop (no restarting Emacs, just live coding), I've added a ton of customizations that in my twenty years of using Emacs previously just never felt like I had the time or enthusiasm for given higher priorities:

* Boring stuff: managing where modes open buffers in which windows

* More ambitious stuff: standard org-remark behavior isn't that natural for highlighting and making notes so I made a nicer Transient based thing for it.

* Stuff for work: a fast logging minor mode that font locks incrementally, disables all the save prompting, and handles ASCII color codes. Later I intend to linkify stack traces, linkify data so that they open pretty printed in a different buffer, collect errors and show an unobtrusive notification in the active window, etc. etc.

In two weeks, I've learned more Emacs than I did the 10 years prior. Most of all, this is a usage of LLMs that I can say I honestly love - improving my own day-to-day tools. Because Emacs is a text-oriented live programming environment - LLM integration just feels like it's on a completely different level.

Claude (or any good LLM) + Emacs is a killer app.

One of the big “ah ha” moments for me with respect to emacs customization was realizing that everything is a function call. Every time you press a key in emacs it’s effectively calling a function to find out what it should do next. Most of the time in most buffers the answer is “print the letter to the buffer” but it doesn’t have to be. It seems obvious said out loud like that but the mental model I had for the longest time made “typing” and “command input” two separate domains and that was a block mentally on using the key maps and various modes to customize the behavior