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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：Emacs 生态的现代 diff 工具缺失与自研冲动

群内最热烈的讨论集中在 Emacs 的 diff 工具（ediff、magit）无法满足复杂工程需求的问题。核心痛点如下：

• ediff 的缺陷：只能按 diff 算法决定的块（chunk）进行 review，无法自定义粒度；且 diff 算法（基于 git diff）在复杂代码修改时表现不佳，无法正确识别删改逻辑。
• magit 的不足：magit 本身没有提供多栏 diff 视图，仅依赖 ediff 或 buffer 对比，浪费窗口空间；magit-delta 项目已长时间未维护。
• 对比 vscode：vscode 的 diff 体验极佳（支持单双栏切换、代码移动识别、行内高亮等），部分成员会专门打开 vscode 看 diff。
• 其他工具对比：有人提到 IntelliJ 的 diff 并不好用（看不懂），有人推荐 neovim 的 Gitsigns 效果类似，但认为红色横线过于醒目。
• 自研尝试：有成员分享了已开发的项目 diffs.el（github.com/LuciusChen/diffs），声称"抄袭 diffs.com"，现代风格；还有成员计划"集大成者"，尝试替换 ediff 接口。讨论中涉及了 diff engine 的替换、以及处理大数据量时的 GC 卡顿问题。
• 最终结论：大家普遍认为 Emacs 社区尚未出现现代 diff 工具，这是基础工具被忽视的体现，甚至有人说"用 emacs 写代码的人太少了，一些基础的工具也没有人想过改进"。

---

🔑 关键概念与技术解析

• ediff：Emacs 内置的 diff 工具，按 diff 块（chunk）进行对比，但无法自定义块大小，且依赖外部 diff 算法。
• magit：Emacs 下的 Git 前端，提供了 status 界面，但 diff 视图较弱，缺少多栏支持。
• magit-delta：magit 的扩展，类似 delta（git diff 美化工具），但已停止维护。
• vibe 式开发：群友用"vibe"指代通过 AI 辅助（如 Copilot）快速开发，类似"vibe coding"。
• LSP 多服务器聚合：提到 eglot 作者写了一个 Python 工具，可将多个 LSP server 合并为一个，供 eglot 调用，解决 multiple 需求。
• Elisp 字节码与 JSON 转换：讨论中提到可以将 JSON 提前转换为 Elisp 字节码，提高通信效率，但无法解决 GC 卡顿。

---

💎 碎片知识与金句拾遗

• "ediff 对于没有选中的区域不会显示高亮" —— 引发对 ediff 可用性的吐槽。
• "很多时候朴素的 git diff 算法没办法正确识别删改，所以必须要对比看两个文件" —— 说明 diff 工具的痛点根源于算法。
• "vscode 的 diff 是真好用啊有一说一，我有时候会为了 diff 专门打开 vscode 看" —— 反映生态差距。
• "跟vsc的那个差不多吧，勾选diff，是否应用，如果是merge可以三栏修改，还有一键合并无冲突的diff块" —— 描述了理想 diff 功能。
• "目前用过最好用的diff工具是idea的" → 但另一人反驳"远不如 vsc 的，jb 的我都看不懂"。
• "Gnus 除了卡之外什么都很好用😅" —— 提及 Gnus 的邮件客户端体验，并讨论其 Topic 体系的灵活性。
• "就差一个 程序员 prompt 了" —— 暗指可用 AI prompt 解决 Gnus 卡顿。
• "我发现 Gnus 除了卡之外什么都很好用😅" 与后续讨论显示，Gnus 单线程问题被戏谑为需要"async 魔改"。
• 有人提到 "guile-devel"、"guix-devel" 邮件列表，可能涉及 Guix 开发讨论。

---

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

• diffs.el（github.com/LuciusChen/diffs）：自制的现代 diff 工具，值得关注，可能成为 ediff 的替代品。
• eglot 多 LSP 聚合工具：作者未记住名字，可搜索“eglot 作者写的 python lsp 聚合”来了解。
• diff engine 替换思路：讨论中多次提到替换 git diff 算法（如 Google 的 diff 可识别代码移动），可调研现有开源 diff 算法（如 diffs.com、vscode 所用算法）并集成到 Emacs。
• Gitsigns 的定制化：提到可修改开源项目，去除红色横线，但暂无具体方案。

