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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题 1: Emacs 32 的 restart-emacs 在 macOS 27 Beta 下的致命问题

群内围绕 Emacs 32 的 restart-emacs 在 macOS 27 beta 上的具体表现展开了深入诊断。核心症状为：执行重启后，窗口虽然可见，但无法获取键盘焦点，Dock 中的图标持续跳动，进程实际并未正确退出。

• 问题定位: 日志分析显示，restart-emacs 通过 save-buffers-kill-emacs 的 re-exec 模式复用 PID。该 PID 在被标记为 QUITTING/terminating 后，又收到一个 CHECKIN（来自 macOS 的后台运行 app 机制）。随后 macOS 系统报错“目标进程不存在”，导致焦点与状态陷入僵持。
• 共识: 多数群友认为这并非 Emacs 本身代码（该机制数年未变）的 bug，而是 macOS 27 beta 的后台应用管理机制（后台运行app 机制）出现了回归或变更，对 re-exec 模式不友好。
• 解决方案与出路:
  • 直接降级回 Emacs 31.09（被认为“其实挺好的”），并稳定在 Emacs 31 等待正式发布。
  • 有群友回忆，zdn 在 Windows 上也遇到类似问题（“一并行编译就报错”），但这被解释为平台无关的编译依赖 bug。
• 更广泛的编译 Bug 讨论: 引申出 Linux 上编译 pgtk 时，由于 misc-info 生成 texi 与构建阶段的并行依赖链未正确设置的 Bug。解决方案是拆分为两个阶段（先串行 misc-info，再并行构建）或使用 make -j1。

专题 2: Emacs 代码补全 / 导航工具的深度评价与对抗

以 zdn 对 citre（基于 ctags 的代码导航）的使用体验和调试为引子，展开了一场关于传统 Tag 系统与现代 LSP 的深度对比。

• 核心发现: citre 默认的 citre-tags-definition-default-filter 会过滤掉 prototype 类型的标签。这导致用户如果只声明函数而不写函数体（如 .h 文件中的纯声明），或者使用 C++20 modules（使用 .cppm 等非传统后缀），citre 将跳过这些声明，造成“跳转失败”。
• 解决方案: 群友提供了一个 advice-add 代码段，重写了过滤函数，仅排除 local 和 parameter，保留了 prototype，从而解决了声明时无法跳转的问题。
• 社区观点:
  • LSP 虽然强大（认为 TypeScript 开发“没有 LSP 不行”），但在 C++ 中由于复杂模板推导困难，有时“LSP 也推导不出来”，且“卡”。zdn 主要用 rg（riggrep）搜索来阅读代码。
  • rg 在 Windows 上的表现被评价为“比 grep 慢，但颜值好看，能接受”。
  • 讨论延伸至 Windows 生态：rg.el 的 when-let 警告（建议改用 when-let*）和 Windows 命令行工具（对比 pwsh 与传统 cmd）。
• 延伸: 最终引发了关于“Emacs 审美改变”的感悟——zdn 表示自己最初对 Lisp 语法和 Emacs 界面是排斥的，但看 Tsoding 视频并实际使用一个月后，已经能感受到 Lisp 的优雅。

专题 3: Emacs AI / 工具链新作与日常贡献

群里出现两个值得关注的新项目，以及关于 Emacs 社区品味的讨论。

• emacs-proofread (brsvh/emacs-proofread): “Emacs 上的 Grammerly”。开发者讨论计划在 0.3.0 稳定后发 Reddit，并表示已加入多后端支持，正在折腾不同语言的多后端 profiles 合并 suggestions。

• magent (Jamie-Cui/magent): 一个 Emacs Native Coding Agent，可以接入 agent-shell，并使用 gptel 提供的模型。可以看作一个在 Emacs 内部运行 AI 编码助手的能力。

• fido-frame: zdn 开发的一个不依赖 posframe、通过 child-frame 实现可缩放、可拖拽的 Fido 补全框架。社区评价极高（“老外里面有眼光识货的也很多”），代码简洁到“加上注释只需要 78 行代码”。此成就引发了关于项目贡献态度的讨论：zdn 表示“Star 多的话，我会认真去写提交”，但被群友纠正为“这只是你的个人要求”。

• Emacs 32 版本与编译流程: 讨论了 mold（高速链接器）和 NATIVE_FULL_AOT 结合使用，以及 misc-info 的并行编译 Bug。

