Geekinney

外观

Emacs 社区日报 2026-06-29

约 5854 字大约 20 分钟

2026-06-29

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

Emacs 社区日报 2026-06-29 手绘图
Emacs 社区日报 2026-06-29 手绘图

Emacs 中文讨论组

好的，群友。以下是基于今日聊天记录整理的知识库。

🎯 核心热点与专题探讨

今日讨论围绕两大阵营展开：“Emacs 作为一切”的硬核深度定制 与 “工具各司其职”的外部工具派。此外，针对 AI 辅助开发的“用”与“驭”也是核心话题。

【专题一】一切皆可 Emacs：无限扩展的边界与代价

核心分歧点：是否应该在 Emacs 内集成浏览器（xwidget-webkit）和 Shell (agent-shell)。

  • “整合派”观点（以 zdn/neomacs 作者等为代表）：

    • 痛点导向： 外部终端在“查找复制粘贴”、“编辑复杂输入”、“管理大量窗口”等场景下效率低下。Emacs 内部的 agent-shell 能无缝调用 sudo tramp、docker tramp 等编辑特权文件，这是外部工具无法比拟的。
    • 技术探索： 讨论了在 Emacs 中通过 xwidget-webkit 实现浏览器体验的艰难历程：
      • 核心矛盾： WebKitGTK 2.42 移除了 Emacs xwidget 依赖的 off-screen 渲染支持。
      • 解决方案： 群友通过自行 patch WebKit 源码并提交 PR，成功恢复了支持并加入了 localStorage 支持（例如能用 Discord 网页版）。
      • 未来野心： 探索浏览器插件支持（受限于 GTK4 依赖），甚至有人开始尝试将 pgtk 后端移植到 GTK4 以获取更好的 WebKit 支持。

  • “外部工具派”观点：

    • 信条： “最合适的工具做最合适的事情”。
    • 反驳： Kitty + tmux 极其强大，性能卓越，且有 copy mode 和 tmux 的 session 保持能力。认为 agent-shell 作者的作品“缺乏打磨”。
    • 不同场景决定选择： 他们认为，如果用 AI 只是“动嘴皮子”，只输入十几个字，用外部工具完全够用。而 Emacs 内部的终端效率优势，体现在需要“编辑输入内容”、“与文件深度交互”、“管理大量 tab”的重型工作中。

  • 结论： 没有绝对正确的选择，关键在于使用场景。Emacs 整合一切的理念，带来了极致的统一体验，但伴随着高昂的维护成本和性能开销；而外部工具链则在特定场景下提供了更高的性能和稳定性。

【专题二】AI 时代的 Emacs：降低门槛与新的争吵

  • 核心洞察： AI 极大地降低了定制 Emacs 的门槛。许多以前“有想法，但因为要写 Elisp 而搁置”的功能，现在可以轻松实现。
  • 积极影响：
    • 群友表示“现在半小时搞定（一个包），还能时不时花十分钟改进一下”。
    • 以前需要“大佬”维护的复杂插件，现在个人也能借助 AI 魔改或创作。
    • magit 作者甚至可能用 AI 分析性能问题。
  • 消极争论：
    • 工具选择：“LLM in CLI” vs “LLM in Emacs”。 前者如 Claude Code (或 pi.*)，后者如 codex-ide.el、agent-shell、gptel、gptel-agent、gptel-subagent。讨论并未达成一致，反而突显了用户工作流的不同。
    • 控制权： 一位群友尖锐指出，agent-shell 作者的项目“缺乏打磨”、“不听建议”，AI 生成的代码如果不理解，只是“表象测试”，心里不踏实。这直接指向了 “AI 辅助开发 vs 代码控制权” 的深层矛盾。
  • 一个尖锐的比喻： “每个月给 AI 花钱，我就当我谈了个女朋友。被封号了就是对方提分手？” 形象地反映了对 AI 服务不稳定性和成本控制的无奈。