观点延伸

群里把原因归到“用 Emacs 写代码的人太少了”。这个归因太舒服，也太省事。更硬的解释藏在当天另一句话里：ediff 只能按块 review，而块完全由 diff 算法决定。这一句把问题从 UI 层拽回了算法层。

一、换 diff 算法才是正解，重做视图只能暂时缓解问题。 有人问“那换个 diff 算法是不是就够用了”，这是当天最接近正确答案的一问。magit 再加多栏也没用，只要底层仍是朴素的行匹配，复杂重构里的删改照样会被切成人看不懂的样子。vscode 和 Google 那套的真正价值不在配色，而在于它先回答了“这段代码是移动还是重写”。所以自研的顺序必须是 diff 算法、数据结构、视图；反过来做，只是给错误的块画更漂亮的高亮。

二、分栏不是审美，是认知负荷。“上下分行的感觉在欺负我的脑力”“跨控制流带修改就很麻”“分支合并不分栏完全看不懂”，这三句说的是同一件事：并排视图保留了空间对应关系，人靠位置比对，不靠记忆。magit 缺多栏并不只是少一个功能，更把 review 的成本转嫁给了用户。vscode 的胜出不是因为功能更多，而是因为它的默认值恰当。

三、Emacs 的真正上限是单线程加 GC。 讨论已经推到了“JSON 转字节码能快不少，但救不了 GC”。这条约束值得单独记住：任何把 diff 计算塞进 Elisp 的方案，都会在真实仓库规模上撞墙。诚实的架构大概只能是外部进程或原生模块算 diff，Elisp 负责编排与渲染。先说清楚这条，能省掉大量“写完才发现卡”的返工。

四、AI 降低的是造工具的成本，不是判断标准。 同一天里既有“找个时间 vibe 一下”自研 diff，也有 Gnus 卡顿“就差一个 prompt 了”。两句话合起来指向同一件事：基础工具长期没人做，很大程度是人力成本问题，而这块成本正在塌陷。但群里对“好 diff”本身并无共识：有人说 IntelliJ 最好用，立刻有人回“jb 的我都看不懂”。代码可以生成，偏好不能。这大概率意味着接下来会冒出一批各写各的、能用但不统一的小工具，而不是一个共识标准。

可继续研究或实践： 挑一个真实的重构 commit，里面跨文件移动、重命名、局部改写各占一部分，分别用 ediff、magit、diffs.el 和 vscode 过一遍，只记录一件事：切出来的块是否忠实于作者的修改意图。这个对比不用写一行代码，却能把“感觉不好用”变成可复现的证据。有了这份证据，再决定是换 diff 算法还是改视图，才不会白做。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：开源社区的“医患关系”——从 emacs-china 论坛争执说起

本次讨论由群友退出 emacs-china 论坛的经历展开，并迅速演变为对开源社区生态、用户关系与开发者心态的深度探讨。导火索是万象输入法作者在论坛回应建议时态度暴躁，引发争论，群友因版主处理不公而愤然离坛。

讨论中逐渐形成多个观点层：

• 开源维护者的困境：多位群友认为开源作者与用户之间形成了类似“医患关系”或“情侣关系”的拧巴状态——两边都觉得自己的付出得不到回报，一边觉得用户烦，一边又舍不得用户。群友一针见血地指出，核心问题在于“既觉得自己牛逼，又不想听意见，但不舍得用户”的患得患失心理。
• 技术人沟通能力缺失：有人总结出技术人典型产品火后的心态不成熟表现，如“觉得自己牛逼了，不必听别人的话”“表达方式极为欠缺，不懂沟通”“既觉得用户问来问去好烦又不知如何处理”。群友补充认为，技术人过于“实诚直来直去”，有时需要提供情绪价值，而 Linus 的成熟之处在于对事不对人、边界清晰。
• 论坛生态恶化：有群友感叹现在论坛“精品内容少，打开巨慢”，什么吐槽都往论坛丢，“像一个垃圾场”，并推测 linux.do 让很多小孩知道了 Discourse 这类站点，导致低质量内容涌入。

专题二：AI 驱动的独立游戏开发——修仙开放世界的探索

