Emacs-copilot：面向 Emacs 的大语言模型代码补全
Emacs 用户正在回应一个新的“emacs-copilot”插件，它使用通过 Mozilla 的 llamafile/llama.cpp 技术栈本地运行的大语言模型，为编辑器带来类似 GitHub Copilot 的代码补全。评论者权衡了自托管模型在隐私、控制权和性能方面相较云端 API 的优势，并讨论了按需触发与持续推送补全等交互方式。该项目还引发了对与现有 Emacs Copilot 客户端命名冲突、“Copilot”可能涉及 Microsoft 商标问题，以及以可执行模型包而非纯权重文件分发时的安全模型的担忧。
命名、商标与混淆
- 包名“copilot”令人困惑，因为 Emacs 里已经有一个名称相似的 GitHub Copilot 客户端。
- 一些评论讨论了“Copilot”是否是或能否成为 Microsoft 的商标，以及这与通用用法之间如何交叉。
- 有人认为，只要没有故意误导用户或利用品牌混淆牟利就没问题；也有人预期无论如何都会面临法律压力。
架构、llamafile 与性能
- 该包使用 llamafile（把 llama.cpp 放进一个“实际上可移植的可执行文件”里）来运行本地模型。
- 基于 mmap 的加载避免了每次都完整重新加载模型；由于文件旁边的缓存，某个文件上的第一次补全更慢，之后的补全会快很多。
- 大模型（例如 34B）可以使用，但速度较慢；像 WizardCoder 13B 或 Phi-2 这样的较小量化模型在中端机器上运行得还可以。
- 升级 llamafile 并不严格要求重新下载权重；用户可以提取 GGUF 权重并重新打包到新的二进制文件中，或者用
-m把通用 llamafile 指向外部权重。
本地 vs 远程 / 自托管 vs 云端
- 大家强烈支持自托管 LLM，以避免把代码发送给 OpenAI/Microsoft，并保留控制权。
- 有人希望在局域网服务器上或通过 SSH 运行模型；讨论了使用
ssh配合call-process以及 llamafile 的 HTTP API 的示例。 - 其他人指出，ollama 和 llama.cpp server 等现有工具已经提供了带流式输出的 OpenAI 风格端点。
UX：按需 vs 内联补全
- 一些用户更喜欢 GitHub Copilot 的风格：自动出现的灰色内联建议。
- 另一些人非常不喜欢“推送式”补全，觉得它们会分散注意力；他们更偏好显式的“我问了再思考”交互，并且能够中断流式输出。
- 大家都同意，若能在 push/pull 模式之间提供可配置切换就最好了。
生态系统与替代方案
- 提到了多个 Emacs LLM 包：gptel、ellama、与 chatgpt 相关的模式、llm.el、与 org 集成的工具，以及一个 GitHub Copilot 客户端。
- 对于 Vim/Neovim，用户提到 gp.nvim、gen.nvim 和自定义命令；有人还 fork 了插件，以混合本地（ollama）和远程模型。
安全与信任
- 有些人对可执行的 llamafile 持谨慎态度，而不是“傻瓜式”的模型权重文件，并拿不安全的 pickle 格式作类比。
- 其他人则反驳说，llamafile 背后有可信赖的组织支持，而且也可以与外部 GGUF 权重一起使用；威胁模型各不相同。
设置问题与平台
- 一些在 macOS 和 Asahi Linux 上的用户在 Emacs 启动 llamafile 时遇到
vfork: Exec format error。 - 解决办法包括使用 “ape” 解释器、用 “assimilate” 将 llamafile 转换为原生二进制文件，或者运行一个用 Cosmo 链接的 Emacs。
关于 LLM 有用性的争论
- 一些人对此很兴奋，尤其适用于 Lisp 和大量样板代码的工作（例如现代 React）。
- 另一些人则认为，在高质量生产代码中，审查和验证 LLM 输出会抵消生产力收益，并担心开发者会推卸责任（“是模型写的”）。