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

Emacs 中文讨论组

🎯 核心热点与专题探讨

1. Emacs 配置与工具生态的现代化演进

群内围绕 Emacs 的讨论占据了主导地位，焦点集中在三个相互关联的维度。

gnus-modern 的重构与界面统一构想

• 发起者: zdn
• 核心动作: 将 gnus (Emacs 的新闻组/邮件阅读器) 的配置从零散的脚本改造为面向对象（OOP）风格，并模块化。最终目标是缩减代码行数至 2000 行左右，并合并为单文件，形成一个名为 gnus-modern 的现代化配置。
• 宏大设想: 讨论中提出了一个更广泛的愿景——设计一套统一的界面定义，覆盖 gnus、mu4e 和 elfeed 三个核心信息管理工具。这反映了资深用户对在 Emacs 内部构建一致、高效信息处理体验的深层需求。群友提到“法国佬都做了”，佐证了这一方向的可行性与探索价值。
• 代码仓库: zHaOdANiuu/.emacs.d

ezf: 在 Shell 与 Emacs 间架起模糊搜索的桥梁

• 核心痛点: 对 fzf 的依赖与集成体验的优化需求。
• 解决方案: 群友开发了 ezf，一个基于 Emacs 的模糊搜索方案。其核心机制非常巧妙：
  1. 在终端 shell 的配置文件（如 .bashrc, .zshrc 等）中 source 一个脚本。
  2. 当在 shell 中触发（如按下 Ctrl-r）时，脚本将当前的输入通过 emacscclient 发送给一个始终运行的 Emacs 实例。
  3. Emacs 内部完成搜索处理后，将结果返回给 shell 执行，或调用其它 handler。
• 关键优势:
  • 异步加载: 解决了性能问题，体验流畅。
  • 无缝集成: 可以像原生 fzf 一样绑定到 Ctrl-r (搜索历史), Ctrl-t (搜索文件), Alt-c (搜索目录) 等快捷键。
  • 按需搜索: 考虑到性能，未实现实时重搜索，而是采用触发式搜索，在体验与资源消耗间取得了平衡。
• 后续计划: 即将为 Ghostel 提供 ezf 集成，展示了其作为通用基础设施的潜力。

Windows 平台 Emacs 输入法体验的质变

• 问题背景: Emacs 在 Windows 上长期受困于糟糕的输入法体验。
• 核心贡献者: zdn
• 成果:
  1. Preedit 渲染补丁: 实现了在 Emacs 内部直接渲染输入法的 preedit 文本。该补丁跨线程、Lisp 编码与事件分发，代码改动超过 100 行，功能完备。但因改动量大，上游维护者 Eli 倾向不合并。
  2. IME 字体补丁: 作为一个更轻量的替代方案，解决了字体大小问题，已稳定使用数日，被群友认为合并可能性极高。
  3. 历史意义: 群内评论认为“现在 Emacs 在 Windows 的输入法体验变成 3 大平台最好的了”，凸显了这一改进的革命性。
• 后续进展: 补丁作者正在等待与 FSF（自由软件基金会）签署版权协议，以便推进代码的合并，但过程缓慢。

2. AI 冲击下的技术写作与知识沉淀 (专题)

群内对 AI 时代如何/是否继续写博客进行了深刻的反思，观点层层递进。

• “访客只剩下 AI 了”: 一语道破博客流量的本质变化，实际读者可能已被 AI 替代。
• “值得去沉淀的知识的门槛变高了”: 这是一个核心洞察。以往许多博客的内容是记录问题的解决过程和简单教程，现在这些问题在终端通过 AI 对话即可快速解决，失去了记录的必要性。有成员提到“之前花好几天解决一个问题，可以写一篇博客记录一下。而现在解决问题的方式，是在终端问 AI，问题很快就得到解决，然而却没有想把这个过程写成一篇博客的冲动。”
• “人的知识面依旧是决定 AI 上限的基石”: 在承认 AI 强大的同时，点明了人类知识深度的根本性价值。
• 写作动机的重塑: 博客的意义从“输出教程”向“建立个人品牌”和“深度记录”转移。如 zdn 所言：“我写博客是为了让别人了解我”。
• 对旧有教程的批评: 聊到过去大量内容没有时间与版本标识，命名不严谨，与其叫“教程”，不如叫“记录”。这些内容的泛滥导致了搜索过时信息、踩坑等一系列问题。

