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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：Emacs 多端显示架构的漫长阵痛

今天的核心讨论围绕 Emacs 长期以来被诟病的跨平台渲染与 GUI 抽象展开。群友从日常的 TUI/GUI 体验差异切入，最终演变成一场关于 Emacs 渲染架构是否应该推倒重来的尖锐辩论。

1. 痛点：TUI 与 GUI 的脆弱抽象

• 有群友发现在 Emacs daemon 模式下，启动时间莫名从 3 秒膨胀到 5~6 秒，暴露出 require 在 :config 中的副作用。
• 紧接着，关于多平台支持的痛苦被点燃。大家列举了 Emacs 不得不单独处理的一长串系统功能：窗口生命周期、IME、剪贴板、拖放、无障碍、多显示器、Native WebView ⋯⋯ 这些在跨平台 GUI 库中本应内置的基础设施，Emacs 却几乎都要在 pgtk、ns、haiku、甚至 msdos 等后端里各自实现一遍。
• 核心矛盾：有人指出，Emacs 本质上是一个自绘系统，不用「控件」或「组件库」，图形全由自身绘制（包括 Customize 界面）。理论上只需要一个 2D 图形库，但实际却要和各个平台的窗口、输入法、焦点等系统特性深度纠缠，导致「任何 GUI 功能都要考虑 N 个平台」，维护负担极重。

2. 2D 图形库的选择困境

• 群友调侃“如果零几年就搬上 JVM，用 JavaFX 什么事都没有了😈”，现实讨论集中在几个候选方案：
  • Cairo：目前 Emacs 主要使用，但没有硬件加速，且连高斯模糊都不支持（冷知识）。
  • Skia：已有热心开发者制作了 emacs-skia，但 Skia 本身没有正式 release，且 License 与 GNU 系兼容性存疑，“基本不可能进上游”。
  • SDL：近期社区有讨论要增加 SDL terminal type，SDL2 在性能测试中表现更好，但群友担心后端切换后失去对某些 Web 功能的支持。
• 一位深度参与的群友悲观总结：“2D 库还真就没有一个开源而好使的……”，这直接导致任何“统一渲染层”的设想都很难落地。

3. GUI 与 TUI 的割裂与取舍

• 讨论中有两种声音：
  • 放弃 TUI，专注 GUI：认为终端模拟器现在可以跑 GUI 程序，TUI 没有必要继续妥协。有群友提议最大化利用 GUI 特性，比如丰富的可视化效果。
  • 保留 TUI，但需要合理抽象：有人提到 TUI 和 GUI 因为共享同一套抽象，导致连“给光标做动画”这种简单需求都无法可移植地实现。
