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

Emacs 中文讨论组

🎯 核心热点与专题探讨

【专题：Emacs 多光标编辑的实践与争论】

群里展开了约一小时的长篇讨论，围绕多光标、宏、矩形编辑的优劣展开了激烈交锋。

背景： Neovim 宣布原生支持多光标编辑（multi-cursor），引发了 Emacs 用户群的讨论。有人认为 Emacs 的宏足够强大，不需要多光标；有人则认为多光标更直觉、更好用。

各方观点：

• 宏派：认为宏适合复杂场景，录制时一次想好就能套用。缺点是“不够直观，容易写错，中途出错就要重来”。
• 多光标派：认为“多光标和吃饭喝水一样自然”，尤其适合对同类文本做批量处理。强调“可以边做边调整”，比宏的“录制前完全想好”更灵活。
• 矩形编辑派：有人表示主要靠 C-x SPC 矩形编辑 + replace-regexp 就能覆盖大多数场景。

痛点与吐槽：

• 有人吐槽 Emacs 的矩形编辑“一次编辑完就要重新选区”，体验不够流畅。
• 有人提到在矩形编辑模式下 backspace 和 C-y 失效，需要先选中才能操作，认为这很“神秘”。
• 有人提到 Emacs 矩形模式下的零宽选区提示（rectangle-indicate-zero-width-rectangle）在 TUI 下不可见，因为 TUI 不支持 :height 属性。

结论： 群内没有达成一致，但普遍认为多光标“不需要特别学”，且对数据处理场景（如 SQL 对齐）很高效。有人总结：“更复杂的匹配替换直接丢给 AI 了”。

【专题：Valve 对 Linux 生态的贡献】

群内对 Valve 的开源投入给予了高度评价，提到几个关键项目：

• Wine/Proton：让 Windows 游戏在 Linux 上运行的核心兼容层。
• FEX-Emu：一个 x86 模拟器，用于 ARM 设备上运行 x86 游戏。
• Linux 图形驱动：Valve 深度参与开源图形驱动栈的开发。
• HDMI 2.1 驱动开源：群友指出 HDMI 标准组织“不干人事儿”，Linux 只能用残废的 HDMI，Valve 解决了这个难题。
• 与 Arch 社区的合作：Valve 直接与 Arch 官方展开合作，但群友指出“Omarchy 目前还没有和 Arch 官方合作的迹象”。

【专题：Omarchy 与 vibe coding 的风险讨论】

群里持续讨论了 Omarchy 项目（一个基于 AI 编程的项目）以及 vibe coding 的隐患：

• 有人评价“Omarchy 总归是个好事”，只要后续能掌控住项目不腐化。
• 但对 vibe coding 持悲观态度：“必然失控的，被营销吸引过去的用户大部分是识别不出来有什么坑的，感觉黑客们有的赚了”。
• 关于“AI 写的漏洞多”，有人指出核心不是“AI 写的漏洞多”，而是“vibe 的东西没人负责”。在公司里“你 vibe 自己不管，出了事故你还是要背锅”。
• 有人感叹“写的快，review 的 AI 也快，漏洞检测的 AI 也快，太快了”。

---

🔑 关键概念与技术解析

• FEX-Emu：Valve 参与开发的 x86 模拟器，用于在 ARM 平台上运行 x86 游戏，是 Linux 游戏生态的重要组件。
• vibe coding：指完全依赖 AI 生成代码的编程方式，不手动审查或修正。群内讨论其安全性隐患，核心问题是“没人负责”。
• telega + tgs2png：telega 是 Emacs 的 Telegram 客户端。它无法直接渲染 Telegram 的动画表情（TGS），需要外部工具 tgs2png 转换为 PNG 后才能显示。
• rectangle-indicate-zero-width-rectangle：Emacs 31 新增选项（默认 t），当矩形选区宽度为零时用 region face 高亮显示。仅在 GUI 下有效，TUI 不支持 :height 属性。
• epub-reader：Emacs 新发布的 EPUB 阅读器，支持目录、高亮、鼠标操作、KP 算法对齐、自定义版面选项（行距、段间距、页面两侧留白）以及阅读进度显示。

---

💎 碎片知识与金句拾遗