🔑 关键概念与技术解析

• gnus: Emacs 内一个功能极其强大的信息管理客户端，常用于阅读新闻组和邮件，配置高度可定制。
• mu4e: 一个基于 mu 邮件索引器的 Emacs 邮件客户端，以快速搜索和轻量设计著称。
• elfeed: 一个纯 Emacs Lisp 编写、配置灵活的 RSS/Atom 阅读器。
• ezf: 本次讨论中出现的自研工具，一个利用 emacsclient 实现类似 fzf 功能的模糊搜索方案，可在 Shell 与 Emacs 间无缝衔接。
• Emms: Emacs Multimedia System，Emacs 的多媒体播放系统，支持多种音频/视频格式。
• liberime-regexp: 推测是一个与 Rime 输入法引擎相关、用于正则表达式搜索的 Emacs 包。
• Ghostel: 一个利用 Emacs 客户端/服务器架构，在终端和图形化 Emacs 间进行交互的工具。
• preedit: 在输入法中，指用户正在编辑、尚未提交到应用程序的文本（通常是候选词或正在拼写的拼音）。本次讨论中，指代在 Emacs 中直接渲染这段文本的技术。
• Telega: Emacs 内一个强大的第三方 Telegram 客户端。
• Denote: 一个基于 Emacs 的、简单但功能强大的笔记管理和文件命名方案。

💎 碎片知识与金句拾遗

• 关于工作流的变化: “惭愧，我已经好长时间没有打开emacs了… 活在了claude code里面”。这反映了部分开发者重度转向 AI IDE，即使对 Emacs 这样深度定制的工具也产生了冲击。
• 关于按键的一致性: “emacs 的按键和 bash 里面的是一套，也不算白学”。这是一个经典的、鼓励性的观点，强调基于 readline 的通用按键体系带来的复利效应。
• 关于博客的生态: “现在还有人看博客吗？访客只剩下 AI 了”。
• 关于知识价值: “是的，AI 让人值得去沉淀的知识的门槛变高了。那些简单的问题已经不值得记录了。”
• 关于人的价值: “人的知识面依旧是决定 AI 上限的基石”。
• 关于教程的弊端: “互联网上的教程最大的问题就是很多没有注明版本和环境信息”。
• 关于中文社区: “还有很多内容都是复制来复制去的，各种原因吧，中文就不怎么行。”
• 关于坚持写作: “懒猫的博客都写了150万字了，可真能写”。
• 关于新书出版: “实际上，现在新出版的书只占印刷数量中的一成，有人还在写就很了不起了😂”。
• 关于生活的松弛感: 群友提到 FSF 版权协议审批缓慢，感叹“欧美人太松弛了”，并对比美国软件公司周日秒回工单。另一群友幽默地引用 matrix.org 的回复风格说“估计要下个月回复”，随后引发了一场关于“纸短情长”是情书还是友情信的文化讨论。
• 关于UI微调: 有群友将 tabbar (标签页栏) 从始终可见改为仅在按 M-Spc 或进行切换/新建/关闭标签时才在 echo area (回显区) 临时显示，以此节省屏幕空间。
• 关于 Emacs 动画: “我用 cursor-animation-cycle” 和 “NEO Emacs's animation cursor type”，展示了部分用户对编辑器鼠标指针样式动画的极致追求。
• 关于重构的乐趣: 在面对 AI 辅助编码的当下，zdn 说“我现在在写mpv的包，还是手写有感觉”，表达了对亲自敲代码、深度掌控细节的创作过程的留恋。

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

1. 开源项目 - ezf: 极具潜力的 Emacs/Shell 协作式模糊搜索工具。其架构精巧，可替代 fzf，实现与 Emacs 生态的更深度整合。关注作者何时正式发布。
   • 关联项目: Ghostel。
2. 配置思路 - 统一信息界面: 将 gnus、mu4e、elfeed 的界面进行统一抽象的构想。这是一个能够极大提升信息处理沉浸感和效率的方向，值得在 gnus-modern 之后持续跟进。
3. 开源贡献 - Windows IME 补丁: zHaOdANiuu 的 preedit 渲染补丁从技术实现上更优，但因维护者的决策可能不会被合并。核心参与者可尝试编译带此补丁的 Emacs 并体验，或关注 IME 字体补丁的合并进度。
   • 相关链接:
     • Preedit 渲染补丁
     • IME 字体补丁