【专题三】Magit 性能优化：一场与冗余渲染的战争

  • 核心问题： Magit 在大型仓库上速度慢，尤其体现在 Windows 平台和 diff 大量文件时。
  • 解决方案探索：
    • 直接对抗： 通过重写 magit-status-sections-hook，跳过对 unstaged 和 staged 文件的 diff，只在用户手动选择时才进行 diff。
    • 特效对抗： magit-diff-fontify-hunk 开启后，与 indent-bar、rainbow-indent、auto-dim-other-buffers 等插件产生严重冲突，导致显示异常（如注释消失、颜色错乱）。
    • 替代方案： 推崇原生 vc-dir 和 dired 下的 C-x v d diff 体验，因为其速度“太快了”。甚至有群友怀疑其直接读取 .git 文件夹而非调用 git 命令。
    • 配置建议： 使用 once.el 进行空闲时增量加载，关闭不必要的 font-lock，或用 magit-delta 代替内置 diff 渲染。

🔑 关键概念与技术解析

  • xwidget-webkit: Emacs 内部的一个基于 WebKitGTK 的浏览器组件。允许在 Emacs buffer 中直接渲染网页。其稳定性依赖于特定版本的 WebKitGTK，近期因上游移除 off-screen 渲染支持导致维护困难，但有群友通过 patch 修复。
  • WPE (Web Platform for Embedded): 一个新的 WebKit 变体，不依赖 GTK，有希望在 Emacs 中提供更现代化的浏览器集成体验。
  • pgtk (Pure GTK): Emacs 的纯 GTK 后端，旨在解决 X11 下的各种缩放和显示问题。目前有群友尝试将其移植到 GTK4。
  • once.el: 一个 Emacs 包，用于实现“理想的”增量加载（idle loading），支持自定义加载优先级，特别适合优化 magit、org 等首屏慢的包。
  • agent-shell: 一个 Emacs 插件，提供一个集成度极高的 Shell buffer，支持 AI 补全、tramp 集成、窗口管理等功能。其作者作品风格被评价为“功能强大但缺乏打磨”。
  • gptel-agent / gptel-subagent: gptel 包的扩展功能，允许创建和管理多个 AI agent 进行协作或并行任务，代表 Emacs AI 领域向 Agent 化发展的趋势。
  • pi-subagent: 另一个基于 pi (可能是某个 AI 工具或框架) 的 subagent 插件，常与 DeepSeek 结合使用。
  • neomacs: 一个用 Rust 实现的 Emacs 复刻，后端采用 winit + wgpu（图形 API）。目标是无缝替换 Emacs，并在所有平台（包括 iOS/Android）提供一致的 GUI 体验，目前处于 v0.0.8 早期开发阶段。