• “让 Linux 生态好起来的是 Valve。” —— 群友评价 Valve 对 Linux 图形栈、Wine/Proton、FEX-Emu 的贡献。
• “做一个成熟的桌面是需要大量脏的工作的，这一部分人类很少去做。” —— 吐槽桌面开发的工作量大且乏味。
• “营销能力顶级了可以说😁” —— 评价 Omarchy 的营销手段。
• “讲个笑话，dhh 有审美。也可以说每个人都有审美。” —— 对某项目设计审美的讽刺。
• “多光标在大部分场合下都更方便。” —— 多光标派的辩护。
• “我是不理解 nvim 为什么现在要加多光标的。” —— 质疑 Neovim 新增多光标的意义。
• “宏我感觉适合更加复杂的场景，多光标很直觉。” —— 两种工具适用场景的总结。
• “多光标很简单，不需要特别学，和吃饭喝水一样。” —— 群友对多光标易用性的评价。
• “我是 evil 用户，喜欢用 C-v, j,j, I, space, space。我把这种行为称为：行云流水。” —— evil-mode 用户描述自己的多光标操作习惯。
• “把视频播放这个独立抽出来吧，太叼了。” —— 群友对 Emacs 视频播放器项目的评价。
• “chirp 是好用啊。” —— 简短肯定某个工具。
• “刚发现有 twitter dm 到 matrix 的桥。” —— 发现一个有趣的中继工具。

---

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

• Emacs 视频播放器（video.el）：群友正在开发，支持嵌入式/全屏两种模式，基于 canvas，支持暂停、静音、进度条、缩放、拖动，并计划集成到 appkit。后续打算支持“流媒体”，且“现在能共享 session，切换时可以连续播放”。这是一个极具潜力的 Emacs 多媒体扩展。
• Neovim 原生多光标：Neovim 刚合并了原生多光标支持，群内讨论热烈。值得对比 Emacs 的 multiple-cursor.el 和 rectangles，看看未来 Emacs 是否也会加入原生支持。
• Valve 的 HDMI 2.1 开源驱动：解决了 Linux 上 HDMI 功能残废的问题，对 Linux 桌面和游戏生态意义重大，值得深入了解其实现。
• chirp 的集成：群友提到“在做 chirp 的集成”，后续可能有更大的框架出现。

观点延伸

今天最值得咀嚼的不是“Emacs 到底需不需要多光标”，也不是“AI 写代码是不是漏洞更多”，而是同一个工程判断：工具真正改变质量的地方，不在它能不能完成任务，而在它是否让人持续看得见、停得住、负得起责。

1. 多光标赢的不是能力，是可中断的直觉

宏、replace-regexp、矩形编辑都很强，复杂匹配甚至比多光标更适合。但群里反复出现的关键词是“直觉”“边做边调整”“不用特别学”。这说明多光标的价值不是表达能力，而是交互闭环短：选中、扩展、删改、撤销，每一步都在眼前发生。

宏的问题恰好相反：它要求操作者在录制前先把路径想完整，中途错一步就有重来成本。矩形编辑的问题也类似，能力存在，但状态提示、按键复用、零宽选区在 TUI 下不可见这些细节，会直接打断心智模型。工程上这不是小体验问题，而是“错误可见性”和“恢复成本”的问题。

2. “更复杂丢给 AI”不是终点，而是分层信号

讨论里有人说，复杂匹配替换直接给 AI。这个判断很现实，但也危险：多光标适合局部可视修改，正则适合可声明批处理，宏适合重复动作，AI 适合需求模糊或转换规则难形式化的场景。问题不在用不用 AI，而在有没有清楚知道自己跨到了哪一层自动化。

一旦从多光标跨到 AI，反馈粒度就变粗了：你不再逐字符观察，而是在审查一段结果。这里就和 Omarchy/vibe coding 的争论接上了。群里那句“不是 AI 写的漏洞多，是 vibe 的东西没人负责”很准。速度本身不会带来质量，速度只会把责任瓶颈暴露得更快：写得快，review 也快，检测也快，但如果没有明确 owner、边界和验收标准，整个系统只是更快地产生不可追责的变更。

3. 可验证的工程标准：看自动化是否保留责任链

判断一个编辑器功能、AI Agent 流程、vibe 项目是否靠谱，可以先问三件事：操作过程是否可观察；错误是否可局部撤回；结果是否有独立验收。多光标在小范围文本处理上天然满足这三点，所以它“像吃饭喝水”。纯 vibe coding 如果缺少 review、测试、安全边界和维护 owner，就同时破坏这三点。

可继续实践的方向：把 Emacs 里的文本变换按“手工可视、多光标、正则/宏、AI Agent”分成四层，分别记录典型任务、失败模式和验收方法。真正值得做的不是争哪种工具高级，而是建立一套从可视编辑平滑升级到 AI 自动化、同时不丢责任链的工作流。

Emacs 轻聊讨论组

今日尚未生成该讨论组总结。