群内一位开发者分享了自己用 AI 辅助开发修仙题材开放世界游戏的项目，引发热烈讨论。游戏采用类似《饥荒》的开放世界设计，具有生存压力与剧情，支持有限联机（类似原神，协助升级），主体为单机。

核心碰撞点在于：

• 核心玩法与细节功能的优先级：有群友提议加入“飞剑砍树”等交互细节，但开发者坚持认为“先把修行体系做出来才是核心”，并指出“套皮功能太没意思”。他主张飞剑应作为独立个体与世界互动，可与剑灵对话、派其执行任务，而不仅仅是砍树的技能。
• AI 的能力边界：开发者认为“一个人做脑子装不下，要发挥 AI 神力”，并感叹“现在 claude 太逆天了”，但对动作游戏的打击感表示担忧，认为“动作游戏水太深，不知道 AI 能不能搞定”，群友则直白回应“搞不定”。
• 游戏设计的差异化：开发者提出“你见过哪个游戏现在做好修仙了？没看到，那不就得了”，凸显其要做别人没做过的核心系统的野心。

---

🔑 关键概念与技术解析

• TermRover：群友推荐的一款“挺轻量”的工具，具体用途未展开，但结合上下文推测为终端环境下的某种工具（可能是终端浏览器或检索工具）。
• Reranker 机制：针对输入法自学习效果差的痛点，有群友提出“应该有一个 reranker 机制来处理”。Reranker 是检索与推荐系统中的概念，对初步候选结果进行精细化排序，这里指用于对输入法的候选词重排序，以更好地适应用户的误触与选错模式。
• DSL 编译出正文与元数据：在讨论文学创作与 AI 结合时，群友提出“通过 DSL 编译出正文和元数据，再通过专门 CLI 给大模型定位，获取信息用”，即利用领域特定语言来结构化文本素材，便于大模型理解语境与作者意图。
• Tailworm（Tailscale SSH 转发漏洞）：安全研究者披露的 Tailscale/headscale 漏洞集合。攻击者控制一台获准连接目标的设备，利用 SSH 端口转发可在目标服务器获取 root 权限，目前无 CVE 或修复版本，建议收紧访问规则并关闭 SSH 端口转发。
• lspbridge：Emacs 中用于桥接 LSP 后端的工具，群友反映即使使用它补全 elisp 依然卡顿，其他群友则指出“elisp 不需要 lspbridge，有个 company 就行”。

---

💎 碎片知识与金句拾遗

• 关于输入法痛点：群友吐槽百度输入法“会记住误触和选错的问题”，以及“用一个词拼音拼不出，用两个词去拼，拼出来的词不会被记住”，认为这是当前输入法的核心痛点。
• 关于双拼与等宽字体：群友发现“双拼两个字母一个字，对等宽字体来说刚好能放在下方的一排对齐”，并可激进地“原地显示”，体现了对排版细节的极致追求。
• 关于输入法的地名店名补充：群友分享“扒了一波大众的数据”来补充城市地名和店名，以解决输入地名店名时无补全的问题，但也承认“店名是几年就会过期的”。
• 关于 GPT 额度重置：有人吐槽 tibo 又重置了额度，“他还 90%+ 就重置了”，群友分析认为此时重置相当于送大家一些额度，但与他缩减的额度相比“依旧觉得毫无诚意”。
• 关于文学创作与 AI：群友感叹“read，write，grep 这类插件都不是很适合文学创作，尤其是编写小说文章时，grep 修改简直是太恐怖了”，因为“文学不是代码，同一个词在不同语境是不同意思”，需要让大模型明确当前场景的作者意图。
• 关于 I 人与社交：有群友认为“I 人这个词的出现确实挺友好的，会让大家认识到这种性格只是分类中的一种，而不像以前对内向会有许多的偏见”，并回忆“以前小孩内向是会被训的”、“我们会被歧视，闷屁虫”。
• 关于人口下行：群友分享“2025年末全国总人口净减少339万人”，有群友调侃“下行这个听上去词就挺温和的”，并担忧“以后的年轻人养不起我们这帮老头子了”，另有人提出“以后靠 AI 养了可能”，但被反驳“AI 只会加速资源垄断，加剧贫富差距”。
• 关于工作心态：群友总结“工作、结婚、生娃都是磨砺脾气的磨刀石”，“工作久了，一般做事情都会想想影响，不会情绪上来了直接干”，并幽默表示“生活太难了，发脾气也要精力，也算 token”。
• 关于 Emacs 补全卡顿：群友抱怨“用 company 也卡，在输入前几个字符的时候”，并称“输入到 3 的时候就卡”，其他群友建议“3 个字符再开始补全”，并惊讶“lspbridge 也能卡的么”，指出“补全 elisp 的该卡还是卡”。

