> 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.
I’m always surprised when they (GPT 4.1 in my case) manage to get all of the closing parentheses right! I’d have guessed that having such a sequence of same characters would be a challenge for the LLM to use the right amount
So do you have gptel configured to ask Claude to respond in org-mode? Do you then use elisp to write the chat into a VCS-controlled dir? Do you use org-mode to record the conversation between LLM and user?
Curious because I've been thinking of writing a chat mode based on gptel to more closely mimic the behavior of Claude Desktop. I find the vanilla gptel experience to be pretty bleh but I know it's meant to be extensible and not necessarily a user-facing experience.
Yes. gptel supports two output modes out of the box, markdown (meh), and org-mode. I make an org-mode heading with my question, then I press `C-c <enter>`. Claude will use the area bellow the heading for its answer. It will make sub-headings, code blocks, lists, tables, etc. If I have another question then I make a new top level org-mode heading.
I started doing this because I got fed-up with Claude Desktop for my StackOverflow style programming questions - and then stumbled upon using it to configure Emacs.
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
I have seen this somewhere in the official documentation [a]. I know it's too much to expect a user to read the full application documentation. But the documentation for Emacs and several other GNU applications are absolute treasures. The elisp documentation for beginners is in fact a full on introductory text book on programming. So it's a good idea to invest some time on those if you plan to make Emacs your long term coding platform. The returns are significant - it isn't too hard to learn elisp and extend Emacs in ways that are difficult in other editors.
[a] A simple tip. You can find the function of a key sequence with this sequence: `C-h k <sequence>`. Try this with any regular letter key to see what the parent comment is talking about.
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 ;)
> (until you're trying to debug some slightly annoying behavior or crufty event loop thing ;)
What do you mean by this? One can look at Emacs itself as a crusty event loop with some slightly annoying behavior. But seriously, I am curious what you mean.
You may already know (and others may not):
- `M-x toggle-debug-on-error` throws you into the debugger on any error (note this isn't "visual" the edebugger!). Use C-h m to see the navigation commands/keys
- Use (debug) to set a breakpoint in Lisp code
- depending on the circumstances, the edebugger may be more helpful. I always instrument the function to debug with `C-u C-M-x` from within the function's form and use `C-M-x` to interpret it (sorry, I forget the underlying commands)
Of course, there's great documentation for both the debugger and edebugger.
You already have - configuring is extending in emacs :) there is no magic, like in other editors - the same function calls, hooks, (re)definitions all the way down, to the c-core.
My advice is to use a LLM for that - they are often surprisingly good at producing decent elisp. Maybe not in "publish on ELPA/MELPA" quality, but it can absolutely cover user needs. I know the ecosystem and can read elisp as a coincidence of playing with common lisp - it is enough for glueing things together. The most complicated code I have is around org agenda and export of org tasks - there I needed some LLM help, but I was able to identify and fix performance bottlenecks in some packages and write a config from scratch on my own.
Prot has an intro book on elisp[1] which I want to go through, because some specifics of text processing and buffer usage are a bit unique - it is a lisp for a text editor, after all! But it is still just a lisp, and it even has a lot of common lisp functions in cl-* namespace!
long time vim user, doomemacs was my door into emacs's world and I don't regret it, it is a wonderfull tool but compared to vim, you need a good config - it's really to barebone out of the box. Doomemacs (or similar) are doing a great job at getting you started. Orgmode was really was kept me inside of emacs.
You can treat DoomEmacs or Spacemacs similarly. They provide an opinionated and streamlined way to interacting with Emacs. Doom is closer to "vanilla" than Spacemacs but I have used Spacemacs for over 10 years now.
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.
I’m always surprised when they (GPT 4.1 in my case) manage to get all of the closing parentheses right! I’d have guessed that having such a sequence of same characters would be a challenge for the LLM to use the right amount
So do you have gptel configured to ask Claude to respond in org-mode? Do you then use elisp to write the chat into a VCS-controlled dir? Do you use org-mode to record the conversation between LLM and user?
Curious because I've been thinking of writing a chat mode based on gptel to more closely mimic the behavior of Claude Desktop. I find the vanilla gptel experience to be pretty bleh but I know it's meant to be extensible and not necessarily a user-facing experience.
Yes. gptel supports two output modes out of the box, markdown (meh), and org-mode. I make an org-mode heading with my question, then I press `C-c <enter>`. Claude will use the area bellow the heading for its answer. It will make sub-headings, code blocks, lists, tables, etc. If I have another question then I make a new top level org-mode heading.
I started doing this because I got fed-up with Claude Desktop for my StackOverflow style programming questions - and then stumbled upon using it to configure Emacs.
i 100% agree, kinda cool how LISP was first meant for AI and now it’s easy to reap the benefits of this
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
I have seen this somewhere in the official documentation [a]. I know it's too much to expect a user to read the full application documentation. But the documentation for Emacs and several other GNU applications are absolute treasures. The elisp documentation for beginners is in fact a full on introductory text book on programming. So it's a good idea to invest some time on those if you plan to make Emacs your long term coding platform. The returns are significant - it isn't too hard to learn elisp and extend Emacs in ways that are difficult in other editors.
[a] A simple tip. You can find the function of a key sequence with this sequence: `C-h k <sequence>`. Try this with any regular letter key to see what the parent comment is talking about.
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 ;)
> (until you're trying to debug some slightly annoying behavior or crufty event loop thing ;)
What do you mean by this? One can look at Emacs itself as a crusty event loop with some slightly annoying behavior. But seriously, I am curious what you mean.
You may already know (and others may not):
- `M-x toggle-debug-on-error` throws you into the debugger on any error (note this isn't "visual" the edebugger!). Use C-h m to see the navigation commands/keys
- Use (debug) to set a breakpoint in Lisp code
- depending on the circumstances, the edebugger may be more helpful. I always instrument the function to debug with `C-u C-M-x` from within the function's form and use `C-M-x` to interpret it (sorry, I forget the underlying commands)
Of course, there's great documentation for both the debugger and edebugger.
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.
You already have - configuring is extending in emacs :) there is no magic, like in other editors - the same function calls, hooks, (re)definitions all the way down, to the c-core.
I think the distinction for me is getting from the mindset of "I'll look for a package for this" as opposed to "let me write some elisp for this."
My advice is to use a LLM for that - they are often surprisingly good at producing decent elisp. Maybe not in "publish on ELPA/MELPA" quality, but it can absolutely cover user needs. I know the ecosystem and can read elisp as a coincidence of playing with common lisp - it is enough for glueing things together. The most complicated code I have is around org agenda and export of org tasks - there I needed some LLM help, but I was able to identify and fix performance bottlenecks in some packages and write a config from scratch on my own.
Prot has an intro book on elisp[1] which I want to go through, because some specifics of text processing and buffer usage are a bit unique - it is a lisp for a text editor, after all! But it is still just a lisp, and it even has a lot of common lisp functions in cl-* namespace!
[1] https://protesilaos.com/emacs/emacs-lisp-elements
I've seen worse code published on Melpa.
if you test it and it works, you should publish it.
[flagged]
long time vim user, doomemacs was my door into emacs's world and I don't regret it, it is a wonderfull tool but compared to vim, you need a good config - it's really to barebone out of the box. Doomemacs (or similar) are doing a great job at getting you started. Orgmode was really was kept me inside of emacs.
Definitely a YMMV kind of vibe. Ignore all the opinionated takes and find your own personal opinionated path.
You can treat DoomEmacs or Spacemacs similarly. They provide an opinionated and streamlined way to interacting with Emacs. Doom is closer to "vanilla" than Spacemacs but I have used Spacemacs for over 10 years now.