I do wish that Emacs was more popular with LLM technologies.
LLMs are powerful at dealing with text. And Emacs is highly extensible and typically text-oriented. Already I see people say that LLMs much Emacs much easier to use (since you can ask an LLM to come up with the elisp for you), but I reckon what Emacs provides ought to be useful the other way.
With Emacs, it's common to see people favour bringing various parts of the system all within Emacs. I'm reminded of that when I've seen how useful it can be to provide API access to logging/code/documentation when asking an LLM to troubleshoot.
With LLMs, there are several uses cases I see which are a natural fit for org-mode, and just imitated in markdown. -- e.g. org mode have TODO items, checklists, tables (including spreadsheet functionality), code blocks, tagging/properties.
I've started experimenting with claude to run end-to-end tests for an emacs package I'm developing. It's incredible.
The way it works:
1. You start emacs in daemon (server) mode.
2. You prompt claude to instantiate an emacs client and write/run tests.
That's it.
Claude will then "pilot" an emacs instance where you can visibly see it running tests. Since almost everything is a first-class function in emacs, and emacs enables almost complete introspection, claude can debug the code in the execution environment. You can also just look at the piloted emacs instance and prompt the agent on what's wrong in the running application state.
This is much more thorough then just having claude write unit tests because many of the issues you might encounter are visual/gui things - which, again, because emacs allows so much introspection, can be examined by looking at the current application state.
> I do wish that Emacs was more popular with LLM technologies.
Let's reword this a bit: "I wish Lisp use was more popular with LLMs...", because using Lisp REPL with AI is such a "life hack", I don't get why more people don't do that. When you give AI a "true Lisp REPL" it works wondrously - it stops randomly guessing and starts empirically understanding the problem and the code - saving time, tokens, your mental energy. And with Emacs' text manipulating machinery on top of that, things can get seriously interesting.
I thought this as well, so I spent a few days working with Claude in emacs. Claude managed to totally break my install by suggesting a bunch of "fixes" that were actually not fixes at all. Very poor performance, just hallucinating things left and right.
I don't need Anthropic to break my emacs, I can do that all by myself.
I do wish that Emacs was more popular with LLM technologies.
LLMs are powerful at dealing with text. And Emacs is highly extensible and typically text-oriented. Already I see people say that LLMs much Emacs much easier to use (since you can ask an LLM to come up with the elisp for you), but I reckon what Emacs provides ought to be useful the other way.
With Emacs, it's common to see people favour bringing various parts of the system all within Emacs. I'm reminded of that when I've seen how useful it can be to provide API access to logging/code/documentation when asking an LLM to troubleshoot.
With LLMs, there are several uses cases I see which are a natural fit for org-mode, and just imitated in markdown. -- e.g. org mode have TODO items, checklists, tables (including spreadsheet functionality), code blocks, tagging/properties.
I've started experimenting with claude to run end-to-end tests for an emacs package I'm developing. It's incredible.
The way it works:
1. You start emacs in daemon (server) mode.
2. You prompt claude to instantiate an emacs client and write/run tests.
That's it.
Claude will then "pilot" an emacs instance where you can visibly see it running tests. Since almost everything is a first-class function in emacs, and emacs enables almost complete introspection, claude can debug the code in the execution environment. You can also just look at the piloted emacs instance and prompt the agent on what's wrong in the running application state.
This is much more thorough then just having claude write unit tests because many of the issues you might encounter are visual/gui things - which, again, because emacs allows so much introspection, can be examined by looking at the current application state.
This is a good example of "completing the loop."
> I do wish that Emacs was more popular with LLM technologies.
Let's reword this a bit: "I wish Lisp use was more popular with LLMs...", because using Lisp REPL with AI is such a "life hack", I don't get why more people don't do that. When you give AI a "true Lisp REPL" it works wondrously - it stops randomly guessing and starts empirically understanding the problem and the code - saving time, tokens, your mental energy. And with Emacs' text manipulating machinery on top of that, things can get seriously interesting.
I thought this as well, so I spent a few days working with Claude in emacs. Claude managed to totally break my install by suggesting a bunch of "fixes" that were actually not fixes at all. Very poor performance, just hallucinating things left and right.
I don't need Anthropic to break my emacs, I can do that all by myself.
No, I think that ̶w̶i̶n̶t̶e̶r̶m̶u̶t̶e̶ ̶w̶i̶l̶l̶ ̶m̶e̶r̶g̶e̶ ̶w̶i̶t̶h̶ ̶n̶e̶u̶r̶o̶m̶a̶n̶c̶e̶r̶ emacs will merge with claude instead.
Already did: https://github.com/stevemolitor/claude-code.el /j
[flagged]
(The prefix arg disables paperclips, for obvious reasons )