4. 新兴项目 - mpv.el: zdn 正在手动开发一个用于控制 mpv 媒体播放器的 Emacs 包，这是一个重现“手写代码”感觉的实践。这对 Emacs 多媒体体验爱好者来说值得关注。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是某个包，而是两个看似相反的信号：一边有人“活在 Claude Code 里面”，一边又有人把 gnus、ezf、Windows IME、mpv.el 这些细节继续往 Emacs 里打磨。表面看是旧工具和新 AI 的拉扯，本质上是“可替代的操作”正在被 AI 吃掉，“可积累的环境”反而变得更重要。

1. AI 没有消灭 Emacs，它消灭的是低复利配置

“简单问题已经不值得记录了”这句话很准。以前很多博客、配置、教程，本质是把一次踩坑过程外化成文本；现在这类东西可以在终端里被 AI 即时生成，价值塌得很快。

但 ezf 这类东西不一样。它不是“怎么用 fzf”的教程，而是把 shell 当前输入、emacsclient、异步搜索、handler 返回链路拼成一个可复用交互层。这个判断可验证：如果一个改动只解决一次问题，它会被 AI 问答吞掉；如果它改变了之后每天几十次的输入/搜索/跳转路径，它就是工作环境资产。Emacs 真正抗 AI 冲击的地方，不是 Lisp 怀旧，而是它能把人的长期操作习惯编译进环境。

2. 博客的门槛变高后，值得写的反而更清楚了

群里说“访客只剩下 AI 了”，这不是博客死亡，而是博客读者结构变了。搜索流量型教程会衰退，因为没有版本、环境、时间戳的“教程”本来就接近污染源；AI 只会把这种污染放大。

真正值得写的是三类东西：第一，像 Windows IME 补丁这种带工程取舍的记录——为什么 preedit 渲染体验更好，为什么 100+ 行会引入线程安全、Lisp 编码、事件分发风险，为什么维护者可能更愿意合并字体补丁。第二，像 ezf 这种架构小但边界清楚的工具说明。第三，是个人判断的轨迹：为什么你选择手写 mpv.el，为什么统一 gnus、mu4e、elfeed 的界面定义值得做。AI 能生成步骤，但很难替你留下“当时为什么这么取舍”的证据链。

3. 工程判断：能不能沉淀，看它有没有边界和反馈回路

今天这些讨论可以抽成一个简单标准：没有边界的知识会过期，有反馈回路的系统会增值。旧教程的问题是缺少版本和环境边界；ezf 的价值在于输入从 shell 到 Emacs 再回 shell 的边界清晰；IME 补丁的价值在于问题被压到可测试的体验差异和上游合并成本；统一信息界面的价值，则要看它能否抽出 gnus、mu4e、elfeed 共同的状态、列表、预览、动作模型，而不是只换一层皮肤。

可继续实践的方向：把今天提到的工具都按同一模板写成“工程记录”——问题边界、运行环境、设计取舍、失败路径、可复现实验、后续合并/维护成本。不要再写泛教程；写能被人和 AI 共同引用、但必须由亲历者才能写出来的判断。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题】Emacs 目录跳转体验之争：zoxide、consult-dir 与 dired-z

讨论围绕如何在 Emacs 中快速跳转目录展开，核心分歧在于交互方式的选择：

• zoxide 模式 vs consult 模式：一方认为应该像 zoxide 那样，输入部分路径名后直接 enter 到达，不经过中间列表（“consult 那一个列表太重了”）；另一方指出 consult-dir 和 zoxide 本质相似（都基于访问记录），只是用 consult 作为选择器，且能利用模糊匹配。
• 实现路径：群友最终将 zoxide 体验迁移到 dired，发布了 dired-z（https://github.com/yibie/dired-z），认为其无需依赖 consult，可以直接在 dired 中完成跳转。后续争论点在于 consult-dir 是否必须依赖已访问目录，而 dired-z 是否支持任意可访问路径。
• 小结：这是典型的工具链设计哲学碰撞——是叠加通用补全框架，还是为特定场景定制轻量方案，双方最终以“每个人习惯不一样”达成和解，但技术讨论留下了两种实现思路的参考。