---

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

• 修仙开放世界游戏的“修行体系”设计：开发者正在构建的修仙核心系统（斗法、御剑、破境）以及“飞剑作为独立个体与世界交互”的设想，具有极强的创新潜力。AI 辅助开发独立游戏的实践值得持续关注。
• “叙事系统语言”的设计构想：群友提出“能不能搞出一种叙事系统的语言”，结合“DSL 编译出正文和元数据”的思路，可能指向一种面向文学创作的结构化文本格式，值得深入探索。
• 输入法的 Reranker 机制：针对自学习效果差的问题，群友提出引入 Reranker 来对候选词进行重排序。这一思路可能对 RIME 等开源输入法的优化方向有重要参考价值。
• emacs 中输入法的“半上屏”模式：群友设想“可以在未上屏的状态下切掉输入状态，用 emacs 原本的能力来做光标移动”，实现中英数字混输的“半上屏”状态，这可能是对 Emacs 输入法交互模式的重大改进。
• Tailworm 安全漏洞研究：Tailscale SSH 转发漏洞涉及 root 权限获取，是网络配置安全领域的重要研究案例，值得关注后续的 CVE 分配与官方修复策略。

观点延伸

今天最值得琢磨的是三条讨论线撞出的同一个问题：开源社区的争执、输入法自学习的改进、文学创作的 AI 工作流，看起来毫不相干，卡住的地方却高度一致：大家都在用“感觉”和“关系”解释一个本该用“结构”解决的问题。

开源不是医患关系，是没有条款的赠与。 医患至少有挂号费、诊疗规范和投诉渠道，开源这三样全没有，只剩下“我付出了”对“我使用了”。于是两边都在道德记账，谁算下来都觉得自己亏。群里说 Linus 的成熟在于对事不对人，这句话的工程含义是：先造出一个可以争辩的对象，例如代码、回归、性能数字，情绪才有地方降级。所谓“提供情绪价值”多数时候是在降低对方的解释成本，而非练话术：明确说“这条建议不采纳，因为会破坏某个场景”，比十句 awesome 有效。有个可验证的判断：一个有贡献指南、有 issue 模板、有明确“不做什么”清单的项目，公开吵架的概率会低得多。

输入法的病其实在于没有 reranker 和评测集，并非“记不住”。 群里两句话已经点到要害：一句是“应该有一个 reranker 机制”，另一句是“需要 benchmark，测试集可以去现成输入方案里找”。用户误触一次就被记住，本质是把噪声当信号：任何学习系统缺负样本和置信度，都会过拟合到误操作。正确顺序是先做候选重排，让上下文和用户历史共同打分；再建可回归的评测，量首屏命中率、改选次数、整句准确率。没有这套东西时，“更快更好”就只能靠体感宣布。而“半上屏”“原地显示”这类交互创新恰恰最依赖它：交互越激进，越需要一条可量化的回退路径。

文学 DSL 的方向对，但要防元数据腐烂。 群里判断很准：代码有格式和关键字，文学里同一个词在不同语境是不同意思，所以用 grep 改稿才恐怖。DSL 编译出正文与元数据、再用专门 CLI 给模型定位，本质是给文本装可寻址的锚点。风险在于锚点一旦要求作者手工维护，就会在写作热情耗尽时全面失效。合理的分工是：能从正文派生的（章节、场景、人物出场）自动生成，只有“作者意图”这种不可派生的才手工标。

可以先做的实验： 拿自己几十条真实输入记录，量出首屏命中率和改选次数，再决定要不要上 reranker；同时把用户手动改选的行为记成负样本，而不是继续喂给自学习。不必换输入法，只需要一份能跑的评测集。先有度量，再谈优化。