Tool call output example

gistfile1.org

Review recent developments in LLM-related packages for Emacs. Both in the community and on emacs-devel

The first search got rate-limited. Let me do more targeted searches. I need to search for specific packages and emacs-devel discussions. Let me also check the emacs-devel archives directly.

Rate limited. Let me try reading some URLs directly for the key sources I found earlier, and also search more carefully with fewer parallel calls.

Good, I’ve gathered substantial information. Let me now look for emacs-devel specific discussions. Let me try fetching the emacs-devel archives directly or search more specifically.

Let me now try to get emacs-devel details specifically, and also look for what’s on the lists.gnu.org archive.

I found a very relevant thread on emacs-devel: “Rejection of LLM-generated code” by Stefan Monnier from June 2026. Let me fetch that thread. Also, let me look at earlier months for LLM-related threads.

I found the key emacs-devel thread. Let me now also look at some more related threads - that blog post reference is interesting. Let me also check the earlier months for LLM-related discussion and get the full picture. Let me look at that blog post about the LLM patch rejection policy.

Now I have a comprehensive picture. Let me also quickly check if there were earlier emacs-devel threads about LLM policy and also look at what the wider community landscape looks like. Let me also quickly check the March 2026 threads for LLM-related discussions.

Now I have a comprehensive picture. Let me also check if there are recent packages I haven’t covered like aider.el, elysium, copilot.el, ECA, etc. and also the emacs-devel LLM policy.

Let me now compile this into a comprehensive review. I have:

1. **Community packages landscape** - the ecosystem has exploded with many LLM packages
2. **emacs-devel discussions** - the LLM-generated code rejection policy and recent controversy

Let me organize this now.

## Community Packages

### Core/Foundation layer

• **llm** (GNU ELPA): Andrew Hyatt’s provider-agnostic library, used by ellama and others
• **gptel** (NonGNU ELPA): Karthink Chikmagalur’s versatile LLM client, v0.9.9.5 (May 2026), supports many backends, tools, MCP, presets, org-mode integration
• **ellama** (GNU ELPA): Sergey Kostyaev’s LLM assistant, v1.29.0 (Jun 2026), uses llm package, supports agent loops, DLP, tools, rich context, many providers

### Agent/Terminal integrations

• **agent-shell** (xenodium): major mode for terminal-based agent interfaces, supports ACP (Agent Client Protocol), Claude Code, Codex, Gemini CLI, Auggie, Copilot, Cursor, Droid, Goose, Mistral Vibe, OpenCode, Pi, Qwen Code
• **aider.el** (tninja): Emacs integration for Aider AI pair programming
• **claude-code.el** (stevemolitor): Claude Code integration

### Coding assistants

• **copilot.el** (copilot-emacs, maintained by Bozhidar Batsov): GitHub Copilot integration
• **elysium** (lanceberge): AI-powered coding assistant with inline diff application
• **ECA** (editor-agnostic): Clojure-based AI coding assistant using LSP-like protocol

### Other

• **ob-gptel**: Org-babel backend for gptel
• **chatgpt-shell** (xenodium): earlier ChatGPT integration
• Spacemacs **llm-client layer**: unified layer supporting gptel and ellama

### Key trends

• Move from simple chat to agentic workflows (tools, plan-and-act loops)
• ACP (Agent Client Protocol) as an emerging standard for editor-agent integration
• Local models via Ollama/llama.cpp becoming first-class
• Context management becoming more sophisticated
• MCP (Model Context Protocol) integration via mcp.el

## emacs-devel

### Key development: LLM-generated code rejection policy

• GNU Emacs has a policy against accepting LLM-generated/assisted code
• Stefan Monnier clarified (Jun 26, 2026): the policy is about copyright status, not legality of using LLMs. “It’s rejected on the same basis as we reject code whose author hasn’t signed the copyright paperwork.”
• This sparked controversy when Przemysław Alexander Kamiński’s NSColor cache patch was rejected because he honestly disclosed LLM assistance
• Kamiński wrote a blog post “Honesty gets Emacs patch rejected” (Jun 25, 2026) and stated he would stop contributing to Emacs
• Stefan Monnier noted the policy shouldn’t apply to NonGNU ELPA (since it doesn’t require copyright assignment)
• The policy is discussed on internal GNU lists, not publicly, which Kamiński criticized