GPT-5.6 Sol 重置与 AI 服务使用体验

• Tibo 宣布为所有付费用户重置用量限制，并表示周一会再执行一次“表演式重置”，引发热议。
• 群内对话涉及多个 AI 服务的使用感受：智谱老套餐“不能降级只能升级”导致拥有者产生损失厌恶；Codex 的 Sol Xhigh 被吐槽跑得快、额度可能又降了；“goal”模型过于强势，在任务达标后仍不停止，需要手动 C-c 终止；Kimi 被评价“对抗性审查方面表现良好”。
• 甲骨文禁止 OpenJDK 使用 AI 生成代码的新闻也被提及，背景是 Oracle 自身大力投资 AI 但以安全/知识产权风险为由限制开源 JDK 项目。

Meta CTO 言论：“AI 省下的时间应该用来做更多工作”

• Meta CTO Andrew Bosworth 公开表示 AI 带来的效率提升不应转化为休假，应将节省的时间用于开发更多产品。
• 群内反应以讽刺和共情为主，有人联想到段子：“领导问，AI 干活的时候你在干嘛？”，并调侃自己当然在摸鱼。
• 该话题折射出行业对 AI 生产力与劳动者权益关系的深层焦虑。

AI 编排与多智能体框架的技术试探

• 讨论涉及多个项目：herdr（多 agents 交流）、relay（类似框架）、jido（https://github.com/agentjido/jido），以及群友自研的编排器中间件/adapter。
• 提到 Pi RPC 并发上限为 4，超出报错；同时指出主流编排已不用 RPC 模式。
• 有观点认为目前 AI 基础设施似乎在“重新实现 Erlang 虚拟机”，群友曾用 Elixir 尝试类似工作。
• 项目 relay（AgentWorkforce/relay）被指出与 herdr 功能类似。

Neoemacs 测试与兼容性推进

• 群友在利用富余算力修复 Neoemacs 的 bug，重点是对比 GNU Emacs 与 Neoemacs 运行相同 Elisp 代码的结果一致性。
• 测试通过 neovm-oracle-tests 仓库进行，已提交大量测试用例，贡献者对 Neoemacs 的兼容性表示“非常有信心”。
• AI 辅助诊断时，结论认为已有 probe 足以暴露问题，无需新增重复测试，建议直接依据现有红灯修复实现。

🔑 关键概念与技术解析

• zoxide：一个基于频率和模糊匹配的目录跳转工具，通过记录访问次数自动优化跳转优先级。
• consult-dir：Emacs 插件，使用 consult 补全框架浏览和跳转最近访问过的目录。
• dired-z：新发布项目，将 zoxide 的体验直接整合进 Emacs 的 dired 模式，无需 consult 中间层。
• Neoemacs：基于 Rust 重写的 Emacs 运行时，旨在保持与 GNU Emacs 的完全兼容。
• neovm-oracle-tests：用于对比 Neoemacs 与 GNU Emacs 输出一致性的 Elisp 测试套件。
• Pi / flue / herdr / relay：AI 编排或 agent 通信框架，Pi 指某个框架，herdr 和 relay 侧重多 agent 协作，flue 是基于 Pi 的框架。
• GPT-5.6 Sol：Codex 提供的模型变体，支持高用量。
• TextUI：群友发布的文本界面工具（https://github.com/yibie/textui），获得 Mastering Emacs 作者高度评价。
• Chai / Chrip：群友开发的包，用于从 Chrip（可能是 Twitter/X 客户端）保存 Tweet 到 org-mode。

💎 碎片知识与金句拾遗

• “失去拥有的比没得到更痛苦”——针对智谱老套餐绝版的无奈总结。
• “AI 说，该暴露的之前已经暴露，所以就不新增无意义的提交了”——AI 辅助编程中“不用再浪费时间”的典型反馈。
• “我恨智谱”、“我从来都看不起耍猴的公司”——对国产 AI 服务商业模式的不满。
• “领导问我，AI 干活的时候你在干嘛？”“当然是在摸鱼”——打工人对 AI 生产力叙事的黑色幽默反击。
• “goal 真的好强势，我说可以了，我手动测试过了已经达标了可以收尾，他还在继续”——AI 模型的“过度敬业”体验。
• “85% 都是跑的 opencode go 的 luna max”——Codex 用量分布细节。
• “自己手写了一个 simple-mpv，真是惬意啊；AI 给我写的代码写了 1000 行，我自己重写就只有 150 行”——对 AI 生成代码质量的直接吐槽，尤其在 Lisp 领域。
• “openjdk 不是他们的吧”、“但他们当年不是对 Google 也管的挺宽的”——对 Oracle 开放态度与法律强权的两面性的调侃。
• “Making Emacs 的作者高度评价 TextUI”——社区背书，验证项目价值。
• “这个连续的 50kb 读取让我下定了 subagent 的决心”——面对 API 限制触发架构决策的瞬间。

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