💎 碎片知识与金句拾遗

  • 社区智慧： “你不用 WebKitGTK 了？那你怎么用 Google 登录？哦，Google 明确禁止受应用控制的嵌入式 user-agent 登录（WKWebView 等也受限）。”
  • 开发纪实： “为 Emacs 移植 pgtk 到 GTK4 实在太难了。Pgtk 之前放弃过。Neomacs 作者把 gtk3, pgtk 全删了，统一用的 winit+wgpu。”
  • 幽默自嘲： “每个月给 AI 花钱，我就当我谈了个女朋友。被封号了就是对方提分手？能申请退款就是要回来彩礼……”
  • 设备升级感悟： “对不起，我这就升级设备。……从 intel Macbook 升到 m4，Emacs 启动时间减少一半，简直是神器。以前卡顿（magit/org）的都是你设备太落后。”
  • 冷门工具发现： dired-collapse-mode 可以一键折叠 Java 项目那种冗长的 src/main/java/com/... 路径层级，秒杀查找器。同场还有 gt.el，被点赞为“几乎完美”的翻译后端，极少代码就能实现在 mu4e 邮件中显示 overlay 翻译。
  • 深刻观点： “AI 写代码输出的无用代码堆起来特别快。最怕的是代码失控，自己都不知道如何验证 PR 的功能，只能从表象测试，心里始终不踏实。只有自己掌握代码才能心里踏实。”
  • 开发者生态观察： “由于 GitHub 默认作者不 watch repo 变动，提 issue 作者也收不到邮件。现在有一种作者似乎自己都不用 Emacs 的感觉。” 精准点出了开源项目维护中的沟通困境。

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

  • neomacs (Rust 实现的 Emacs): 极有潜力的项目。v0.0.8 已发布，目标是多平台统一 GUI（winit+wgpu），并计划移植到 iOS/Android。准备在 macOS/Linux 上尝试 -Q 模式运行体验其基本能力。
  • Emacs 的 PGTK -> GTK4 移植: 这是一个极其硬核的 hack，目标是利用 GTK4 的优势（如更好的 WebKitGTK 支持）。任何相关预研或进展都值得关注。
  • tmux 3.7 的 Floating Panels: 这是一个重大的实用增强。可以在 Emacs 的任何位置创建临时的、非模态的悬浮面板，极大地扩展了 Emacs 的窗口管理能力。虽然目前仅支持鼠标，但潜力巨大。
  • emacs-china.org 上的 WPE 方案讨论: 群里提到有人尝试用 WPE (Web Platform for Embedded) 替换 WebKitGTK，以获得更纯净、更可控的浏览器引擎集成。这是一个从根上解决 xwidget 依赖问题的重要方向。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“Emacs 里能不能塞浏览器/终端/Agent”，而是一个更硬的工程判断：工具整合的价值，不取决于它看起来多统一，而取决于它能不能把高频摩擦变成可验证的控制面。

1. “一切皆 Emacs”不是信仰，是摩擦账本

群里关于 xwidget-webkit、agent-shell、Kitty/tmux 的争论，本质不是审美差异，而是工作负载差异。

如果你的 AI 使用方式只是“说十几个字，让它跑”，外部终端、tmux、Claude Code 足够好；复制、恢复 session、开 tab 都能解决。但一旦任务变成重型：编辑长 prompt、反复修改 shell 脚本、在输出里搜索、把终端结果和文件 buffer 互相引用、用 TRAMP 进 sudo/docker 环境，Emacs 内部终端的优势就不是“情怀”，而是减少上下文切换和中间态丢失。

所以判断标准很简单：别问“能不能放进 Emacs”，问“放进去之后，是否减少了可测的操作步骤、错误率和恢复成本”。如果不能，就只是把浏览器或终端重新造一遍；如果能，那就是把 shell、编辑器、文件系统、AI 对话收敛成同一个操作平面。

2. AI 让 Emacs 更有活力，也让失控更便宜

群里那句“以前一两天搁置，现在半小时搞定”非常关键。AI 确实降低了 Elisp 扩展门槛，让个人 workflow 可以快速长出小插件：dired 图标、mode-line、美化、翻译 overlay、AI agent 接口。这会让 Emacs 这种可塑系统重新获得生命力。

但另一句更重要：“最怕的是代码失控，自己都不知道如何验证 PR 实现了什么。”这才是 AI 编程的工程边界。AI 不是把维护成本消灭了，而是把“生成成本”打到接近零，于是维护债会以更快速度堆起来。10-20 行写完、单文件限制、测试约束、harness，这些不是洁癖，而是对抗失控的最小治理结构。

3. 可维护性比集成度更稀缺

xwidget-webkit 需要 patch WebKit、GTK4 才有插件支持、PGTK 迁移很难；Magit 卡顿要拆 section hook、关 font-lock、避开 face 冲突。这些都说明：深度集成的收益越大，对底层边界的理解要求越高。