### Other emacs-devel threads

• The gptel package commit thread in May 2026 (technical discussion about string-pixel-width)
• No other major LLM-related threads in recent months on emacs-devel beyond the rejection policy debate

Now let me write the review.

Here is a review of recent developments in LLM-related packages for Emacs, covering both the community package ecosystem and emacs-devel discussions as of mid-2026.

Community package landscape

The pace of LLM package development in the Emacs ecosystem accelerated significantly through late 2025 and into 2026. The landscape now divides roughly into three layers: provider-agnostic foundation libraries, general-purpose chat clients, and agent-oriented tools.

Foundation layer

llm (GNU ELPA) by Andrew Hyatt is the closest thing to a shared backend abstraction. It provides a uniform interface across OpenAI, Claude, Gemini, Ollama, GPT4All, LlamaCpp, Vertex, and OpenAI-compatible APIs. Both ellama and other tools build on it. Its presence on GNU ELPA makes it the natural dependency for packages that want to avoid locking users into one provider.

General-purpose clients

gptel (NonGNU ELPA, maintainer Karthik Chikmagalur) is the most mature and widely used general LLM client. Version 0.9.9.5 shipped in May 2026. Key capabilities:

• Works in any buffer, not just dedicated chat buffers. You can send buffer text, a region, or arbitrary context to a model and redirect output anywhere.
• Supports ~20 backends: ChatGPT, Azure, Gemini, Anthropic, Together.ai, Perplexity, Anyscale, OpenRouter, Groq, DeepSeek, Cerebras, GitHub Copilot Chat, AWS Bedrock, xAI, Sambanova, Mistral, Kagi, plus local models via Ollama, Llama.cpp, GPT4All, and any OpenAI-compatible API.
• Tool-use support via gptel-make-tool, with MCP (Model Context Protocol) integration through the mcp.el package.
• Presets: bundles of model, backend, system message, and tools that can be applied globally, buffer-locally, or per-request.
• Org mode integration: heading-scoped conversation context (gptel-org-set-topic), branching conversations via outline paths, and Org property-based configuration for reproducible chat notebooks.
• ob-gptel: an Org-babel backend that lets you write #+begin_src gptel blocks with :session, :prompt, :wrap src <LANG>, and other headers.
• In v0.9.9.3+, gptel-include-reasoning defaults to ignore – reasoning text from LLM responses is displayed but not re-sent on subsequent turns, following LLM API recommendations.
• In v0.9.9.3+, gptel-make-tool tools now default to including results in the buffer for coherent multi-turn tool use.

ellama (GNU ELPA, maintainer Sergey Kostyaev) is the other major client, and the one with the most aggressive development velocity. Version 1.29.0 shipped on 2026-06-26. It positions itself as “LLMs in Emacs without turning Emacs into a web app.” Key features:

• Built on llm, so it inherits all its backends (Ollama, OpenAI, Claude, Gemini, Vertex, GPT4All, LlamaCpp, etc.).
• Agent loops with plan-and-act: the LLM makes a checklist, calls tools, reads project context, and continues from the previous turn.
• First-class context management: requests can include buffers, files, directories, Info nodes, selections, images, and audio. Context can be persistent across sessions.
• Sessions: save, resume, rename, compact manually or automatically before hitting context limits.
• DLP (data loss prevention): filesystem checks, edit hooks, and DLP scans can block or warn on reads, writes, shell commands, and tool output.
• SRT (sandboxed runtime) support for autonomous operation within policy boundaries.
• ellama-setup-agentic-coding: one function to enable tools, enforce DLP, block irreversible actions, and configure longer agent loops. Reads project instructions from AGENTS.md.
• Rich everyday commands: translate, summarize, proofread, code review, code edit, commit message generation, format conversion.
• Audio: record from microphone, send to model, add to context.
• Blueprints and community prompts: templated prompt collections with variable filling.
• Active development cadence: multiple releases per month, with the latest (1.29.0) adding features around agentic coding defaults.

  Agent-oriented tools