• dired-z：将 zoxide 逻辑直接植入 dired 的实现方式，值得了解其内部实现与 consult-dir 的差异。
• Neoemacs 兼容性测试体系：neovm-oracle-tests 提供的可行性测试方法，可能对其它 Emacs 替代实现（如 Remacs）有参考价值。
• AI 编排框架对比：herdr、relay、jido 以及自研 adapter 的设计思路，关注它们如何解决 RPC 并发限制、多 agent 通信与任务调度问题。
• Codex 的 Sol Xhigh 模型实际性能：用量下降和体验报告值得跟踪，尤其与 opencode go 等模型的组合使用模式。
• simple-mpv 手写 vs AI 生成对比：可以深入验证 AI 在 Elisp 代码生成上的短板，以及手动精简的巨大收益，用于指导 AI 辅助策略。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的，不是某个新包，也不是哪个模型又重置额度，而是同一条暗线反复出现：好的工具不是“更聪明”，而是让人的意图更快、更可控地落到系统状态里。

1. Emacs 的目录跳转之争，本质是“选择器税”

consult-dir 与 dired-z 的分歧，不只是补全框架偏好。有人说 consult 那个列表“太重”，想要像 zoxide 一样输入部分目录名直接进入，这其实是在拒绝一种很常见的交互税：明明用户已经知道自己大概要去哪，系统却强制把“确认候选列表”插进流程。

这类争论在 Emacs 里尤其典型。Emacs 的强项是可组合，但可组合经常滑向“任何动作都先进入一个通用选择器”。通用框架降低实现成本，却不一定降低操作心智负担。工程判断上，目录跳转这种高频动作，应优先优化“命中后直接改变上下文”的速度；只有在不确定性较高时，列表选择才是收益而非负担。dired-z 的价值不一定在功能更多，而在它把交互模型重新贴回了 dired 的使用场景。

可验证标准很简单：同样从当前 buffer 跳到一个常用项目目录，统计按键数、视觉停顿、错误回退次数。谁更少，谁就更接近这个场景的正确抽象。

2. AI Agent 的问题不是不够努力，而是不知道何时停止

“goal 真的好强势”“手动测试已经达标了还在继续”“得 C-c 才行”，这比额度、模型名更有工程含金量。现在很多 agent 把“完成目标”理解成持续推进，而不是进入可验证的收尾状态。它们缺的不是能力，而是停止条件、验收边界和控制权交还机制。

这也解释了为什么有人面对连续 50kb 读取决定上 subagent，为什么编排器讨论会自然滑向 adapter、并发限制、甚至“重新实现 Erlang VM”。当 agent 从单次调用变成系统组件，核心问题就不再是 prompt 写得多漂亮，而是调度、隔离、背压、失败传播和可观测性。RPC 并发上限为 4 这种细节，看似琐碎，实际是在提醒：没有运行时语义的 agent 编排，只是把脚本地狱换成模型地狱。

3. AI 写 1000 行，手写 150 行：Lisp 暴露了生成式代码的短板

“AI 写 Lisp 不如 Python/JS”并不意外。Lisp 代码质量高度依赖局部抽象、宏观风格和编辑器生态语感。AI 容易把问题摊平成命令式胶水，于是 150 行能表达的东西膨胀成 1000 行。这不是简单的“模型不懂 Lisp”，而是训练分布和语言文化错位：主流语料奖励显式展开，Lisp 社区奖励结构压缩。

可继续实践的方向：选今天提到的 simple-mpv 或 dired-z 这类小工具，做一次人写版与 AI 生成版对照评测：行数、抽象层级、交互路径、可测试点、后续修改成本。不要只看能不能跑，要看三个月后人还愿不愿意维护。