可继续实践的方向：给自己的 Emacs/AI workflow 建一个“摩擦审计表”——记录每个集成点节省了哪些操作、引入了哪些维护依赖、如何回退、如何测试。凡是无法测试、无法回退、无法解释的 AI 生成扩展，先不要让它进入长期配置。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：AI 模型生态的“迁徙”与经济博弈

群内对 AI 模型的讨论呈现出明显的“迁徙”现象与价格敏感特征。核心议题集中在Codex、Claude、DeepSeek V4 的性价比与用户体验上。

  • 迁徙潮： 一条生动的“生态讽刺”叙事被群友广泛转发，描述了开发者每月在 Claude 和 Codex 之间“迁徙”的荒诞现实——因额度枯竭、模型跑分变化、新模型发布等触发，且迁徙途中与反向迁徙者擦肩而过，互不询问。这被戏称为“硅基自然的法则”。
  • Codex vs. Claude： 有群友认为“codex相比claude感觉现在更划算些了”，但也有用户吐槽 Codex（GPT-5.5）的上下文窗口仅有 272K（API版为1M），认为“272 实在有点少了”。Claude 一方则被提及因“A\”做太多坏事”而获得高评价（诚实率高）。
  • DeepSeek V4 涨价： 官方宣布 V4 正式版将引入“高峰时段”（9:00-12:00, 14:00-18:00）涨价机制，输入/输出价格翻倍（从 0.025->0.05 元，6->12 元/百万tokens）。群友对此反应复杂：“预览版，正式版。有啥区别？用来涨价”、“虽然不爽，不过好像还是便宜，算了...”。同时，群内出现一个名为 Dao Code 的项目，声称通过高度缓存命中（达 95.8%）可将 DeepSeek V4 的单次完整功能开发成本压缩至 ¥0.15 左右，比 Claude 旗舰模型便宜约 18-30 倍，引发讨论。

专题二：Emacs 生态圈的技术抉择与坑

群内围绕 Emacs 的几个具体技术问题展开了深度讨论。

  • Telega（Emacs Telegram 客户端）的 NixOS 适配之痛： 用户在 NixOS 上配置 telega 时遇到问题。通过群友协作诊断，问题根因在于：
    1. NixOS 默认的 telega 包来自 melpa stable，可能过老。
    2. telega 当前版本只适配了 tdlib 1.8.64，而最新版 NixOS 的 tdlib 已更新，版本不兼容导致部分功能（如链接预览）失效。 解决方案： 最佳实践是从源码自行编译 telega 及对应版本的 tdlib，或使用非 stable 的 melpa 源。
  • Dotfiles 管理方案与 Nix 生态： 有群友提出跨机使用 dotfiles 的痛点，咨询管理方案（stow vs. XDG 目录化 vs. bare git vs. 声明化模板）。最终群友倾向于使用 Nix 的 home.file 参数进行声明化管理，认为这是“加钱解决”的终极方案，并分享了相关链接供参考。

专题三：浏览器新势力与老牌工具进退

群内讨论了 Arc 浏览器的替代品及一些“逃难”趋势。

  • Arc 替代选项： 多位群友推荐或询问 Dia 浏览器作为 Arc 的替代品。讨论点包括：Dia 的交互与 Arc 的差异（如标签分组功能是否如 Arc 般直观）、快捷键一致性（shift+cmd+c 复制 URL）、以及地域访问问题（Dia 需要将多个域名走美国节点，否则无法登录，被群友吐槽“烦人”）。
  • Brave 的信任危机： 有群友透露已从 Arc 转向 Brave，但近期传出 Brave 也“偷传数据”，导致部分用户考虑进一步迁移到更激进的版本（如 Chrome Canary）或 Firefox（因其支持自动标签分组）。