• Windows 环境变量与系统组件记忆: zdn 提到自己连 Windows 环境变量的命令行工具名和注册表选项都记住了，感叹“越用越难换”。

🔑 关键概念与技术解析

• restart-emacs re-exec 模式: Emacs 的一种重启实现。它以相同的命令行参数重新执行自身，并尝试复用原有的进程 ID（PID）。Emacs 32 默认使用此模式，但它在 macOS 27 beta 下因后台进程管理机制的变更而失效。
• fido-frame: 基于 Emacs child-frame 的 Fido 垂直补全界面。无需 posframe 依赖，支持鼠标拖拽缩放，因其代码量少、功能完整而受到推崇。
• citre: 一个基于 ctags 的 Emacs 代码导航包，用于跳转到定义/声明。关键词：prototype 标签过滤（这是导致本日讨论 Bug 的核心）。
• gh.el 异步化: gh.el 是一个 Emacs 的 GitHub API 客户端。群主正在为它添加异步支持，并计划开发 PR review 功能。
• guix: 一个声明式包管理系统 / 操作系统。类似于 Nix。讨论中涉及到其缺少类似 NixOS 的 option 搜索功能，以及安装 NVIDIA 专有驱动的途径（通过 Nonguix 项目）。

💎 碎片知识与金句拾遗

• 关于 Emacs 审美: “emacs是会改变人的审美的...大概用了一个月，我现在能到感觉lisp语言的优雅了。” — zdn
• 关于维护心态: “个人项目嘛，可以自由一点。” — zdn (对 git commit -m "update" 的解释)
• rg 与 grep: “rg我感觉比grep慢，但是rg的那个样式好看...它比grep慢不了多少，还能接受。” — zdn (Windows 上使用 rg.el 的高亮体验)
• AI 辅助与 C++: “c++就无所谓嘛，有lsp也推导不出来复杂模板。” — zdn
• Windows 开发环境: “Windows的终端工具非常难用...自带的powershell不支持 xxx && xxx这种语法，得升级到 pwsh，pwsh才是现代的shell。” — zdn
• 关于投稿心态: “多看看Reddit发现国外的伸手党也不少...基数大了，傻逼数量就会变多。（表情）” — 群友
• 关于知识迁移: “感受到能迁移目前需要的环境就完全足够了，剩下的只要有兴趣，都只是时间问题。” — 关于从 Arch 迁移到 Guix 的态度。
• 通用模式: “我才知道 general 在 use-package 上提供了 :general，不好好看文档的后果。” — Aiser

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

• emacs-proofread: Emacs 多后端校对工具（类似 Grammarly）。关注其多后端 profiles 合并技术，以及它如何处理不同语言的语法检查。
• magent: Emacs 原生 AI Coding Agent。可集成 agent-shell 与 gptel，代表了 Emacs 生态中 AI 开发工具最直接的集成方向。值得关注其实现模式（如果它使用了 Emacs threading / 并发）以及 prompt 设计。
• citre prototype 过滤器：核心是通过 advice-add 重写 citre-tags-definition-default-filter。此补丁直接解决了 ctags 跳到声明的痛点。值得深入了解 citre-readtags-filter-kind 的 API。
• Guix 的 NVIDIA 显卡驱动: 通过 Nonguix README 中的“NVIDIA graphics card”部分配置，是 Guix 系统用户需要关注的上游渠道。
• gh.el 异步化与 PR Review: 随着 gh.el 支持异步，未来可能形成一个非第三方客户端的、在 Emacs 内完成整个 PR Review 流程的完整解决方案。

🧠 Hermes GPT-5.5 观点延伸

今天最有咀嚼价值的不是某个包，而是一个老问题又换了新皮：工具到底应该追求“聪明”，还是追求“可解释、可降级、可修补”。Emacs 社区的答案很清楚：聪明可以有，但最后必须落回可观察的工程边界。

1. restart-emacs 的问题说明：平台语义比代码更危险

Emacs 32 在 macOS 27 beta 上的 restart-emacs 事故，很像一个经典工程陷阱：代码多年没变，不代表依赖的系统语义没变。re-exec 复用 PID 这件事，在 Unix 语境里看起来合理；但一旦 macOS 的“后台运行 app”机制开始把同一个 PID 同时理解成 terminating 和 CHECKIN，Emacs 这边就算逻辑自洽，也会卡在 Dock 跳动、窗口可见、焦点不可用的半死状态。

