Emacs-copilot: Large language model code completion for Emacs

Original Article ↗ Hacker News Discussion ↗

Emacs users are reacting to a new “emacs-copilot” plugin that brings GitHub Copilot‑style code completion to the editor using locally run large language models via Mozilla’s llamafile/llama.cpp stack. Commenters weigh the benefits of self‑hosted models for privacy, control and performance against cloud APIs, and debate interaction styles such as on‑demand versus constantly pushed completions. The project also prompts concerns over naming conflicts with existing Emacs Copilot clients, potential Microsoft trademark issues around “Copilot,” and the security model of distributing executable model bundles versus plain weight files.

Naming, trademarks, and confusion

  • The package name “copilot” is confusing because Emacs already has a GitHub Copilot client with a similar name.
  • Several comments discuss whether “Copilot” is or can be a Microsoft trademark and how that intersects with generic usage.
  • Some argue it’s fine as long as there’s no intent to confuse users or profit from brand confusion; others anticipate legal pressure regardless.

Architecture, llamafile, and performance

  • The package uses llamafile (llama.cpp inside an “actually portable executable”) to run local models.
  • mmap-based loading avoids fully reloading the model each time; first completion on a file is slower, subsequent ones are much faster thanks to a cache alongside the file.
  • Large models (e.g., 34B) are usable but slow; smaller quantized models like WizardCoder 13B or Phi-2 run acceptably on mid‑range machines.
  • Upgrading llamafile does not strictly require re-downloading weights; users can extract GGUF weights and re-pack them into a new binary or point a generic llamafile at external weights with -m.

Local vs remote / self‑hosted vs cloud

  • Strong enthusiasm for self‑hosted LLMs to avoid sending code to OpenAI/Microsoft and to retain control.
  • Some want to run models on LAN servers or via SSH; examples using ssh with call-process and llamafile’s HTTP APIs are discussed.
  • Others note existing tools like ollama and llama.cpp server already provide OpenAI‑style endpoints with streaming.

UX: on‑demand vs inline completions

  • Some users prefer the GitHub Copilot style: grey inline suggestions appearing automatically.
  • Others strongly dislike “push” completions, finding them distracting; they prefer explicit “think when I ask” interactions and being able to interrupt streaming.
  • There is agreement that configurability between push/pull modes would be ideal.

Ecosystem and alternatives

  • Multiple Emacs LLM packages are mentioned: gptel, ellama, chatgpt-related modes, llm.el, org‑integrated tools, and a GitHub Copilot client.
  • For Vim/Neovim, users mention gp.nvim, gen.nvim, and custom commands; some fork plugins to mix local (ollama) and remote models.

Security and trust

  • Some are wary of executable llamafiles vs “dumb” model-weight files, drawing analogies to unsafe pickle formats.
  • Others counter that llamafile is backed by a reputable organization and can also be used with external GGUF weights; threat models differ.

Setup issues and platforms

  • Several users on macOS and Asahi Linux hit vfork: Exec format error when Emacs launches llamafile.
  • Workarounds include using an “ape” interpreter, converting llamafiles to native binaries with “assimilate”, or running a Cosmo‑linked Emacs.

Debate on LLM usefulness

  • Some are enthusiastic, especially for Lisp and boilerplate-heavy work (e.g., modern React).
  • Others argue that reviewing and validating LLM output negates productivity gains for high‑quality production code, and worry about developers deflecting responsibility (“the model wrote it”).