专题四：《沉星之序》与吹哥的游戏哲学

  • 游戏推荐与背景故事： 群友讨论并推荐了由知名游戏设计师“吹哥”（Jonathan Blow）团队开发的新作《沉星之序》。讨论焦点：
    • 技术背景： 该游戏使用了吹哥团队自创的编程语言开发，开发周期很长。
    • 性能与体验： 游戏对性能有一定要求，集显或 Mini PC 低配体验不佳（卡顿），但优化潜力尚存，可能因赶工导致。
    • 关联社区： 吹哥本人是 Emacs 用户，游戏在 Hacker News 获得高评价，其 YouTube 频道也被群友关注。

🔑 关键概念与技术解析

  • telega & tdlib： telega 是 Emacs 上最流行的 Telegram 客户端。tdlib 是 Telegram 官方提供的底层库，用于与 Telegram 服务器交互。在 NixOS 等滚动发行版上，系统自带的 tdlib 版本可能超越 telega 所支持的版本，导致功能异常（如链接预览缺失），需手动版本对齐。
  • DeepSeek V4 前缀缓存： 一种针对 LLM 推理的优化技术。如果用户的输入 prompt 前段（前缀）在缓存中已存在（例如全局使用的系统提示、工具描述），则这部分 token 的计算成本会大幅降低（DeepSeek 的命中价约为未命中的 1/120）。通过精心设计 prompt 结构，可以显著提升缓存命中率，大幅降低使用成本。
  • Dao Code： 一个强调极致成本控制的 AI 编程代理项目。它通过将系统前缀、工具表、记忆等结构化地“铺排”在 prompt 的固定位置，最大化利用 DeepSeek 的前缀缓存机制，声称可实现极高缓存命中率（>95%），从而将每次编码任务成本降至 0.15 元人民币级别。
  • Codex / GPT-5.5 上下文限制： Codex（GitHub Copilot 的底层模型）基于 GPT-5.5，但其 Web/App 版本的上下文窗口被限制在 256/272K tokens 左右，而通过 API 调用可达到 1M tokens。这解释了为何某些高频或长上下文任务在 Web 版 Codex 上表现受限。

