Aidermacs 2.0 Initiative: No More Aider, Only Emigo #98
Replies: 6 comments 5 replies
-
|
seems like the goal is to implement a brand new AI pair programming assistant in emacs? And the CLI program Aider is no longer needed? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, beginning with making a simplified Aider. |
Beta Was this translation helpful? Give feedback.
-
|
Kudos. I think the core functionality can be still implemented in Python. And maybe using a communication like LSP-bridge for data communication. Alternatively, if LSP-bridge style’s tight coupling and non trivial setup is not desired (this can vary according to person’s taste). Implementing it as a LSP server is an alternative approach. (a nonstandard LSP server like copilot that uses its JSON-RPC standard but only implemented private request method). There are framework for building a LSP server in python. The benefit of LSP is that it can published as a standalone PYPI, so the user do not need to configure the python app environment manually. So that we can reuse the aider’s code as much as possible. Another thing is that python has some many nice framework for agent related stuffs. Implementing those things in python would sure easier than in elisp |
Beta Was this translation helpful? Give feedback.
-
|
Yes, a lsp-bridge-like flow is my intention, I am working this with lazycat. I am going to dismantle aider using aider ;-) |
Beta Was this translation helpful? Give feedback.
-
|
Excellent! I'd be happy to contribute to development and provide code related to lsp-bridge/mind-wave/eaf-git. |
Beta Was this translation helpful? Give feedback.
-
|
Great, use epc, this is the way! |
Beta Was this translation helpful? Give feedback.
-
|
Given that aidermacs 2.0 will not use aider anymore, should the repo be renamed? Should I create a new repo completely? What're everyone's thoughts on this? |
Beta Was this translation helpful? Give feedback.
-
|
It sounds like your goal is different enough that it should be a different project. I wouldn't rename this repo; I would start a new one, or fork this one. |
Beta Was this translation helpful? Give feedback.
-
|
If the major rework is to reuse aider’s coding and agent logic. Just removing its CLI part and implementing a client-server middle-end. I think keep calling its aidermacs fine. As the name would suggest, aidermacs would them become a shout out to the original project aider. |
Beta Was this translation helpful? Give feedback.
-
If you don't use aider, adding support for MCP becomes straightforward. |
Beta Was this translation helpful? Give feedback.
-
Thank everyone for the ongoing support, for the 400 stars in 45 days, for the 30 contributors. Upon consideration, future development will be made at https://github.com/MatthewZMD/emigoStay tuned. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Update: Thank everyone for the ongoing support, for the 400 stars in 45 days, for the 30 contributors. Upon consideration, future development will be made at https://github.com/MatthewZMD/emigo
Stay tuned.
As the author and maintainer of Aidermacs, my vision has always been to bring a Cursor-like, seamless AI-assisted programming experience to Emacs: focusing on seamless UX and smart, agentic AI workflows, and deep integration with Emacs’ editing model. Whether or not it uses Aider, or mimics its behavior, is not my primary concern. Aider is a convoluted and complex project, and in some ways, I would argue it’s over-engineered. While many of its features are undeniably useful, and even unique compared to Cursor, but the more I try to adapt Aidermacs to its architecture, the more bloated and daunting the transient menu becomes, especially for users unfamiliar with Aider itself.
I don't expect (or hope) anyone who uses Aidermacs is because it is the "best" Aider frontend in Emacs, but because Aidermacs is the best AI pair programming solution in Emacs, otherwise aider.el was a fine enough Aider frontend, and I wouldn't have the incentive to fork it in the first place. Aidermacs having a very detailed/daunting Aider controls in the transient menu that respects Aider design, have made it the better frontend with Aider, but it is a side-effect of me trying to make the Emacs AI Pair Programming solution by studying Aider itself.
The deeper I get into maintaining Aidermacs, the more friction I experience from Aider’s CLI-driven design. I’ve had to implement numerous workarounds, some quite ugly, just to align its behavior with what feels native to Emacs. It’s taking an increasing toll on maintenance, and I’m starting to question the value of continuing down this path.
At this point, I’ve come to believe that Aider’s upstream architecture is actively limiting the evolution of Aidermacs. Therefore, I’m announcing the Aidermacs 2.0 initiative: I will begin dismantling Aider’s core logic and reimplementing essential functionality natively within Aidermacs. This means the comint/vterm backend will be removed, and many breaking changes will follow. But I believe this is the right step toward a simpler, better, and distinctly Emacs-native experience. And yes, expect that it will not be backward compatible with Aider or Aidermacs 1.0.
The work is at early phase, developments will be made at https://github.com/MatthewZMD/emigo
Beta Was this translation helpful? Give feedback.
All reactions