agent-shell (xenodium) represents a different design philosophy: rather than building a chat client, it provides an Emacs major mode for interacting with terminal-based agent CLIs through the Agent Client Protocol (ACP). Supported agents as of mid-2026: Claude Code, Codex, Auggie, Copilot, Cursor, Droid, Gemini CLI, Goose, Mistral Vibe, OpenCode, Pi, Qwen Code. Sessions are namespaced by directory and model name. ACP lets these terminal agents use Emacs as a first-class frontend with proper editing and keybindings.

aider.el integrates the Aider AI pair-programming tool into Emacs.

copilot.el (maintained by Bozhidar Batsov since early 2026) provides GitHub Copilot integration.

elysium (lanceberge) offers inline diff application from AI suggestions, closer to the Cursor-style experience.

ECA is an editor-agnostic AI coding assistant built in Clojure, using an LSP-like protocol, supporting both Emacs and Neovim.

Consolidation signals

Spacemacs now ships an llm-client layer that provides unified configuration for both gptel and ellama, suggesting these two are seen as the primary options. Skye Freeman’s widely-circulated April 2026 post “How I’m using LLMs via Emacs” describes a two-tool setup: agent-shell for heavy agentic work and gptel for quick queries and documentation – a pattern that appears to be converging among power users.

emacs-devel: the LLM-generated code policy

The single most significant emacs-devel development in this area is the controversy around GNU’s policy on LLM-generated or LLM-assisted contributions.

The policy: GNU Emacs rejects code that is LLM-generated or LLM-assisted. Stefan Monnier clarified on 2026-06-26 that the rationale is copyright status, not legality of LLM use: “It’s rejected on the same basis as we reject code whose author hasn’t signed the copyright paperwork.” The concern is that LLM-generated code does not have a clear copyright provenance that can be assigned to the FSF.

The incident: Przemysław Alexander Kamiński submitted a performance patch (NSColor cache for macOS, 92 lines) to emacs-devel in late June 2026, explicitly noting that the issue was found and the patch drafted by GLM 5.2 (an open-weight Chinese model). He reviewed, modified, and tested the patch, declared authorship, and took full responsibility. The patch was rejected under the policy.

The fallout: Kamiński published “Honesty gets Emacs patch rejected” on 2026-06-25, making several arguments:

• The policy punishes honesty: he could have hidden LLM usage and the patch would likely have been accepted.
• The copyright argument is inconsistent: if the same model were run locally (open weights), the “SaaS is closed” objection evaporates.
• The policy discussion happens on internal GNU lists with limited transparency.
• He announced he would stop contributing to Emacs and released ~40 additional performance patches on GitHub outside the GNU process.

The nuance: Stefan Monnier noted the policy “makes no sense to apply to NonGNU ELPA” since NonGNU packages do not require copyright assignment. This creates an asymmetry: LLM-assisted code can enter the Emacs ecosystem through NonGNU ELPA but not through core Emacs or GNU ELPA.

Your involvement: You (Ihor) participated in the emacs-31 branch discussion (2026-06-27) and the NSColor cache thread (2026-06-26), though not in the LLM-policy subthread itself. The Org meetup #27 (Feb 2026) and #28 (Mar 2026) both touched on LLM topics: LLM patches in Org context, gptel tools, agent-shell, and using embeddings for Org note linking.

The policy remains in place as of July 2026, with the underlying legal question unresolved and community discussion continuing mostly outside the official lists.

[Disclaimer: This review is based on publicly available mailing list archives, package repositories, and blog posts through early July 2026. The internal GNU discussions about LLM policy are not publicly archived, so the full reasoning behind the policy may include factors not visible here.]