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.
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.
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.
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 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.
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.
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 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
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).
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.
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
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.
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.
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
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.
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.
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 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)
Code Companion for neovim has supported ACP for a while now
See https://agentclientprotocol.com/overview/clients
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
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).