• 此外，有群友展示了一个野路子用法：(set-char-table-range glyphless-char-display #xFFF4 'zero-width) 来隐藏某些字体在 Emacs 终端与 GUI 中显示异常的 Unicode 控制字符，这正暴露了多端一致性的琐碎问题。
• Lem 的动向也作为参照被提及：Lem 最近切换到了 Electron，有人觉得“丑了不少”，也有人认为直接做 Web UI 才是未来，毕竟已经能在浏览器里用了。

4. 争议与金句

• “Emacs 的 GUI 给 TUI 妥协太多了，当然考虑到历史也正常。”
• “就好像不用 MPS 而是非要自己写 incremental GC 一样——重复劳动。”
• “Cairo 甚至没有高斯模糊，连 CPU 实现的都没有（” 这些略带讽刺但又精准的评论，折射出社区对 Emacs 底层架构爱恨交织的复杂感情。

---

小专题：Rune —— 一个野心勃勃的商业 Emacs 风格编辑器

• 群友在 Hacker News 上发现了一个正在 beta 中的商业 IDE Rune (rune.build)。其宣称“提供 point、mark、region、minibuffer、kill ring、query-replace 以及 Emacs 用户期待的 C- 和 M- 快捷键”，甚至可能有 pop-mark。
• 但因其拒绝开源、采用商业 IDE 模式，被群友评价“勇气可嘉”。多数人持观望态度，转而将目光投向同样未来可期的 Lem（虽然其 UI 方向还在摇摆）。

---

🔑 关键概念与技术解析

• Rune：一款商业化的、灵感来自 Emacs 的编辑器，正在封闭测试，注重还原 Emacs 的核心交互体验。
• emacs-skia：社区成员尝试将 Skia 图形库集成到 Emacs 的项目，旨在获得更现代的 2D 渲染能力（如硬件加速、抗锯齿等），但受限于许可证与上游策略，难以合入主线。
• SDL terminal type：目前 Emacs 社区正在讨论的一种新终端类型，用 SDL 替代传统的 ncurses 作为 TUI 后端，以获取更好的色彩、性能和可移植性。
• MPS (Memory Pool System)：一个开源、可插拔的垃圾收集器，群友以此作比，讽刺 Emacs 自研 incremental GC 的行为是重复造轮子。
• glyphless-char-display：Emacs 中处理无字形字符显示的机制，可配置将特定 Unicode 字符渲染为零宽度，解决字体显示问题。
• image-slice：一种将大图切成多个小块以便让 Emacs 滚动更平滑的技术，正在被 Chirp 等包采用。

---

💎 碎片知识与金句拾遗

1. 消灭烦人的 ￴ 字符 在所有平台（包括 TUI）上隐藏 PragmataPro 等字体显示的 U+FFF4 控制字符，只需一行：

   (set-char-table-range glyphless-char-display #xFFF4 'zero-width)

2. Emacs 启动变慢的元凶:config 中不宜直接 require 类似 telega-bridge-bot 这种重型包，否则 Emacs daemon 启动时间会悄然从 3 秒跳到 6 秒。

3. Cairo 的尴尬 “冷知识：Cairo 甚至没有高斯模糊，连 CPU 实现的都没有（” —— 这一真相戳中了 Emacs 依赖陈旧图形库的痛处。

4. Emacs 放 JVM 上真的会有性能提升？ 群友开玩笑：“指 elisp 的性能，放 jvm 上肯定比现在好😈”。虽是戏言，但暴露出不少人对 elisp 运行效率的不满。

5. 商业公司解散测试团队后的“边缘问题” “现在也不是问题了，因为商业公司也纷纷解散了测试团队，应该也会出现大量边缘问题了（” —— 毒舌却尖锐地描绘了行业现状。

6. Treemacs 的奇特性能 “我之前还在用 treemacs 的时候感觉让它跑在 terminal 下面还流畅一些。” 侧面反映 emacs 图形渲染的性能可能还不如 ncurses 纯文本模式顺畅。

7. 代码未提交但已可用的“image-slice” 群友提到 Chirp 的图片切片功能“还没上传 和孩子出来吃饭了”，这种随时写随时布的 hacker 风格颇为真实。

8. Emacs 边缘问题多，用户不够 “边缘情况一般测不到，得用户足够多” —— 一针见血地指明了小众软件 QA 的困境。

---

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

• Rune (rune.build)：虽然众人对其闭源嗤之以鼻，但其对 Emacs 核心交互的精准复制值得观察。如果能定义出一套可移植的“Emacs 交互标准”，对社区或有益。
• Lem 的 Web/Electron 路线：作为 Common Lisp 生态中的现代化编辑器，Lem 逐渐放弃纯 SDL 拥抱 Electron/Web UI，值得思考是否会给 Emacs 的未来 UI 方向带来启发。
• emacs-skia 与 SDL terminal type 的实际进展：可追踪 debbugs #80271、Arthur Heymans 的 SDL 终端分支以及 ewm 作者的 skia 实验，它们代表了“换底”派的最新尝试。
• Emacs 的可移植 2D 抽象层：是否存在一种方式，既能屏蔽多平台脏活，又能保持 Emacs 自绘的自由？如果 Skia/SDL 均难入上游，是否可以考虑嵌入一个轻量级的纯软件矢量渲染库（例如 nanovg 级别的）？

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“Emacs 该不该换个图形库”，而是一个更硬的判断：Emacs 的 GUI 痛苦，本质不是渲染性能问题，而是抽象边界长期错位。它把“自绘编辑器”做成了“半个跨平台应用框架”，却又没有真正拥有现代应用框架该有的窗口、输入、焦点、IME、拖放、无障碍、多显示器等统一能力。

1. “自由”如果不能降低维护成本，就会变成技术债

群里有人说多平台各自维护的好处是“不被跨平台 GUI 库绑定”。这话成立，但只成立一半。工程上的自由不是“我什么都自己写”，而是“关键控制权在我手里，非关键复杂性外包给稳定层”。

Emacs 屏幕内容大量自绘，这让它不太需要传统控件库；但它仍然逃不开系统集成层。IME preedit、剪贴板 selection、窗口生命周期、焦点、Dock、任务栏，这些不是编辑器创造力的来源，而是平台脏活。把脏活保留在核心项目里，并不会让 Emacs 更自由，只会让每个新 GUI 能力都变成 N 个后端的排列组合测试。

2. TUI/GUI 共用抽象，是历史兼容，也是创新阻尼

“给光标做动画都难以可移植实现”这个例子很关键。它说明问题不在动画本身，而在抽象层把 TUI 和 GUI 拉到了同一个最小公约数上。

TUI 的价值是远程、脚本、低依赖、可救急；GUI 的价值是表达力、交互密度、图形化反馈。两者都重要，但不应该互相绑架。工程上更合理的方向不是“放弃 TUI”或“所有端保持一致”，而是承认它们是不同能力层：核心编辑模型共享，显示能力分级暴露。否则 GUI 永远像戴着终端手铐跑步。

3. “换 Skia/SDL/Web”不是银弹，真正要换的是决策接口

Cairo 没硬件加速、Skia license 和 release 问题、SDL 可能损失 WebView 能力，这些讨论表明：找一个完美 2D 库很难。但更深的问题是，即使明天有完美图形库，Emacs 也需要先定义哪些能力属于“渲染层”，哪些属于“平台服务层”，哪些属于“编辑器语义层”。

Rune 和 Lem 的出现有参照意义：前者试图复制 Emacs 交互语义，后者在 Web/Electron/SDL 间摇摆。它们都在证明一件事：Emacs 最值钱的不是 C 实现，也不是某个 GUI 后端，而是 point、mark、region、minibuffer、kill ring、buffer/window/frame 这些交互语义。如果这些语义能被更清晰地协议化，前端路线反而可以多样。

可继续实践的方向

不要先争“Emacs 应该用 Skia 还是 SDL”。更可验证的实验是：选一个小而尖的 GUI 能力，例如光标动画、图片切片平滑滚动、每行不同高度、富文本预览，写出一份能力分层设计：核心语义需要什么，GUI 后端需要什么，TUI 如何降级。能把这个接口跑通，比空谈“重写前端”更接近真正的现代化。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题一】AI编码工具的模型调度、成本与工作流优化

深夜群友对比了 DeepSeek-V4-Flash 与预览版甚至 Pro 版的差异，认为 Flash“比预览版的 Pro 都强”，且猜测 OpenAI 在 DeepSeek 内有内应以辅助 Luna 定价。随后话题转向 Codex 使用限额：Tibo 宣布重置 Codex 与 ChatGPT Work 的用量，群友反馈“太残暴了，逼我用 fast”，但实际体验中 Max 账户即便不开 fast 也只用了 50%，说明近期模型效能或限额策略已发生微妙变化。

更深入的讨论聚焦于 “高级模型规划 + 廉价模型执行”的组合工作流。有人寻求“融合 SOL 和 DeepSeek”的有效方案，其核心诉求是：在降低推理成本的同时不增加心智负担。群内出现了几种实践思路：

• 通过 OMP（推测为某种编排协议） 让高级模型生成 Plan 并短时间运行，随后切换至低阶模型继续，且让高阶模型先行探索代码库，以传递上下文与目标导向。
• 反对声音指出 Claude Code 的 harness 不如 Codex，纯粹依赖模型自身能力，表明工具链的“驾驶舱”设计同样关键。
• 也有人发现 Luna 5.6 模型内部会调用 5.5 来干活，怀疑是 omx 机制导致，这揭示了多层模型间的隐形调用已成为成本与行为分析的新变量。
• 同时，Pro 版本的价格策略被寄予厚望，群友预测“若维持原价，会杀穿另外两家”。

【专题二】Emacs 深度定制：Minibuffer 子框架、代码评论对齐与界面雕琢

一场关于 Minibuffer 交互体验 的探讨从凌晨持续到上午。核心围绕fido-frame与 vertico-posframe 在显示嵌套 minibuffer 时的行为差异：

• vertico-posframe 通过重定向实现，但在 Linux 下光标仍驻留在原生 minibuffer 而非 child-frame 上，部分用户更偏爱 fido-frame 那种“光标直接落在 child-frame”的感觉。
• fido-frame 的实现极为简洁——仅用一个 child-frame 并设置参数只显示 minibuffer（代码链接：minibuffer-frame.el），这种方式避免了窗口焦点切换的麻烦（不需要自动切回，且支持补全中途跳出，甚至可能天然兼容递归 minibuffer）。
• 开发者坦言尚未在递归场景下测试，但“简单到不可思议”的代码为社区提供了一个极具参考价值的 UI 方案。

另一个精彩的技术点来自代码评论的框线绘制。当被问及 Emacs 中精美的 Unicode 评论边框如何实现时，答案揭示了红显示（redisplay）的高级技巧：

• 在目标行末放置零宽 overlay，通过 after-string 插入由 ╭─╮ │ ╰─╯ 组成的带 face 字符串。
• 宽度先用 string-width 计算，右侧边框借用 (space :align-to ...) 与 string-pixel-width 做像素级对齐，确保 CJK、Emoji 及字体缩放时依旧整齐。
• 分屏模式下，两侧评论共享同一条垂直 lane，短侧自动补透明换行以保持后续代码对齐。 这种 “Unicode 框线 + overlay after-string + space :align-to 像素定位” 的组合，堪称 Emacs 界面工程的典范。

此外，群内还涉及少量 Emacs 录制功能（疑似 Codex 调用系统录屏）、comment 高亮对齐 bug、以及 gh-stack 前端更新等细节。

---

🔑 关键概念与技术解析

• Pi：群内提到的 AI agent 客户端，用于接入不同模型，在 DeepSeek 新模型测试中被提及，显示出一定流行度。
• Luna：OpenAI（或 Tibo 关联服务）中的一个模型层级，有 5.5、5.6 等版本，存在内部模型互相调用的行为，且降价时机引发对其竞争策略的猜疑。
• Codex Reset：Tibo 为庆祝效率周而重置 Codex 及 ChatGPT Work 的用量限制的操作，直接影响用户的使用节奏。
• SOL Xhigh：指某个高性能模型（或配置），被用于与 300B 参数模型进行能力对比，200B+ 模型的期待与之挂钩。
• OMP：可能是某种用于模型编排的协议或框架，能够实现“高级模型规划→低级模型执行”的流水线。
• fido-frame / vertico-posframe：Emacs 中两种将 minibuffer 转移到 child-frame 的实现。前者直接创建显示 minibuffer 的 child-frame，后者通过对 minibuffer 的重定向实现。
• Recursive minibuffer：Emacs 中在已经激活 minibuffer 的情况下再次调出 minibuffer（如连续按 M-x），对 UI 子框架的切换与焦点管理是高级挑战。
• ra (rust-analyzer)：被包装成 CLI 工具用于重命名等操作，避免编写冗长 patch 文件，体现了将 LSP 功能前移到终端的轻量用法。
• org-supertag：一个 Emacs 笔记工具，已完善备份与同步功能，可直接对接 GitHub 等 git 网络服务，实现知识库的版本控制。
• open-slopware（https://codeberg.org/ethical-foss/open-slopware）：一份维护了“无 AI 参与编写的软件”列表，响应了反 AI 运动中开发者寻找纯净工具链的需求。

---

💎 碎片知识与金句拾遗

• “我现在怀疑 OpenAI 在 DeepSeek 里也有间谍，luna 降价的时机刚刚好。”——略带阴谋论的价格战观察。
• “Codeberg 那边把 https 的验证关了，ssh 可以 push。我去给我吓一雷。”——凌晨 403 问题最终通过切换协议解决，体现自托管 git 平台的临时故障特征。
• “Gmail 要什么 reset🤣”——针对 Tibo 痴迷于各种 reset 操作的调侃，透露出对不断重置限额的幽默无奈。
• “我的 fido-frame 代码特别简单，简单到有点不可思议了。”——对优雅解决方案的自豪，同时指路 minibuffer-frame.el。
• “但你还是需要一个 daemon，不然会很慢。那不如试试写个 cli 走 tcp 发 request。”——针对某工具的延迟问题，提出用 tcp client 代替 daemon 的轻量化思路。
• “我发现 5.6 luna 在调用 5.5 干活。”——发现了 AI 模型内部偷懒的“套娃”行为，可能源于配置或 omx 干扰。
• “重命名函数/变量之类的就不用写好长的 patch 了，简单包装一下 ra 来当 cli 用。”——分享一个将 rust-analyzer 转化为命令行重命名器的实用技巧。
• “他们只是想找一个没有 AI 参与软件编写流程的替代品，git 允许 AI 贡献，逻辑就是这样。”——精炼概括反 AI 运动的部分动机，并引出 BitKeeper 的复古替代。
• “AI 不知道哪里找过来的辐射图……”——对 AI 生成内容来源不明的感叹。
• “Unicode 框线 + overlay after-string + space :align-to 像素定位”——一句概括 Emacs 评论框线绘制技术的精髓。
• “指望 300B 的模型打 sol xhigh，想屁呢。”——对参数体积与实际能力关系的犀利点评。

---

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

• fido-frame 极简 minibuffer child-frame 实现：代码量极少却解决了嵌套 minibuffer 的潜在焦点问题，适合深度分析其与 vertico-posframe 的架构差异，并测试递归 minibuffer 的兼容性。
• Emacs comment 边框的像素级对齐技术：after-string overlay 配合 space :align-to 与 string-pixel-width 的完整实现，可作为高级 Emacs 界面开发的范例。
• 多模型编排的低心智负担方案：当前“高级模型探索+廉价模型执行”的流水线仍缺乏成熟的社区标准，如何平衡性能、成本与上下文传递值得持续关注，尤其是 OMP 等方案的进展。
• open-slopware 列表：该项目整理了无 AI 参与的软件，可作为研究“手工软件”生态与反 AI 运动演变的切入口。
• ra (rust-analyzer) 的 CLI 包装：将 LSP 功能剥离为独立命令行的思路，可推广至其他语言的工具链，降低脚本化重构的门槛。
• org-supertag 的 git 同步机制：结合 Emacs 知识管理与分布式版本控制的实践，适合探索个人知识库的自动化备份与多端协作方案。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“哪个模型更强”，而是两个更硬的工程判断：第一，AI 编码的瓶颈正在从模型能力转向调度系统；第二，Emacs UI 的魅力不在“可定制”，而在它允许你把显示层当成可编程工程对象。

1. “高级模型规划 + 便宜模型执行”只有在 harness 足够强时才成立

群里提到的诉求很准确：用强模型做规划、弱模型做执行，前提不是“能省钱”，而是“省钱时不增加心智负担”。这句话把多数多模型工作流的虚假繁荣戳穿了。

如果切模型之后，人还要重新解释目标、修上下文、判断低阶模型有没有跑偏，那成本只是从 token 账单转移到了人的注意力账单。所谓有效编排，必须满足三个可验证条件：强模型探索代码库后留下的 plan 是否能直接驱动执行；低阶模型是否能在失败时回报结构化状态，而不是吐一堆半成品；harness 是否能把测试、diff、上下文、回滚变成默认控制面。

所以“Claude Code harness 不如 Codex，纯靠模型强悍”这个反馈很关键。未来 AI coding 的胜负不只是模型榜单，而是驾驶舱质量：上下文怎么装载，计划怎么冻结，执行怎么审计，失败怎么归因。模型内部“5.6 调 5.5 干活”这种套娃现象也提醒我们：只看入口模型名已经不够，真实成本与行为边界必须从 trace、调用链和产出稳定性上验证。

2. fido-frame 的价值在于：简单不是少写代码，而是少制造状态

fido-frame 与 vertico-posframe 的差异，看似是 child-frame 里光标在哪里，实际是 UI 架构里的状态管理问题。

vertico-posframe 的重定向方案更像“显示挪走了，但真实交互还留在原处”；fido-frame 直接创建只显示 minibuffer 的 child-frame，则更接近“让界面结构符合用户感知”。群里提到它“不需要自动切回”“补全中途跳出可能天然支持”“递归 minibuffer 待测”，这些都是同一个判断：好的 Emacs 扩展不是把视觉效果缝上去，而是让 Emacs 自己的 buffer、frame、minibuffer 机制少打架。

评论框线那段也是同理。overlay after-string、Unicode 框线、space :align-to、string-pixel-width 并不是炫技，而是把“好看”拆成可测量的工程约束：CJK 宽度、Emoji、字体缩放、分屏 lane、透明补行。审美在这里不是主观形容词，而是 redisplay 层面的不变量。

3. 可继续实践的方向

可以把今天两个话题合成一个小实验：为 Emacs/Agent 工作流建立“可验证 UI 与可验证 Agent”的标准库。前者收集 child-frame、overlay、像素对齐、递归 minibuffer 的最小示例；后者收集强模型 plan → 弱模型执行 → 测试回报 → 人类审计的最小 harness。别先追求宏大框架，先做一批能跑、能复现、能失败得明白的 reference cases。真正的社区质量提升，往往不是靠口号，而是靠这些小而硬的工程样本。