Geekinney

外观

Emacs 社区日报 2026-09-10

约 5109 字大约 17 分钟

2026-09-10

自动整理自 Telegram 讨论组，每天更新。内容为 AI 摘要，仅作信息索引与回顾。

Emacs 社区日报 2026-09-10 手绘图
Emacs 社区日报 2026-09-10 手绘图

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：Agent Shell 与 ACP 生态的现状与争议

群里对 Agent Shell（代码执行工具）的流畅性赞誉有加，但焦点集中在 ACP（Agent Client Protocol）协议的发展困境上。参与者认为 ACP 是最大的瓶颈——"没人管的状态"、"ACP跟不上agent发展的速度"，甚至调侃"这玩意可还是JetBrains做出来的"。讨论围绕几个痛点：

  • 协议扩展不足：有人抱怨 ACP 支持的命令太少，但有参与者指出 ACP 已提供 custom request 机制（如 /side、/btw、在对话中间 fork session），只是"适配有成本"。
  • 维护责任缺失：当被问及"各大 coding agent 的 acp 有人维护吗？"时，有人回应"你自己用 AI 维护呗，都是开源的"，并建议用 Mux 包一层隔离，避免 Emacs 崩溃影响 Agent 运行。
  • Agent Shell 与第三方工具兼容性：有人询问 opencode 和 codex 对 Agent Shell 的支持情况，但未得到明确答复。
  • 生态建议：有人呼吁"来加入 agent shell，为 ACP 生态做贡献"，但被"没空"和"如果开源赞助有我现在工资的一半我就考虑跑路了"调侃回应。

专题：Emacs 的 ebox 与 etaf —— 文本分层渲染的新可能

群友分享了 Emacs 新特性 ebox（文本盒子堆叠效果）和 etaf（更惊艳的后续版本）的进展。讨论核心在于其实现原理：

  • 技术亮点：ebox 将所有内容以文本和文本属性存放在同一个 Buffer 中，实现通用的分层显示文本功能，支持水平像素裁切，未来可能支持图片。
  • 性能对比：有人认为这比 Child Frame 管理更方便，且性能更好，但有人提出"Child Frame 第一次启动总会卡一下"的痛点。
  • 适用场景：参与者建议 ebox 更适合只读 Buffer 中的交互（如按钮点击、按键行为），而非作为补全弹窗替换窗口区域文本——"这种补全弹出的窗口，本质上会替换窗口区域的文本，当窗口消失时还要恢复，不够优雅"。

专题：Emacs completion style 配置调优

群友分享了自己在 orderless 与 flex 之间的配置纠结，并贴出完整配置代码，推荐使用 completion-category-overrides 针对不同 category（如 file、eglot）分别配置。核心观点：

  • 路径匹配：不要看到 / 就认为是 file category，可能是 project-file，需仔细查看 orderless 文档。
  • 风格取舍：有群友指出 orderless 和 flex 是两种风格，不应混用；有人建议在 orderless-flex 前加 orderless-literal。
  • 体验反馈：有人提到 Sublime 的匹配"超好用"，想研究其实现，但也有人吐槽"Sublime 买了之后用了不到 50 小时"，并盛赞其 org 插件还原度极高。

🔑 关键概念与技术解析

  • ACP (Agent Client Protocol)：JetBrains 推出的用于 Coding Agent 与 IDE/编辑器交互的协议。支持 custom request 扩展（如 /side、/btw），但生态维护不足，跟不上 Agent 发展速度。
  • ebox / etaf：Emacs 的文本分层显示功能。ebox 支持文本盒子的堆叠与交互，etaf 是其后续版本，预期更惊艳。原理是在同一 Buffer 中通过文本属性实现分层显示，而非使用 Child Frame。
  • Steering a running turn：在 Agent 会话运行中插入或转向的能力，用于在不打断 Agent 干活的前提下调整上下文。

