coding-agent subagent system | First-party IDE features may appear before language-server or Emacs…
انتشار: 2026/07/14 22:07 UTC
coding-agent subagent system | First-party IDE features may appear before language-server or Emacs support; best paired with a separate agent || gh-copilot-chat.el | Partial | No | Mostly explicit buffers/files/project context | Calls GitHub Copilot chat services | Multiple Copilot-hosted models | GitHub Copilot subscription | Explicit context can work remotely; broader scope may be awkward | Some Copilot/project instructions | No native subagent system | No autocomplete by itself; not a replacement for full Copilot CLI Agent Mode || Aidermacs | Full pair-programming agent | No | Automatic repo map plus explicit editable/read-only files | Emacs launches Aider through comint/vterm; Aider calls provider APIs | Yes | Usually provider API billing or local models | Remote support depends on process and repo placement | .aider.conf.yml, conventions, model/editor settings | Architect/editor split; not general subagent tree | Configuration precedence and editable/read-only file management can be confusing || aider.el | Backend; full | No | Automatic repo map plus explicit files | Lightweight wrapper around Aider CLI | Yes | Aider/provider authentication | Depends on how Aider is launched | Aider config/conventions | Aider-dependent | Usually less polished than Aidermacs; significant overlap || pi-coding-agent | Full | No | Automatic | Purpose-built Emacs frontend communicating with Pi process | Yes | Whatever provider/login methods Pi supports | Pi process should run near project filesystem | Pi instructions, extensions, project config | Depends on Pi features/extensions | Rich TUI widgets and some interactive commands may not map; login may need external terminal || cursor-agent.el | Backend; full | No | Automatic | Emacs wrapper around Cursor Agent CLI | Models offered by Cursor | Cursor account/subscription | Best when CLI runs where project exists | Cursor rules and CLI config | Cursor-dependent | Does not provide Cursor editor autocomplete inside Emacs; tied to Cursor service || ai-code-interface.el | Backend-dependent | No | Backend-dependent | Compatibility layer over multiple packages and CLIs | Yes | Backend-dependent | Backend-dependent | Backend-dependent | Backend-dependent | Adds another abstraction layer; special backend features still need explicit adapters || minuet-ai.el | No | Yes; FIM/chat-model completion; no true NES | Buffer/local context, not autonomous repo search | Emacs calls completion-model APIs directly | Yes | API keys or local models | Usually easier with TRAMP because it mainly uses buffer text | Provider/completion prompt config | No | No shell, repo search, multi-file edits, agent loop, or genuine NES || Direct CLI in eat/vterm/ghostel | Backend; full | No Emacs-native autocomplete | Usually automatic | Real CLI subprocess with no normalization layer | Depends on CLI | Whatever selected CLI supports | Often best for remote servers | Full native CLI config ecosystem | Full backend support | Weakest native Emacs integration; keybinding conflicts, TUI rendering, and clickable references may be awkward || elysium | Editing assistance, not full agent | No continuous autocomplete | Mostly explicit/project-assisted | Built around gptel editing workflows | Yes, through gptel | Backend-dependent | Similar to gptel | Inherits gptel config | No | Better classified as editing assistance than autonomous coding || chatgpt-shell | Partial/general LLM client | No native NES | Mostly explicit context | Emacs shell-like client calling model APIs | Multiple backends depending on setup | Usually API billing | Remote files possible; shell/tool routing varies | Prompt/config dependent | No native coding subagents | General chat client, not primarily a repo-wide coding agent || ellama | Partial/general LLM client | No native NES | Mostly explicit context | Emacs package calling local or remote model backends | Yes | Local models or provider APIs | Usually buffer-oriented | Prompt/config dependent | No | Not primarily a full repository agent || org-ai |
پستهای تلگرام — /r/emacs
Vague theme for emacs built on top of Modus themesHi all,I recently made the emacs port for the excellent vague theme. It is built on top of Modus themes and I've been daily driving it since then.Happy to hear feedback/suggestions. It would be great if people could try it and report issues on the issue tracker.Main repository: github.com/paniash/modus-vaguehttps://red…
Update Reddigg is now a fullblown reddit clientJust an update for one or two users of my reddigg package (github.com/thanhvg/emacs-reddigg). It has become a flullblown client. Beside reading, you should be able to submit a post, make a comment, upvote, downvote, edit your post, your comment... There is a dedicated minor mode which some of the users have been asking for but I was too lazy. Key bindings are not complete yet though.If you can see this post it means it works because I did it through reddigg.Okay here is the fine print:- you must have browsel github.com/dmgerman/browsel, btw many thanks to the creator of this awesome package.- you must have a reddit account, have your browser open old reddit and allow browsel to run on that tab.- reddigg will use browsel to drive the interaction with reddit through your browser.- llm code but lgtm :P- Don't think so but reddit might ban me and you. they closed the free access to old reddit recenly which led me to make this changeredd.it/1vqy5pn@r_emacs
What is emacs canvas and how does it work?Emacs Canvas (patch) on redditFrom my understanding of how programs draw to screens, it seems that Emacs canvas provides a video buffer to external graphics programs or libraries so that instead of drawing to the regular screen, they draw inside a video buffer created and displayed within Emacs.The equivalent I can think of is the case of VNC or Xpra where a program uses a $DISPLAY which is rendered remotely on the client.Would that mean that getting a program to run in a canvas would be along the lines:(emacs-create-canvas height width buffer-name "/usr/bin/random-gui-program -param 1 -param -2")?I suppose there would be some additional parameters relating to passing key strokes, controlling window movement and size etc.redd.it/1vqtjmi@r_emacs
emado: manage 100k+ markdown entries from Emacs at native speedredd.it/1vqtodk@r_emacs
Emacs AI assistants (results)Disclaimer: I'm not a heavy AI user, I'm just trying to understand the differences between AI harnesses specifically for Emacs and if using the real harness claude-code would even make a difference.I like agent-shell more than anything else I've tried in Emacs including ECA which I recently configured but never used for anything.Today I decided to give them both a try to a relatively complicated task (reviewing code) and oh boy, ECA was not only better but thousands of times better.They both are using the same model and configs so I feel I'm missing something here, agent-shell failed to trigger simple things as bufffer overflows while ECA correctly pointed out the issue and fix. I'm I missing something here? Anybody had experience with this kind of things?redd.it/1vqr0f9@r_emacs
Tempted to try Meow over Evil, but worried about IntelliJ / cross-editor muscle memoryI'm coming back to Emacs and I'm playing with Doom and vanilla configurations. I'm really tempted to ditch Evil and give Meow a proper shot. The selection-first model and native Emacs integration make a lot of sense to me, but I have one major hesitation: portability.At work, we use IntelliJ (I enabled IdeaVim). Sticking with Evil on Emacs means my muscle memory stays aligned between Doom/Emacs and my IDE. If I switch to Meow, I'm worried about the context-switching friction during the workday.Has anyone managed to port Meow-style bindings/selection mechanics to IntelliJ or found a solid way to bridge that gap? Would love to hear how others handle using Meow alongside non-Emacs tools at work.Thanks!redd.it/1vqkogz@r_emacs