Xenodium is doing amazing things for emacs. If you enjoy this or are generally emacs interested, I’d check out his blog @ https://xenodium.com/
I also purchased my first iOS app upon recommendation from other emacs users - the author’s app, Journelly. A simple portable place to save down links or notes and export out as org files (as one option; apparently markdown is on the way). https://xenodium.com/journelly-for-ios
No affiliation to Xenodium. I’ve just been diving into emacs this year and love seeing his contributions.
I have just spent a few days (part time) getting AiderEmacs working for running local models and commercial APIs. Fairly useful.
Next up for me is integrating your agent-shell with Gemini in my Emacs workflow. I will let you know how that goes and any other feedback I think might be useful.
EDIT: just finished a 20 minute Emacs session using agent-shell - love it!
agent-shell: A single native Emacs experience to interact with different AI agents powered by ACP (Agent Client Protocol) https://agentclientprotocol.com
So far, agent-shell can interact with Claude Code, Gemini CLI, Codex, and Goose, but can technically work with any ACP-powered agent.
Very exciting. I used claude-code-ide, but the fact that it's not using comint-mode is a PITA.
looking forward to trying this!
Can I ask. I haven't dug into the ACP spec. Does it cover the "ide" features too (like Claude code ide. Seems to mostly be telling the agent where your cursor is and diff integration)? Or just the basic stuff?
It's got some of them already like showing and accepting diffs rendered natively. All edits are committed via Emacs itself and on to open buffers if applicable. TAB navigation. Accepting permission has had a fair amount of iteration to smoothen the experience. It's been quite a bit of work to get here. There are obviously more feature to come. Please file feature requests if you find anything missing and of course, sponsor the project if you truly want it to be sustainable and move forward.
Agent shell is what I always wanted. I have been using many of the different Claude code integrations packages and they are really good. But there is always some friction because I need to run it in a terminal emulator. With agent shell it feels so much more integrated and natural.
I am really excited for these improvements, especially reading the env from a file.
I wish that agent-shell-sidebar had some screenshots though so I could see what it actually does.
Xenodium is doing great work for Emacs community. I am currently using `agent-shell` but I don't like the header added on the top of the buffer. I already have all information I want at the bottom. The bottom line you have make it optional so that minimalists can choose to remove it.
This is the first I hear of ACP… how does it compare to AG-UI? Well, obviously this is coding-specific and AG-UI aims to be generic… but beyond that obvious point?
It's the same point as LSP, but with AI agents.
It's a pain to implement a claude wrapper and a codex wrapper and a gemini wrapper and an aider wrapper and so on for every editor. So the zed people started the effort to standardise the protocol.
I think the difference is ECA is a coding agent with a LSP-like protocol for various frontend and editors, which itself supports many models.
Where as agent protocol if I understand lets you use many agents like Gemini CLI, Claude Code, well assuming they support the protocol, using various frontend?
Though I guess other coding agents could also adopt the ECA protocol maybe.
Yes, and the ECA project includes an emacs package; I've been using it recently.
I've been diving in to the ECA protocol a bit to debug some emacs issues, and from glancing at the ACP (Agent Client Protocol) documentation, it seems that the ECA and ACP protocols are incredibly similar, and both very well documented. An accident of reinvention.
I've tried both and that sounds about right - I had to configure my MCPs for it again and it runs its own server in the background.
For that alone I've preferred agent-shell since you just use the agent's own config. That's already enough of a pain point when each agent has its own config format and location, as well as the differences between project and user level config - would be nice if there was a standard for that at some point too.
A unified native user experience built into your text editor. Not only for Claude Code but also any other agent that talks ACP like Gemini CLI, Codex, Goose, etc.
I've spent 2 month trying out emacs and I feel like I sort of scratched the surface. It's like the deeper you look the more you realize how much more there is
I think the problem that most beginners try to explore the editor features, instead of focusing on main fundamental truth about Emacs - it's not just an editor, it's a Lisp system with a built-in editor.
I think focusing on understanding how Lisp drives Emacs can remarkably speed up the pace of learning it. Every key press and button click hooks up to a Lisp function. Even complex keyboard macros translate to Lisp command sequences.
1. Figure out structural editing commands to move s-expressions freely - those parens only feel annoying initially, later they become friendly.
2. Understand REPL-driven development - any expression can be evaled in-place.
3. Try the build-in profiler.
4. Learn the debugger.
5. Use the describe- commands. Emacs can "describe" to you every key, function, command, symbol, input methods, themes, fonts, characters, etc.
Emacs is really not about "what it can or cannot do" in general sense. It's all about "what you can do with it". Learn some basic elisp - and you will be able to achieve a lot.
I'm going to give a counterpoint to this (common) take.
I was an Emacs power user for almost a decade before I learned Emacs Lisp. I knew just the bare minimum to populate my .emacs file, and occasionally copied others' config snippets.
> Who's got a decade to spare, when they can wield the power in just a couple of months?
I was a power user within months - a year tops. I didn't say it took me 10 years to become a power user.
Ever since I learned Elisp (it's been many years), I wouldn't say my expertise and abilities has grown exponentially. It is merely an incremental improvement. It definitely is nice that I can now code away annoyances, but it's not the game changer people make it out to be.
> I wouldn't say my expertise and abilities has grown exponentially
Things always look easier only after you solve a problem, don't they?
That is a known as hindsight bias (also called the "knew-it-all-along" effect). Once you've solved a problem or seen the solution, it seems obvious and you tend to overestimate how predictable or easy it was.
There's related phenomena known as the curse of knowledge - difficulty imagining not knowing something once you know it.
"The Mythical Man-Month" - discusses on why we underestimate complexity, it explains the psychology behind it.
There's also "forgetting the beginner's journey" or the "fourth stage" of learning where skills become so automatic you can't easily explain them.
Your psychology lesson is misplaced. I know my usage before and after, and it's a minor delta. The bulk of my Emacs usage today is using features that have been in my config since prior to my learning Elisp.
If we're going to be patronizing here: Most people who learn Elisp early into their Emacs experience are failing at identifying the source of their growing expertise, and are incorrectly attributing it to their knowledge of Elisp, when in reality they are merely becoming better Emacs users due to repetitive practice.
They also have a habit of reinventing solutions that are readily available within Emacs, or as a package.
I'm not trying to snub you nor am I arguing with you - my opinions are just that - I never said they are fundamentally true for everyone. Similarly, your experiences are yours - it would be wrong to generalize based solely on that data. There was no "schooling" here, the phenomenon mentioned fits this case perfectly, I just thought someone might be interested to learn more about it, that's all. Cheers to you, friend.
My biggest revelation was when I realized how to use Emacs to learn about Emacs. Knowing where to look up function, variable definitions etc was an eye opener in my understanding of how things work and are piped together
There was a time when this was the obvious thing to do when making systems. Sadly that's forgotten. Manpages to read on cli tooling is the same thing of course. Yet people rather go to another window, the browser, and go to a ad-driven website and get the same output as the manpage would give.
These days people rather switch to a browser window, open an LLM of their choice in a new tab and in verbose English ask "how do I do X in this popular program Y?".
Then get a hallucinated answer and come to you to complain about a missing cli option, while it's literally there, in their terminal, just one -h away. True story (had to vent out, thanks for listening).
The only 2¢ I can add here is that LLMs are surprisingly good for solving tasks that involve Elisp. There's large corpus of Emacs Lisp in the wild - the amount of it on GitHub alone is shocking.
For comparison - whenever I try using a model to write some Neovim config stuff, LLMs hallucinate badly.
Using Emacs these days is so much fun - you just ask a model and you can immediately try things - not only without restarting - you don't even have to save anything, anywhere.
You can even make Emacs do things that involve tools and languages that have nothing to do with elisp, e.g., "write elisp that would open all nested dirs in a given folder, and then run magit-log for each project, searching for specific pattern... and if found, issue npm or uv pip install with arguments...", etc.
Xenodium is doing amazing things for emacs. If you enjoy this or are generally emacs interested, I’d check out his blog @ https://xenodium.com/
I also purchased my first iOS app upon recommendation from other emacs users - the author’s app, Journelly. A simple portable place to save down links or notes and export out as org files (as one option; apparently markdown is on the way). https://xenodium.com/journelly-for-ios
No affiliation to Xenodium. I’ve just been diving into emacs this year and love seeing his contributions.
Thank you! This really makes my day.
Also glad to hear you’re a Journelly fan. Thank you for purchasing. Building niche apps sustainably is a real challenge.
I'm going to pile-on here: I enjoy using Journelly a lot and it was an easy purchase for me to make. Thanks for building it!
Hello my friend, you deserve a good day!
I have just spent a few days (part time) getting AiderEmacs working for running local models and commercial APIs. Fairly useful.
Next up for me is integrating your agent-shell with Gemini in my Emacs workflow. I will let you know how that goes and any other feedback I think might be useful.
EDIT: just finished a 20 minute Emacs session using agent-shell - love it!
Hey, nice to see ya here! Sure, you know where to find me :)
agent-shell: A single native Emacs experience to interact with different AI agents powered by ACP (Agent Client Protocol) https://agentclientprotocol.com
So far, agent-shell can interact with Claude Code, Gemini CLI, Codex, and Goose, but can technically work with any ACP-powered agent.
ps. agent-shell needs more sponsors to become sustainable https://github.com/sponsors/xenodium
Very exciting. I used claude-code-ide, but the fact that it's not using comint-mode is a PITA.
looking forward to trying this!
Can I ask. I haven't dug into the ACP spec. Does it cover the "ide" features too (like Claude code ide. Seems to mostly be telling the agent where your cursor is and diff integration)? Or just the basic stuff?
It's got some of them already like showing and accepting diffs rendered natively. All edits are committed via Emacs itself and on to open buffers if applicable. TAB navigation. Accepting permission has had a fair amount of iteration to smoothen the experience. It's been quite a bit of work to get here. There are obviously more feature to come. Please file feature requests if you find anything missing and of course, sponsor the project if you truly want it to be sustainable and move forward.
Agent shell is what I always wanted. I have been using many of the different Claude code integrations packages and they are really good. But there is always some friction because I need to run it in a terminal emulator. With agent shell it feels so much more integrated and natural.
I am really excited for these improvements, especially reading the env from a file.
I wish that agent-shell-sidebar had some screenshots though so I could see what it actually does.
Xenodium is doing great work for Emacs community. I am currently using `agent-shell` but I don't like the header added on the top of the buffer. I already have all information I want at the bottom. The bottom line you have make it optional so that minimalists can choose to remove it.
> but I don't like the header added on the top of the buffer
Please file a feature request, so we can make the graphical header optional: https://github.com/xenodium/agent-shell/issues
I've used it a few times now. It's a really smooth experience for quite a new package.
Im a bit out of the loop. What's the main differences between this one and gptel?
This is the first I hear of ACP… how does it compare to AG-UI? Well, obviously this is coding-specific and AG-UI aims to be generic… but beyond that obvious point?
It's the same point as LSP, but with AI agents. It's a pain to implement a claude wrapper and a codex wrapper and a gemini wrapper and an aider wrapper and so on for every editor. So the zed people started the effort to standardise the protocol.
There's another project called ECA: https://github.com/editor-code-assistant/eca
I think the difference is ECA is a coding agent with a LSP-like protocol for various frontend and editors, which itself supports many models.
Where as agent protocol if I understand lets you use many agents like Gemini CLI, Claude Code, well assuming they support the protocol, using various frontend?
Though I guess other coding agents could also adopt the ECA protocol maybe.
Yes, and the ECA project includes an emacs package; I've been using it recently.
I've been diving in to the ECA protocol a bit to debug some emacs issues, and from glancing at the ACP (Agent Client Protocol) documentation, it seems that the ECA and ACP protocols are incredibly similar, and both very well documented. An accident of reinvention.
I've tried both and that sounds about right - I had to configure my MCPs for it again and it runs its own server in the background.
For that alone I've preferred agent-shell since you just use the agent's own config. That's already enough of a pain point when each agent has its own config format and location, as well as the differences between project and user level config - would be nice if there was a standard for that at some point too.
So why would one want to use this verses using Claude Code directly?
A unified native user experience built into your text editor. Not only for Claude Code but also any other agent that talks ACP like Gemini CLI, Codex, Goose, etc.
It's the emacs way - emacs eats the world
I am waiting for someone to build this for Neovim.
Come on, you unknown hero!
(and thanks to the Zed team and Google for building the spec)
Swing by the Emacs side ;) We got vim bindings too!
You can learn Emacs in one day. Every day!
Hey I know where that’s from!
As an Emacs user, his video was very funny https://youtu.be/urcL86UpqZc?si=Jhqiy1yCXDGHoIoS
I've spent 2 month trying out emacs and I feel like I sort of scratched the surface. It's like the deeper you look the more you realize how much more there is
I think the problem that most beginners try to explore the editor features, instead of focusing on main fundamental truth about Emacs - it's not just an editor, it's a Lisp system with a built-in editor.
I think focusing on understanding how Lisp drives Emacs can remarkably speed up the pace of learning it. Every key press and button click hooks up to a Lisp function. Even complex keyboard macros translate to Lisp command sequences.
1. Figure out structural editing commands to move s-expressions freely - those parens only feel annoying initially, later they become friendly.
2. Understand REPL-driven development - any expression can be evaled in-place.
3. Try the build-in profiler.
4. Learn the debugger.
5. Use the describe- commands. Emacs can "describe" to you every key, function, command, symbol, input methods, themes, fonts, characters, etc.
Emacs is really not about "what it can or cannot do" in general sense. It's all about "what you can do with it". Learn some basic elisp - and you will be able to achieve a lot.
I'm going to give a counterpoint to this (common) take.
I was an Emacs power user for almost a decade before I learned Emacs Lisp. I knew just the bare minimum to populate my .emacs file, and occasionally copied others' config snippets.
No need to rush into learning Elisp.
You just unironically proved my point. Who's got a decade to spare, when they can wield the power in just a couple of months?
> Who's got a decade to spare, when they can wield the power in just a couple of months?
I was a power user within months - a year tops. I didn't say it took me 10 years to become a power user.
Ever since I learned Elisp (it's been many years), I wouldn't say my expertise and abilities has grown exponentially. It is merely an incremental improvement. It definitely is nice that I can now code away annoyances, but it's not the game changer people make it out to be.
> I wouldn't say my expertise and abilities has grown exponentially
Things always look easier only after you solve a problem, don't they?
That is a known as hindsight bias (also called the "knew-it-all-along" effect). Once you've solved a problem or seen the solution, it seems obvious and you tend to overestimate how predictable or easy it was.
There's related phenomena known as the curse of knowledge - difficulty imagining not knowing something once you know it.
"The Mythical Man-Month" - discusses on why we underestimate complexity, it explains the psychology behind it.
There's also "forgetting the beginner's journey" or the "fourth stage" of learning where skills become so automatic you can't easily explain them.
___
https://en.wikipedia.org/wiki/Hindsight_bias
https://en.wikipedia.org/wiki/Curse_of_knowledge
https://en.wikipedia.org/wiki/Four_stages_of_competence
Your psychology lesson is misplaced. I know my usage before and after, and it's a minor delta. The bulk of my Emacs usage today is using features that have been in my config since prior to my learning Elisp.
If we're going to be patronizing here: Most people who learn Elisp early into their Emacs experience are failing at identifying the source of their growing expertise, and are incorrectly attributing it to their knowledge of Elisp, when in reality they are merely becoming better Emacs users due to repetitive practice.
They also have a habit of reinventing solutions that are readily available within Emacs, or as a package.
I'm not trying to snub you nor am I arguing with you - my opinions are just that - I never said they are fundamentally true for everyone. Similarly, your experiences are yours - it would be wrong to generalize based solely on that data. There was no "schooling" here, the phenomenon mentioned fits this case perfectly, I just thought someone might be interested to learn more about it, that's all. Cheers to you, friend.
My biggest revelation was when I realized how to use Emacs to learn about Emacs. Knowing where to look up function, variable definitions etc was an eye opener in my understanding of how things work and are piped together
There was a time when this was the obvious thing to do when making systems. Sadly that's forgotten. Manpages to read on cli tooling is the same thing of course. Yet people rather go to another window, the browser, and go to a ad-driven website and get the same output as the manpage would give.
These days people rather switch to a browser window, open an LLM of their choice in a new tab and in verbose English ask "how do I do X in this popular program Y?".
Then get a hallucinated answer and come to you to complain about a missing cli option, while it's literally there, in their terminal, just one -h away. True story (had to vent out, thanks for listening).
Hey, now.
When I want to ask an LLM how to do something in emacs I `SPC $ g g` and ask it in a gptel buffer.
The only 2¢ I can add here is that LLMs are surprisingly good for solving tasks that involve Elisp. There's large corpus of Emacs Lisp in the wild - the amount of it on GitHub alone is shocking.
For comparison - whenever I try using a model to write some Neovim config stuff, LLMs hallucinate badly.
Using Emacs these days is so much fun - you just ask a model and you can immediately try things - not only without restarting - you don't even have to save anything, anywhere.
You can even make Emacs do things that involve tools and languages that have nothing to do with elisp, e.g., "write elisp that would open all nested dirs in a given folder, and then run magit-log for each project, searching for specific pattern... and if found, issue npm or uv pip install with arguments...", etc.
Im going on a decade now, and there's always still more (in a good way)!
Code Companion for neovim has supported ACP for a while now
See https://agentclientprotocol.com/overview/clients