💎 碎片知识与金句拾遗

  • "直接给 ai 打钱" —— 对开源赞助的调侃回应。
  • "如果开源赞助有我现在工资的一半我就考虑跑路了" —— 关于开源维护者生存现状的戏谑。
  • "child frame 管理起来会比较麻烦，这个是所有的内容都是文本和文本属性在同一个buffer里面显示。做了一个Buffer里面通用的分层显示文本的功能。" —— ebox 实现原理的精炼总结。
  • "增量更新很丝滑" —— 对 ebox 动态效果的赞叹。
  • "连续点击的时候，CPU维持在50%左右，停止之后降到了 2% 以内。我是MBP M1。" —— ebox 的性能实测数据。
  • "多按一下空格的事（" —— 对 flex 匹配问题的幽默处理。
  • "我买了 sublime 之后，可能就用了不到 50 个小时" —— 对工具选择的真实吐槽。
  • "sublime 上的 org 插件，是所有里面，对 org-mode 还原得最好，甚至 agenda 部分有所超出" —— 对 Sublime org 插件的高度评价。

🛠️ 值得深入研究的点 (Follow-up)

  • ebox / etaf：值得进一步研究其在只读 Buffer 中的交互设计（按钮点击、按键行为）以及图片支持（水平像素裁切）的实现细节。
  • ACP custom request 扩展：如何为 Agent Shell 添加自定义命令（如 /side、fork session），以及如何用 Mux 隔离 Agent Shell 与 Emacs 的依赖，值得深入探索。
  • orderless 与 flex 的组合策略：针对不同 completion category（如 file、project-file、eglot）的匹配风格配置，值得参考并测试。
  • telega-rc：有人打包了 telega（一个 Emacs 的 Telegram 客户端），群友称为"win emacs 打包侠"，但未展开讨论，可进一步了解其在 Windows 下的打包方式。

观点延伸

今天最值得咀嚼的，不是 Emacs 又能接多少 Agent、画多少层界面，而是：功能接通之后，谁负责状态正确，谁承担持续维护？ ACP 的争论与 ebox 的演示，看似一后端一前端，其实都到了同一道工程门槛：能展示，不等于能依赖。

1. ACP 缺的未必是命令，而是可检验的语义

群里从“支持的命令太少”争到 custom request，又从“已经支持 fork”追问到“能否从历史位置分叉”。这个转折很关键：名字相同，不代表行为相同。 从当前末尾分叉、从历史节点分叉、中途转向，改变的是不同的上下文边界，不能因为都能发消息就算支持。

我的判断是，评价适配器应少列命令，多列行为契约：分叉继承哪些消息？分叉之后的新消息是否隔离？运行中的补充何时生效？不支持时是否明确拒绝？扩展机制解决的是“允许接”，不是“两端理解一致”。让 AI 补代码可以降低初次适配成本，却不能免掉升级后的回归责任；没有行为测试，自由扩展很容易变成各自方言。

2. Agent 活着，不等于工作可恢复

“用 mux 包一层，Emacs 坏了不影响 Agent”是当天很实在的建议。但沿着它再走一步：进程隔离只回答任务会不会停，不回答重连后能否知道它干了什么。

真正值得验收的是：编辑器断开期间的输出能否补齐，待确认操作能否恢复，重连是否误触发重复执行。编辑器可以是控制台，不该是任务状态的唯一保管者。 这不是主张马上重写一套后台，而是提醒：长任务的可靠性，应通过主动断连测试证明，不能从“终端还在”推导出来。

3. ebox 的价值，要用阅读操作来验收

群里既有“增量更新很丝滑”，也有滚动慢、正在优化的反馈。它们并不矛盾：局部更新与连续滚动是两种负载，单次 CPU 观察也不能证明整体性能优于 Child Frame。

只读 Buffer 的建议因此很重要：先避免与实时编辑争夺文本状态，把分层显示用于阅读和按钮交互。不过，对知识界面而言，漂亮还不够。还要验证搜索能否定位、复制顺序是否合理、键盘能否遍历、更新后阅读位置是否稳定。否则，“杂志排版”可能只是把可操作的文本变成了难用的展板。