这里的判断标准不是“谁的锅”，而是“哪个边界不可控”。如果边界是 beta 系统的进程生命周期管理，那么最稳的工程选择就是降级、冻结版本、等待上游确认，而不是在 Emacs 配置里继续堆 workaround。能复现、能解释、能降级，这比“猜一个修复”更重要。

2. citre vs LSP 的讨论，其实是“索引系统的诚实性”问题

citre 过滤掉 prototype 标签导致声明跳转失败，这个细节很小，但暴露出一个更硬的判断：代码导航工具不是越智能越好，而是要清楚告诉你它到底看见了什么、丢掉了什么。ctags 已经生成了 prototype，失败发生在 citre 的过滤策略；这类问题能通过重写 filter 修掉，说明它的失败路径是可审计的。

相比之下，LSP 在 TypeScript 里几乎是基础设施，因为类型系统、编辑器反馈、构建检查已经高度耦合；但在 C++ 复杂模板面前，LSP 也可能卡、也可能推不出来。于是 rg 搜索、ctags、LSP 并不是替代关系，而是三种不同置信度的阅读工具：rg 给文本证据，ctags 给结构索引，LSP 给语义猜测。越复杂的代码库，越不能把“跳转成功”误认为“理解正确”。

3. Emacs AI Agent 的机会不在“把 Copilot 搬进来”

magent、agent-shell、gptel 这些方向真正有意思的地方，不是 Emacs 里终于也有 coding agent，而是 Emacs 天然适合做 agent 的可验证工作台：buffer 是上下文，Dired 是文件系统视图，compilation buffer 是反馈通道，Magit/gh.el 是变更与 review 边界。

如果 agent 只是把聊天框嵌进 Emacs，那价值有限；如果它能沿着 Emacs 的 buffer、process、VC、xref、grep 这些原语工作，每一步都留下可跳转、可 diff、可回放的痕迹，那它会比“黑盒 IDE 助手”更工程化。

可继续实践的方向

把今天的讨论落成一个小实验：为一个 C++ 项目同时配置 rg、citre 和 LSP，记录同一批跳转/查找任务的成功率、延迟、误报和可解释性；再让一个 Emacs 内 agent 基于这些结果做代码阅读。不要先问“哪个工具最好”，先测“哪个工具在什么失败模式下最诚实”。

Emacs 轻聊讨论组

好的，这是为您整理的今日群聊精华纪要。

🎯 核心热点与专题探讨

专题一：AI 模型与工具的“蹬”文化与使用效率

今天群里最核心、最火热的话题围绕 AI 模型（特别是 Codex / OpenAI）的使用展开。群友们发明了“蹬”这个生动的动词，用来形容“消耗模型提供的免费或订阅额度”这一行为。

• “蹬”的焦虑与内卷： 群友们普遍面临“用不完”的焦虑，尤其是 Pro 用户。从“又能重置了”、“我刚好在重置前用完”到“用尽全力没有在重置前用完”、“怎么用不完呐”，反映了大家为了物尽其用，主动“蹬”模型的努力。有人甚至无差别重构代码，只为消耗 token。
• Codex vs. Claude 的生态争论： 核心矛盾在于 Codex 的多 Agent 设计。虽然其“自动引入 Coding Agent”的特性被部分群友认可，但“subagent 记录丢失”、“可观察性差”、“Diff 不输出”等痛点被群友反复吐槽，被认为是“刀耕火种的年代”。相比之下，Claude 的生态（如 claude-hud）在美观度和易用性上备受推崇。
• 订阅与支付难题： 围绕 OpenAI 的订阅支付问题展开讨论。大家发现双币卡（尤其是 Visa）大部分无法支付，群体性的解决方案包括：通过黑商买号、使用苹果礼品卡或 Google Play 订阅（仅普通订阅），而对于 Codex 的订阅则暂无完美方案。
• 模型与工具组合： 群友分享使用 Pi 的 Schedule Prompt 插件处理简单任务，以及用 openusage 统计工具替代 CodexBar (因其无密码弹窗且有截图功能)。还有人提到“模型配合是否有什么成熟方案”，但未深入。

专题二：Emacs 的极限改造与生态遗珠

