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.
Also glad to hear you’re a Journelly fan. Thank you for purchasing. Building niche apps sustainably is a real challenge.
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!
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
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?
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.
That's great to hear.
> I wish that agent-shell-sidebar had some screenshots though so I could see what it actually does.
I nudged the package author for a screenshot. Having said that, you can see it in action here: https://github.com/xenodium/agent-shell/pull/55
Please file a feature request, so we can make the graphical header optional: https://github.com/xenodium/agent-shell/issues
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 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.
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.
Come on, you unknown hero!
(and thanks to the Zed team and Google for building the spec)
As an Emacs user, his video was very funny https://youtu.be/urcL86UpqZc?si=Jhqiy1yCXDGHoIoS
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).
When I want to ask an LLM how to do something in emacs I `SPC $ g g` and ask it in a gptel buffer.
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.
I'm a Spacemacs user, and Claude knows the difference between Spacemacs and stock emacs. It basically wrote tools for itself to hook into the emacs LSP package and look up C++ code (in our codebase, which is, uh, challenging for FOSS language servers) from gptel. I was completely fucking unable to do this via publicly-available MCP servers in the VSCode agent mode. In general I have been able to resolve a bunch of niggling config issues that I had just been ignoring in favor of doing Actual Work.
As you said, I can evaluate the elisp Claude wrote right there in the gptel buffer, try it out, and iterate before actually pasting it into .spacemacs. It it doesn't work, Claude knows a ton of debugging tricks I can try. trace-function, advice to dump a backtrace, etc. It knows how to do everything in org-mode. Super helpful. Way better than the AI Assistant that my employer bundles with our product (which is outperformed by the Google AI Overview).
Claude Sonnet is good at being Claude Code and it turns out it's also pretty good at calling gptel tools when hooked up to gptel as a dumb token pipe.
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 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.
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.
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
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.