可继续研究／实践

先做两组小型验收，而不是继续加功能：Agent 侧测试历史分叉与断连重接，核对上下文和执行次数；ebox 侧固定同一份长文，测试滚动、搜索、复制与局部更新。用失败案例划清能力边界，比演示再多一个按钮更能推动生态成熟。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：ebox 发布前的技术打磨与协作

今日群内围绕 ebox（一个 Emacs 文本盒子布局库）的开发和发布展开了大量讨论。作者已初步实现相对/绝对定位布局，底层是通用的 buffer 文本图层实现，支持任意多层文本盒子的覆盖与切换层级。群友对 ebox 的动态交互能力表示了浓厚兴趣，并申请参与 alpha 测试。作者为此临时将私有仓库暴露到公网（通过阿里云主机转发），并临时创建测试账号供群友体验。讨论中还对比了 Ebox 与 ETAF（更高级的组件化框架）的定位差异——Ebox 提供底层布局能力，而 ETAF 提供组件化、模板指令、数据驱动响应式写法等更接近前端 JS 框架的体验。有群友评价“ebox 最大的魅力在最小化增量更新”，并强调“按需取用，这就是我把 ebox 独立出来的原因”。

专题二：omarchy 的体验与生态观察

群内多人尝试了 omarchy（基于 NixOS 的 AI 操作系统），对其主题切换器、系统一致性、Agent 自动配置能力给予好评。讨论焦点包括：

  • 主题切换体验极佳，系统各方面一致性很好。
  • 配合 Agent 自动解决问题（如配置中文输入法）的效果令人满意。
  • 也有吐槽：每次操作都必须进入 launcher 选单略显繁琐；子菜单未被列入搜索范围（不如 macOS 搜索系统设置方便）；鼠标/键盘偶尔失灵的问题。
  • 群友提到 quickshell 作者被招募（“有钱还是好啊，直接把人家quickshell的作者招安了”），并讨论了 quickshell 内存占用过高的问题（noctalia v4 曾达 300-500M，新版本降至 100-150M）。hyprland 作者未被招募的原因也被顺带提及（其与跨性别团体的争议）。

专题三：DeepSeek V4.1 Flash 发布引发热议

DeepSeek V4.1 Flash 正式发布并开源，引发群内高度关注。主要亮点：

  • 模型底座从 284B 增至 552B（近翻倍），但采用全新“Causal-Encoder-Decoder”架构，输入激活仅 8B、输出激活 16B，大幅降低推理成本。
  • KV Cache 用量缩小 13.7 倍，显著降低 Agent 任务成本。
  • 官方宣称“全面超越 DSv4 Pro 0812”，群友实测速度极快（“速度快到想哭”“秒出”），并有多人尝试通过 dsh、Pi、opencode 等工具接入使用。
  • 有群友反馈官网网页版可免费无限使用 v4.1 flash，适合处理小问题。
  • 群友“梁圣”被评价为“拿到卡了还是优化了算法”，提速效果明显（如 git commit message 从半天变秒出）。
  • 相关开源项目被提及：DeepSelect（提速 2-20 倍）和 DeepGEMM 的 PR。

专题四：AI 模型与工具生态的忠诚度讨论

围绕“模型是否有用户忠诚度”展开了一场精彩的讨论。核心观点：

  • “vibe coding 是没有用户忠诚度的”——模型可随时替换，用户不在乎背后是谁。
  • 但“agent 是有忠诚度的”——一旦习惯某个 harness（如 codex），更换成本较高。
  • 模型与 harness 都是可插拔件，流行的做法是将 GPT 接入 Claude 使用，或将各种模型接入同一 harness。
  • 讨论延伸至国内外 AI 竞争格局：国内模型（DeepSeek、Kimi）价格优势明显，且差距在缩小；但“大力砖飞是否到头”尚无定论。也有观点认为企业效率瓶颈不在写代码，AI 对企业的实际效率提升有限。