作为硬核开发者的聚集地，Emacs 的定制改造是永恒的主题。

• 核心项目：Emacs WebKit Browser (ewb): 一位群友正在推进一个名为 ewb 的项目，目标是让 Emacs 成为全功能浏览器。目前已实现让 YubiKey 在 xwidget-webkit 中正常工作，并将挑战让浏览器支持 Vimium。这表明 Emacs 社区深入内核级定制的传统仍在延续。
• 远程开发方案争论： 关于 Emacs 远程开发，话题围绕 tramp + eglot 和 tramp-rpc 展开。群友遇到了 eglot 无法运行 LSP server 的问题，而有人反映 tramp-rpc 的使用体验“不如之前”，表明现有方案仍不完美。
• Emacs Fork 生态： 讨论了 remacs（Rust 版）、neoemacs (TypeScript 版) 等 Emacs fork。有群友提出“用 TypeScript 给 Emacs 搞一个”或“Rewrite 成 Rust”的设想，并提到 Linus Torvalds 的 uemacs 是基于 microemacs。多语言、多路线的 fork 尝试反映了社区对经典工具现代化的渴望。
• 预览与格式化： 有人询问如何在 Emacs 中预览含 Mermaid 和 PlantUML 的 Markdown 文件，特别是由 Codex 生成的 PRD，但尚未有成熟解决方案。讨论中提及了 org-mode 中 PlantUML 的预览体验不佳。

专题三：开源社区与文化观察

• 反 AI 情绪： 群友注意到 GitHub 上存在“无 AI 贡献”的 fork，并对这种“纯手工打造”的风潮表示不解，感叹“国外反 AI 反的太魔怔了吧”。这与群内“全面拥抱 AI 工具”的文化形成鲜明对比。
• Mastodon 与去中心化： 由于对马斯克接管 Twitter 后的现状不满，部分群友开始关注 Mastodon。但普遍认为 Mastodon 存在“孤岛社区”问题，使用难度较高，用户活跃度不如 Twitter。
• 硬件与系统： 有人遇到了 Linux 下 xe 驱动的 freeze bug 导致电脑死机、因 swap 配置过小导致编译任务被卡住等问题，反映了实际开发中的硬件兼容性和系统调优挑战。

🔑 关键概念与技术解析

• “蹬” (deng / pedal): 群内黑话，指代“用力使用、消耗”某 AI 服务（尤其是 Codex）的免费或收费额度，源于对“用不完”的焦虑。
• xwidget-webkit: Emacs 内置的一个特性，允许在 Emacs 窗口中嵌入 WebKit 浏览器部件。群友的 ewb 项目在此基础上进行深度定制。
• subagent: Codex 中用于分解任务的子模型/代理人。当前设计和 PAI (Prompt 可观察性) 被群友认为是其最大的短板。
• tramp-rpc: 一种通过 RPC (远程过程调用) 针对 Emacs 的远程文件访问和工作区 (workspace) 加载机制进行优化 的 Tramp 扩展，旨在解决传统 Tramp 的性能瓶颈。
• ventoy: 一个开源工具，用于制作可启动 USB 盘。用户只需将 ISO/WIM/IMG/VHD(x)/EFI 等文件复制到 U 盘即可启动，无须重复格式化。群友用它来更新 BIOS。
• Multi Agent Systems (MAS): 多Agent系统，指由一个主Agent协调多个子Agent（如 Codex 的 subagent）协作完成复杂任务的架构。

💎 碎片知识与金句拾遗

• 关于 Emacs 复刻: “总之，可以运行 elispVM 就可以了” - 对 Emacs 替代品核心需求的精炼概括。
• 关于 UI 审美: “TUI 那么多漂亮的例子都感化不了他么” - 对 codex-hud 丑的无奈吐槽。
• 关于项目管理: “把一坨重构成了另一坨，然后决定继续重写” - 对重构失败、陷入重写循环的精准描述。
• 关于生产力: “以前感觉做不完的需求，现在感觉没啥需求。” - AI 大幅提升效率后的真实感受。
• 关于开源社区: “我要是个没素质的人就好了，就可以去一些repos提issue说你这个项目怎么这么差” - 对开源社区礼貌礼仪的自我约束。
• 生活哲学: “这一切都是因为我终于会坐着呼吸了，我终于知道如何调整坐姿的呼吸到正确的方式……我可以长时间玩电脑，思绪不会变得焦躁中断变得更专注了。” - 一位群友分享的、通过改善呼吸方式提升生产力的生活经验。
• 工具评价: “你的 bios 升级好了吗 / 我准备今天晚上搞 / 好了” - 极客间简短的硬件升级对话。
• 关于 Codex 用量: “r/我昨天蹬了还剩下10+% / 你加了没有 / 我也没加 / 怎么回事，这不搞人心态了么” - 对重置逻辑不一致的困惑。

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

