The state of agentic coding tools in Emacs (2026)# The State of Agentic Coding in Emacs — 2026 Comp…
انتشار: 2026/07/14 22:07 UTC
The state of agentic coding tools in Emacs (2026)# The State of Agentic Coding in Emacs — 2026 ComparisonThis is a current-state comparison of Emacs AI coding tools and integrations. The goal is to distinguish full coding agents, editor frontends, protocol clients, autocomplete systems, and wrappers around external CLIs.Legend- Full: can inspect a repository, edit multiple files, run commands/tests, and iterate.- Editing: project-aware multi-file editing, but not necessarily a complete autonomous command/test loop.- Partial: some agent-like behavior, often dependent on configured tools.- Backend: capability comes from the external CLI or agent.- FIM: fill-in-the-middle completion.- NES: Next Edit Suggestions.- Automatic scope: the tool can search/discover relevant repository files.- Explicit scope: the user normally supplies files, buffers, or context.| Tool | Agentic coding | Autocomplete / NES | Project-wide scope | Model / agent interaction | Multiple providers | Auth / billing | Remote / TRAMP | Persistent instructions / skills | Subagents / parallelism | Main limitations ||---|---|---|---|---|---|---|---|---|---|---|| gptel | Partial through tool calling | No native continuous autocomplete; no true NES | Explicit by default; automatic with suitable tools | Emacs calls provider APIs directly; optional Elisp and MCP tools | Yes | Usually provider API keys or local/OpenAI-compatible endpoints | Remote buffers work, but shell/file tools require careful routing | System prompts, directives, project-local config | Not native; possible through tools/extensions | Not a standardized coding agent by default; capabilities vary heavily by user configuration || gptel-agent | Full | No native continuous autocomplete; no true NES | Automatic within the current project; can read, write, edit, search files, use Bash, access the web, and inspect Emacs | Implemented as a gptel preset containing prompts and tools; gptel calls the selected provider API directly and can also use MCP tools | Yes, through gptel | Usually provider API keys or local/OpenAI-compatible endpoints supported by gptel | Can operate on remote buffers, but filesystem and Bash tools must be configured so they execute against the intended remote host rather than locally | Built-in agent and planning presets; custom agents can be defined in Markdown or Org files with their own prompts, tools, model, backend, and API parameters | Yes; can delegate to specialized context-isolated subagents and run them in parallel | Requires a current development version of gptel; uses significantly more tokens than ordinary gptel; most write, edit, Bash, and Emacs actions require confirmation by default; remote execution behavior requires careful configuration || macher | Editing | No | Automatic project search/read | Uses gptel backends and project-editing tools | Yes, through gptel | Same as selected gptel backend | Works at Emacs/project layer; remote execution may need care | Inherits gptel prompts/config | No native subagents | Strong controlled patch workflow, but not equivalent to an autonomous terminal agent repeatedly running tests || macher-agent | Full, experimental | No | Automatic | Model backend plus sandbox/worktree orchestration | Yes, backend-dependent | Backend-dependent | Sandbox/worktree placement complicates remote use | Project prompts plus backend config | Yes; asynchronous subagent orchestration | Young project, smaller ecosystem, less production history || mevedel | Partial to editing | No continuous autocomplete; no NES | Project/tool dependent | Uses gptel APIs, directives, and tools | Yes, through gptel | Backend-dependent | Similar concerns to gptel | Directives, reusable instructions, project state | Agent/workflow support; maturity varies | Broad workbench rather than one standardized agent architecture || agent-shell | Backend; usually full | No | Usually automatic, depending on selected agent | Emacs ACP client → ACP server/adapter → real agent or CLI | Yes |
پستهای تلگرام — /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