🔑 关键概念与技术解析

  • jj sparse v2：jj（Jujutsu）版本控制系统的稀疏集（sparse set）新设计。有群友发现 sparse v2 已支持路径选择与映射规则，即可以将同一目录映射到多个项目的子模块目录，用 jj 的 snapshot 同步变更，从而解决多项目共享依赖但无法拆分的问题。群友感叹“原来 sparse v2 就是这样设计的，有点小丑了”——这与其独立构想的设计不谋而合。

  • Causal-Encoder-Decoder 架构：DeepSeek V4.1 Flash 采用的新模型架构。相比传统 encoder-decoder，它通过仅激活部分参数（输入 8B、输出 16B）来降低推理成本，同时保持相近表现。核心思路是让模型在推理时只处理必要信息，从而大幅提升吞吐量。

  • KV Cache 压缩：DeepSeek V4.1 Flash 将 KV Cache 用量缩小 13.7 倍，直接降低了 Agent 等长上下文任务的成本。这是其在性价比上碾压竞品的关键。

  • quickshell vs noctalia：两者都是 Wayland 合成器/Shell 的实现方案。quickshell 表现力强但内存占用大（一个 shell 比 WM 还多），noctalia 则自研 shell，内存占用大幅降低（100-150M），但表现力略逊。omarchy 将 quickshell 作为基建，但群友对其性能表示担忧。

  • dsh：疑似一个 DeepSeek 相关的 CLI 工具或脚本（上下文不完整），用于调用 DeepSeek 模型。群友提到“通过 dsh 调用 ds4.1”“npx 这个命令你执行了没”“pip 的包是坏的，npm 是好的”——说明该工具存在多种安装方式，且 npm 版可能更稳定。

💎 碎片知识与金句拾遗

  • “沒有主題也是主題”——某群友的洒脱之语，关于主题管理。
  • “我把 ebox 独立出来的原因：按需取用”——作者对 ebox 设计哲学的概括。
  • “有钱还是好啊，直接把人家quickshell的作者招安了”——对开源作者被商业公司招募的感慨。
  • “怀念三个 Claude 20x Max 的账号给我用的时候”——对过往高配额账号的怀念。
  • “模型和harness都是可插拔件”——对 AI 工具生态的精准概括。
  • “国内模型写代码已经不错了，而且 AI 用户忠诚度为零”——对国产模型崛起的观察。
  • “企业效率瓶颈本来就不在写代码上”——关于 AI 在企业应用的冷思考。
  • “优秀模型无法产生足够优势击败竞争者，国产模型很快就会追上，差距越来越小”——对国内 AI 发展速度的判断。
  • “月之暗面的关于页面居然放了一个可以弹奏的钢琴 🎹”——有趣的细节，附有演奏脚本：https://gist.github.com/miantiao-me/b6477d762d5cf4cd1da4fadc776343b7
  • “DeepSeek 官网注册登录，网页版无限免费使用 v4.1 flash”——实用省钱技巧。
  • “知乎全是 AI 泔水……AI 泔水别点进去，给点负反馈”——对 AI 生成内容泛滥的吐槽。
  • “我要穿越回大一给自己一拳，天天读点破书没一点用”——某群友对求学时光的感慨。
  • “keybr.com 上练习指法，wpm 提升后字词输入变得很快”——Rime 输入法讨论中的实用建议。
  • “Rime 没有云输入，更适合用确定性强的输入法，以字词为单位”——对 Rime 方案的理解。
  • “宣布‘没有AI’后，一周下载破100万！”——某应用以“无 AI”为卖点走红，群友评论“no ai 成老外的政治正确了吗”。
  • “我很讨厌 AI 写的文档”——直接了当的观点。
  • hyprland 作者“在推上经常阴阳怪气不喜欢/说 hyprland 缺点的人”——关于其争议行为的描述。
  • codex“一直是 Rust”——回答“codex 已经重构到 Rust 了”的疑问。
  • “国外 AI 说实话就是靠无限资源支撑，但这种投入始终有上限”——对 OpenAI 模式的反思。