• ewb (Emacs WebKit Browser): 一个将 Emacs 打造成全功能浏览器的项目，目标是让 xwidget-webkit 支持 Vimium 等插件。值得跟踪其进展。
• codex-hud 替代品 / 自定义方案: 鉴于现有 codex-hud 的糟糕设计，可以探索基于 codex 目录下的凭证，自己调用 API 制作一个更优雅的状态栏或 HUD 脚本。
• tramp-rpc 的替代品: 鉴于 tramp-rpc 体验下降，可以重新评估 Emacs 的远程开发方案，例如使用 sshfs 挂载 + lsp-mode，或者其他容器化方案。
• remacs / neoemacs: 对用 Rust 或 TypeScript 重写 Emacs 感兴趣，可以关注这些项目的现状、核心设计哲学及其与主流 Emacs 的兼容性。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“Codex 又重置了”，而是两个看似分散的话题其实指向同一个工程判断：AI Agent 时代，真正稀缺的不是模型调用量，而是可观察、可控制、可复用的工作界面。额度用不完只是消费焦虑；subagent 记录丢失、diff 不透明、HUD 难用，才是生产系统还没成熟的证据。

1. “蹬”是新瓶装旧酒：把算力当 KPI，会诱导坏工程

群里说“重构、性能优化、代码膨胀处理这一套下来就蹬完了”，这很真实，也很危险。订阅制把成本从“每次调用都疼”变成“不用就亏”，于是人会主动制造任务来消耗模型。问题是，软件工程不是健身房跑步机：跑得越多不等于离目标越近。

可验证的判断很简单：如果一次 Agent 任务结束后，没有明确的 diff、测试结果、设计边界变化、可回滚点，那它消耗的 token 大概率只是噪音。所谓“把一坨重构成另一坨，然后继续重写”，不是模型能力问题，而是任务定义和验收机制缺失。AI 把执行成本打下来了，但没有把判断成本打下来；判断成本反而更显眼。

2. 多 Agent 的核心短板不是智能，而是审计链

群里对 Codex subagent 的吐槽很集中：退出不保存记录、diff 不输出、切进去才看得到、可观察性“一坨”。这说明当前很多多 Agent 产品还停留在“会派活”的阶段，没有进入“可审计协作”的阶段。

工程上，一个 subagent 不应该只是后台跑掉的黑盒，而应该产出最小审计单元：输入任务、读取过的关键文件、决策摘要、修改 diff、验证命令、失败点。没有这些，主 Agent 只是调度员，不是负责人；人类 reviewer 也只能“等着”。这就是为什么有人说“真该开始写自己的 harness”：不是为了重新发明 Agent，而是为了把 Agent 关进工程流程里。

3. Emacs 讨论给了另一个答案：工具应该可被用户改造到骨头里

从 xwidget-webkit 跑 YubiKey、继续挑战 Vimium，到自己编译 Codex、改 HUD、讨论 Emacs fork，这些都不是单纯折腾。它们体现了 Emacs 用户的底层偏好：工具必须允许用户把工作流嵌进去，而不是只给一个漂亮但封闭的界面。

所以 Codex HUD 丑不只是审美问题，statusline 不能被外部脚本控制也不只是小缺陷。对这类用户来说，不能脚本化、不能观察、不能接入现有编辑器仪表盘，就意味着不能真正成为个人工程系统的一部分。

可继续实践的方向

可以把“蹬”从消耗额度改造成一套 Agent 评测 harness：每个任务强制记录目标、上下文、subagent 分工、diff、测试、回滚说明和人工评分。连续跑一周后看两件事：哪些任务真的节省了时间，哪些只是制造了更多 review 负担。到那时，模型配合方案、HUD、statusline、Emacs 集成都不再是玩具审美，而会变成可度量的工程基础设施。