💎 碎片知识与金句拾遗

  • 关于群聊 ID 的诠释： 本群名称的灵感来源被揭示——“readme视频里有 jj (”，直指一个硬核程序员社区的幽默。
  • Hacker News 的字体美学： 有群友吐槽“hackernews的字体太小了，都要放大看”，随即有人澄清“这个是 Emacs 里面的（用 elfeed 或 eww 浏览），可以自己设定字体大小”。
  • “先锋书店”的网红抵抗： 为防止网红扎堆打卡，先锋书店竟然把门牌去掉了。
  • AI 模型的“雨季”与“旱季”： “deepseek 很缺人呀。竟然直接在官方首页放这么大个招聘。” -> “不止缺人，现在看来还缺利润）”、“快上市了。财报要弄好看点”
  • “不能说的秘密”： 一位群友分享了在群友分享过的隐蔽实操经验后，称“我最近跨机使用愈发多了...好像没得选，想加钱解决了”，反映出程序员面对复杂环境的“加钱当躺平”心态。
  • AI 工具的“异化”用法： “用用那种qwen 27B之类的好了” -> “我用过，很拉胯，通用任务不行”，揭示了开源本地模型在通用性上的不足，以及其在特定任务中的可能生态位。
  • 关于游戏《沉星之序》的细节： “我关注作者十年了，在 twitter 上看到的”、“吹哥的游戏，吹哥是 Emacs 用户”、“造了个新语言写的”。

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

  1. Dao Code 项目的缓存策略实现： 该项目通过 prompt 编排实现高达 95.8% 的缓存命中率，其核心技巧（如“逐字节稳定”铺排系统前缀、工具表、记忆）和具体的 fork 机制是值得深入研究的方向。这代表了 AI 编程代理领域极致的成本优化范式。
    • 关注点： 访问其 GitHub 链接/evals/runs/ 目录下的 cost log，研究其 prompt 结构设计。
  2. NixOS 下的 Emacs 与 tdlib 版本锁定： NixOS 声明式系统下，如何精确锁定 telega 与 tdlib 的版本匹配，是一个值得关注的技术实践。这涉及到构建自定义 flake 或使用 overlay 覆盖系统包。
    • 关注点： 参考群友“自己编译 tdlib”的建议，以及 tdlib.github.io/td/build.html 官方编译指南，在 NixOS shell 中复现。
  3. Dia 浏览器的代理策略需求： 该浏览器需要特定域名走美国节点才能登录，这可能与它的认证后端、存储策略或用户基础架构部署有关。对于需要多地区测试或隐私强保护的开发者而言，了解其对代理的深层依赖是一个兴趣点。
    • 关注点： 查看其官网 diabrowser.com 和 diabrowser.engineering 域名的解析与联通性配置逻辑。
  4. 吹哥的自研编程语言： 开发《沉星之序》所使用的自研语言，其设计哲学、与 Rust/C++ 的差异、以及它对游戏性能的影响（特别是性能瓶颈处），值得关注。
    • 关注点： 关注吹哥的公开演讲或博客，了解该语言的立项初衷和最终未采用主流方案的原因。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“Codex、Claude、DeepSeek 谁更强”，而是一个更硬的判断：AI Agent 正在从“模型崇拜”进入“运行时工程”阶段。谁便宜、谁上下文大、谁诚实率高，当然重要；但真正决定长期可用性的，是你能不能把成本、上下文、版本、环境这些变量纳入可控系统。

1. “迁徙”不是用户善变，而是缺少稳定控制面

群里那段“每个月在 Codex 和 Claude 之间迁徙”的笑话很准。开发者并不是不知道对岸的草未必更绿，而是当前 AI coding 订阅形态把人训练成了游牧民族：额度快用完就迁、模型榜单变了就迁、价格策略改了就迁。

工程上这说明一件事：如果你的 Agent 工作流绑定在某一个闭源前端、某一种会员额度、某个不可控上下文窗口上，它就不是基础设施，只是消费品。可验证的判断标准不是“今天哪个模型感觉聪明”，而是：同一个任务能否在不同模型后端复现？成本、失败率、上下文消耗、人工介入次数能否被记录？如果不能，迁徙永远会发生。

2. Dao Code 真正有意思的不是便宜，而是把 prompt 当构建产物

Dao Code 被提到的高缓存命中率，表面看是“DeepSeek 便宜再砍一刀”；更深一层，是它把系统前缀、工具表、记忆这些 Agent 结构做成“逐字节稳定”的缓存友好布局。这和传统软件工程里的 reproducible build 很像：不要每次都即兴拼装环境，而是让可复用部分稳定、可变部分隔离。

所以它的价值不该只用“¥0.15 一次任务”来评价。更应该看三项指标：缓存命中率是否稳定；任务变复杂后命中率是否崩；省下来的钱有没有换来更差的上下文适配和修复质量。便宜不是护城河，可测量的 prompt/runtime 结构才是。

3. telega + NixOS 的坑，和 AI Agent 是同一个问题

telega 只适配到特定 tdlib 版本、NixOS 包版本不匹配导致链接预览异常，看似是 Emacs 小坑，其实和 AI 工具链完全同构：上层体验坏了，根因在底层依赖漂移。解决方案也不是“多试几个包”，而是版本锁定、源码编译、overlay、声明式配置。

这也解释了为什么群里 dotfiles 最后自然滑向 Nix/home.file：跨机使用到一定程度，手工同步一定会输给声明式系统。AI Agent 也一样，AGENTS.md、工具定义、模型配置、缓存策略、测试命令，最终都应该变成可版本化的工程资产。

可继续实践的方向

把下一轮 AI coding 评估从“哪个模型更爽”改成一个小型 harness：固定 5 个真实维护任务，记录模型、上下文长度、缓存命中、总成本、测试是否通过、人工修正次数。再配一份可复现的 Agent 配置。能被复测的体验，才有资格叫工程判断；不能复测的，只是本月迁徙路线。