🛠️ 值得深入研究的点 (Follow-up)

  • ebox：作者即将发布，支持相对/绝对定位布局、多层级文本盒子堆叠、动态交互。可关注其 alpha 测试与后续发布。依赖：ecss、tp、ekp。
  • DeepSeek V4.1 Flash 技术报告：https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash/blob/main/DeepSeek_V41_Tech_Report.pdf——值得深入研读其 Causal-Encoder-Decoder 架构与 KV Cache 压缩方案。
  • DeepSelect：https://github.com/deepseek-ai/DeepSelect——据称可提速 2-20 倍，或与模型推理优化相关。
  • jj sparse v2 的路径映射能力：可关注 jj 在 monorepo 和 submodule 管理上的创新，尤其是“路径选择与映射规则”的设计思路。
  • omarchy 的 Agent 配置流程：群友展示了“一句话配置好 fcitx+rime+雾凇输入法”的用例，值得跟踪其 Agent 系统的设计与实现。
  • dsh：群友提到“用 chromium 包装的启动器（PWA）”，且 npm 包优于 pip 包，但具体项目信息不完整，值得进一步调查。

观点延伸

今天最值得连起来看的，是 ebox 的“按需取用”和 Agent 的“模型可插拔”。两场讨论指向同一个判断：好的工具允许替换实现，却不要求用户重建工作习惯和验收标准。 但模块拆开了、接口接通了，并不代表这个目标已经实现。

1. ebox 的价值，要用“没被打扰的东西”证明

群友把“最小化增量更新”看得比布局和 CSS 更重要，这个判断抓住了 Emacs 的使用现场：buffer 不只是画布，也是用户正在操作的工作空间。

由此延伸，ebox 值得验证的不只是盒子能否覆盖，而是局部更新时，光标、选区、窗口位置以及其他包附加的文本属性是否保持合理。视觉上只变了一小块，不等于底层没有整片重写；底层写入少，也不等于交互状态没有被破坏。

独立于 ETAF，是依赖边界的第一步；让使用者不必接受整套组件模型，也能得到可预测的更新行为，才是抽离基础库的实质收益。基础库的成熟度，不在演示有多复杂，而在它对别人的状态有多克制。

2. 模型能换，不等于工作流能无损迁移

“模型没有忠诚度，Agent 有”描述了真实的使用倾向，但还不是技术结论。当天既有模型提速的兴奋，也有重复输出、执行停住，以及“源码都没拉下来，AI 就说不用”的反馈。

这些现象提示：用户依赖的可能不是某个界面，而是一套已经摸熟的失败处理方式——何时打断、哪里找证据、怎样接着做。换模型后，如果这些预期全部失效，接口兼容也只是接线成功。

因此，可插拔应该由任务回归来证明：面对相同仓库和验收条件，替换后能否正确读取材料、完成修改、运行测试，并在失败时留下可接手的状态。一次提交说明“秒出”，不能替代这些证据。

3. 提速是否增效，要看验收端

群里“企业瓶颈不在写代码”的提醒有价值，但不能直接推成“AI 不会提升企业效率”。更可检验的判断是：生成加速后，需求澄清、审查和返工是否吞掉了节省的时间。

个人知识系统也一样。更快生成笔记，不等于更快形成理解；如果来源核对更费劲，只是把等待输出换成了清理输出。

可继续研究／实践

做两组小回归：ebox 对比局部更新与完整重绘，检查结果一致性、交互状态和耗时；Agent 固定任务与验收条件，替换模型并重复运行，记录完成时间、人工介入和返工。前者验证“少改而不乱”，后者验证“换芯而不失控”。这比继续争论哪个框架更强、哪个模型更快，更接近工具真正的价值。