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

Emacs 中文讨论组

🎯 核心热点与专题探讨

【专题】Emacs 终端（TUI）下 Emoji 显示崩溃与渲染错乱的深度分析与修复

这是本日讨论最激烈、技术含量最高的话题。群成员在使用 TUI Emacs 时，遇到了严重的渲染崩溃问题，尤其在打开包含 emoji 的 rime 配置或 telega 时，整个 Emacs 渲染会乱掉。

痛点与复现：

• 群友普遍反映不敢在 -nw 模式下打开 telega，因为 emoji 会导致整个渲染崩溃。
• κόσμος 发现即使像 rime 的配置文件这样包含少量 emoji 的场景，也足以复现“渲染乱掉”的问题。

根因分析与修复过程：

• κόσμος 深入研究并定位了两个核心 Bug：
  1. Grapheme cluster 宽度计算有误（第一阶段发现）。
• 他通过一个测试用力的研究报告（AI 辅助），证明了 Emacs 和 Kitty 在不同宽度 emoji 的认知上都有错误。例如，对于 👍🏽 (modifier)，Emacs 计算宽度为 4，而 Kitty 为 2，实际应为 2。 2. auto-composition 机制违反内部 invariant（根本原因）。
• 详细机制：当 auto-composition 将 FE0F (Variation Selector-16) 和它前面的 emoji 组合（compose）成一个复合字形（composite glyph）后，生成的这个 composite glyph 的宽度是 2。
• 矛盾点：然而，TUI 的 glyph matrix 在维护索引时，预设每个 glyph 的宽度均为 1。这导致后续所有 glyph 的 X 坐标都产生了 1 个单位的偏移，最终引发显示错乱和崩溃。
• 修复方案：在生成 composite glyph 后，为其增加一个 padding glyph，从而修正 glyph matrix 的索引。
• κόσμος 在群里分享了初步的 PoC patch，测试后确认 rime 配置已经不再导致崩溃。
• 此外，κόσμος 还发现即使在宽度计算“正确”的情况下（如 \u26A1\uFE0F 宽度为 2），在 wezterm 等现代化终端中仍可能意外折行。他判断这是终端将某些字符进一步 compose 所致，而 Emacs 的处理在这种具体案例下反而是对的。他感叹 “终端发展了这么多年怎么还这么草台”。

后续行动与遗留问题：

• κόσμος 计划将修复问题 2 的 patch 整理并提交给 Emacs 上游。他认为问题 1 的宽度计算是更大的坑，留待将来。
• 他提到 Eli (Emacs 维护者) 倾向于对 emoji 处理进行正确方式的重构而非 workaround，这让社区贡献者感到压力很大（“给我看麻了”）。
• 群友普遍认为，能修掉崩溃问题，让 TUI 变得“可用”，就是巨大的进步了。

---

【专题】Emacs 生态工具之争与实践：Flycheck 38 发布与 TUI 演变

Flycheck 38 大版本更新的影响

• 核心变化：Flycheck 38 作为作者接手以来最大、最具野心的版本发布。它内置了对 Eglot 和原生 lsp-mode 的支持，消除了对第三方包如 flycheck-eglot 的依赖。
• 群友反响：
  • 一部分用户早已从 Flycheck 转投内置的 Flymake，认为功能已经足够。
  • 另一部分用户则被新版本吸引。一位从 Flymake 转来的用户表示，因为 flymake 有时会出现诊断信息不刷新的问题，而新版 Flycheck 的 eglot 支持好用了，global-flycheck-annotate-mode (内联诊断，类似 Error Lens) 看起来也比较现代，因此打算试用。
  • 一位用户指出，Flycheck 仍然有独占功能，例如“应用检查器建议的自动修复”（C-c ! f / C-c ! F），这是 Flymake 不具备的。

TUI 下的 Emacs 体验演进

• 痛点与解决：
  • Telega 头像显示：群友在探索让 telega 在 TUI 下显示头像。目前通过配合 kitty-graphics 协议可以手动触发显示，但无法让头像和图片始终显示。
  • 图片显示抽象化：有群友提议应将图片显示能力抽象出来，以便 telega 等应用能更好地适配支持图片协议的终端。
  • 粘贴图片问题：telega 在 TUI 下无法粘贴图片，可能与剪贴板实现有关。
• 总体评价：群友认为 TUI Emacs 已经很好用了，甚至在单纯开发体验上 Linux 已经超越了 macOS。除了 emoji 支持的 Bug 外，没有大的痛点。

---

【其他讨论】Emacs 社区贡献与 AI 伦理

• 一则名为 "emacs-master-gains-claude-co-authored-commit-despite-gnu-ban" 的新闻引发了讨论。一个由国内开发者提交的 commit 标注为与 Claude Fable 5 共同撰写，这在 Emacs devel 邮件列表中引起了不安。
  • 核心争议点：
    1. “与 XX 共同撰写”的署名方式被视为对 AI 公司的营销，类似“发自我的 iPhone”。
    2. Commit 的作者日期 (Author Date) 标注为 2026 年 5 月 20 日，但该 AI 模型在当时并未对公众开放，引发了真实性的质疑。

---

🔑 关键概念与技术解析

• Eglot：Emacs 内置的一个轻量级、可扩展的 LSP (Language Server Protocol) 客户端，与 lsp-mode 是竞争/互补关系。
• Flycheck / Flymake：Emacs 中两大实时语法检查框架。Flycheck 功能更丰富、插件更多；Flymake 是内置的，更轻量。
• TRAMP (Transparent Remote Access, Multiple Protocols)：Emacs 的一个特性，允许用户通过 SSH 等协议透明地编辑远程文件，如同在本地一样。Flycheck 38 新增了对 TRAMP 远程文件检查的支持。
• Composite Glyph：在 Emacs 渲染引擎中，将多个字符组合（如 emoji + FE0F 或 ZWJ 序列）形成的单个字形单元。这直接关系到 emoji 的显示。
• Glyph Matrix：终端（TUI）Emacs 在内存中维护的一个网格结构，用于追踪每个屏幕单元格（cell）上应显示的字形（glyph）。这是本次 emoji Bug 的核心所在。
• ZWJ (Zero Width Joiner)：零宽连字，Unicode 中用于连接两个字符，使其表现为单个字符（如家庭组合 emoji 👨‍👩‍👧‍👦）。
• VS15/VS16 (Variation Selectors)：Unicode 中的变体选择符。FE0E (VS15) 请求文本样式，FE0F (VS16) 请求表情样式。它们是导致 emoji 宽度问题的关键因素。
• OC Collective：开源资金支持平台，Flycheck 作者提及在该平台三年的收入不足 300 美元，反映了独立开源维护者的资金困境。

---

💎 碎片知识与金句拾遗

• MBTI 与 Emacs 使用习惯：“所以我都不用 org mode 的 gtd... 因为我 p 人不喜欢做计划... 都是心血来潮就开始搞”。揭示了 P 人（随性）与 J 人（计划）在工具选择上的潜在差异。
• Emacs vs. Vim 的非英环境体验：“Emacs 默认不是 vim 这样的模态编辑器，感觉在非英环境更顺手一些。” 道出了非模态编辑器在需要混输中文等非英语言时的天然优势。
• 开发体验：“最近折腾下，单纯开发体验，感觉 Linux 已经比 macOS 好了”。以及 macOS 用户的回应：“我：从来没觉得 macOS 比 Linux 在开发上更好过”。Linux 开发环境的生态优势正在凸显。
• Headline/Header-line 的对齐问题：一位群友在研究 tabulated-list 表格的居中对齐时，发现即使在 Emacs 30.1 和 master 分支上，min-width 文本属性在 header-line 的 redisplay 路径上也不被支持，这是底层实现的一个局限。只能通过左对齐加手动填充空格来迂回实现。
• Emacs Lisp 的 autoload 技巧：当需要在文件局部变量中使用自定义格式器时，如果对应的包是 autoload 加载的，那么其安全局部变量的声明（safe-local-variable）会在首次打开文件时缺失，导致 Emacs 不断询问。解决方案是为其添加 ^;;;###autoload magic comment：;;;###autoload (put 'VAR 'safe-local-variable 'PRED)。
• Emacs 全栈化生活：“我只配置好了收邮件... 还没配置发邮件... 也没配置多个账号（”。经典的全 Emacs 化工作生活的进行时状态。
• 对 openmp 的怀念：“看到 omp 第一反应是 openmp 我已经落伍了嘛（”，当新缩写出现时，老一代程序员的惯性思维。
• Neomacs 的 Fringe 能力：“neomacs 的 fringe 可以显示各种花里胡哨的 Glyph, 图片，gif，视频，想显示什么就显示什么... 但是 neomacs 的 fringe 仍然可以和 gnu/emacs 100% 兼容”。
• AI 辅助开发的窘境：“还没自己看，ai就写好了研究报告和 test harness, 自愧弗如... 结论就是 emacs 的算法是错的 = =”。AI 的高效生产力让开发者既兴奋又感到一丝不安。
• 草台论：“终端发展了这么多年怎么还这么草台”，在多次发现终端 emoji 复杂处理的不一致性后发出的深刻感叹。

---

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

1. Emacs TUI Emoji 宽字符修复补丁：κόσμος 正在研究的 PoC patch。这是一个直接影响所有终端用户的底层修复，若能进入上游，收益巨大。值得追踪其在 emacs-devel 邮件列表的后续讨论。
2. Emacs TUI 的图像显示生态：kitty-graphics 协议在 telega 等应用中的普适性适配。研究如何将图片显示逻辑从具体应用中抽象出来，形成一个通用的、协议无关的 TUI 图形显示层。
3. Neomacs 的 Fringe 渲染管线：其 Fringe 能与普通 Buffer 共享渲染管线的设计思想，使其能低成本、高兼容性地展示富媒体元素。这种架构对于 GUI Emacsen 的拓展性很有启发。
4. corfu 补全吃掉后续字符的 Bug：eglot 配合 corfu 在行中补全时，“随机吃掉后面的字”以及补全出错误内容（如 .func() (as Trait)）的现象。这是一个影响日常编码体验的 Bug，值得有能力的开发者去复现和修复。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“Emacs TUI 能不能显示 emoji”，而是一个更硬的工程判断：越底层的抽象，越不能靠“看起来能显示”验收。Emoji 把终端、Unicode、字体、composition、glyph matrix 这些平时被用户忽略的层全部撕开了；而 Emacs 这次的问题，恰好说明一个老系统最危险的地方不是功能少，而是内部 invariant 和外部世界的复杂度开始错位。

1. “终端草台”不是吐槽，是工程边界失控的症状

群里定位到的问题很典型：auto-composition 把 FE0F 和前面的 emoji compose 成宽度 2 的 composite glyph，但 TUI 的 glyph matrix 索引路径仍按“一个 glyph 一个 cell”的假设推进，结果后续 X 坐标整体偏移。这个 bug 的可怕之处不在 emoji，而在于它违反的是数据结构层面的契约。

所以“加 padding glyph”不是脏修，而是在当前架构下恢复 invariant：既然 matrix 的消费方按 cell 推进，那生产方就必须补齐 cell 占位。至于 grapheme cluster 宽度计算是否全面正确，是另一个更大工程。把“避免渲染乱掉”和“完全符合 Unicode 复杂语义”拆成两个层级处理，是成熟工程判断，不是逃避重构。

2. 上游想要正确重构，用户想要今天能用：两者都对

Eli 倾向于按正确方式重构 emoji 处理，贡献者觉得“看麻了”，这个张力很真实。维护者怕的是 workaround 堆穿架构；用户怕的是 TUI Emacs 连 telega、rime 配置都不敢开。

这里的判断标准应该很朴素：如果一个局部 patch 能证明它恢复了现有 invariant、缩小了破坏面、并且有明确测试覆盖，那它就不是随手 workaround，而是可合并的风险控制。大重构可以继续，但不能把“未来正确”当成“现在不可用”的理由。老软件的演进经常不是一步到位，而是先止血、再分层、最后替换抽象。

3. AI 辅助开发在这里真正有价值：不是替人写 patch，而是放大可验证性

“AI 写好了研究报告和 test harness”这句很关键。AI 在这种底层问题上最有用的地方，不是给出最终权威结论，而是快速生成 case matrix：👍🏽、ZWJ、flag、VS15/VS16、keycap 等，把 Emacs 和 Kitty 的宽度认知差异摊开。工程上这比“我感觉某个 emoji 会坏”强得多。

但最后仍然必须回到人能验证的东西：最小复现、源码路径、内部 invariant、补丁前后行为。AI 可以扩大搜索面，人必须收敛判断面。

可继续实践的方向

把这次讨论沉淀成一个 Emacs TUI emoji regression test pack：覆盖 VS16、ZWJ、modifier、flag、keycap、快速刷新残留、telega/rime 真实场景。先证明“不会把 glyph matrix 打乱”，再逐步追“宽度完全正确”。这比泛泛争论 TUI/GUI、Flycheck/Flymake、AI 署名，都更接近能进入上游的工程成果。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

🌪️ AI 编程工具的“额度焦虑”与应对之道

从深夜到傍晚，群内的主线始终围绕Codex 每周限额大幅缩水展开。大量用户反馈过去一个长时间任务会吃掉 30% 限额，甚至有人一觉醒来发现“跑掉 30% 周限”，晚间不断有人播报剩余额度：8%、3%、0%。抱怨焦点直指平台一边宣称上线算力集群，一边反而砍量改套餐，且对老用户权益打折扣。“minimax 都敢给老用户无周限/150%周限，虽然模型菜，但态度在”——这种对比更放大了不满。 为了对抗限额，群策群力出现了：

• “网页文件库”技巧：把项目打 zip 扔到 GPT/Claude 网页文件库，让它解压继续完成代码任务，全程不消耗 API 额度，最后再打包回传。
• 模型结对编程：用 Kimi 出想法，Codex 校验想法，让异构模型各司其职而非无意义循环讨论。
• Cursor 的降维打击：多位成员盛赞 Cursor 的工具链调用速度比现有 CLI 快一个数量级，且其 composer 功能、文件 diff 体验让人羡慕；但也受限于必须包月或 API，以及无法使用部分微软专有调试器。
• 其他渠道探索：Codex 被指“耐用性提升 18%”，但不少人仍觉得一个 task 干掉大半限额；有人尝试用 pi 反代、cc-switch 编排，却被吐槽“在 home 下随地大小便”。

行业动态穿插其间：翁荔重返 OpenAI 负责“递归自我改进”研究；字节跳动宣布飞书与豆包团队合并，成立新 ToB 组织“创造力服务平台”。这些信息在开发者群中引发的不是商业分析，而是“又是资源集中，会不会让散户更难用”的警惕。

---

🔑 关键概念与技术解析

• Codex (OpenAI Codex CLI)：OpenAI 推出的编程智能体，可在终端直接执行代码、操作文件，但已全面改版为限额制，导致重度用户大量吐槽。
• Cursor：基于 VSCode 的 AI 编程 IDE，其 composer 可调用多模型进行复杂任务，工具链调度速度极快，被评价“各种层面已完爆 VSCode”，但需包月且不兼容部分微软插件。
• Kimi K3：月之暗面的最新模型，开放初期曾引发购买潮，后因“限购、调额度、改套餐”而被类比为“一强就砍”的典型。
• Minimax：另一国产大模型，模型能力弱于头部，但对待老用户更慷慨（无周限或 150% 周限），被用作“态度对比”的标杆。
• pi (Project IDX? 或某 agent harness)：这里指一种可以串联多个 AI agent 的工作台/运行环境，支持反代 Codex 等服务，被诟病不遵循 XDG 规范在 $HOME 下创建大量配置目录。
• Ghostty：Mitchell Hashimoto (Terraform 作者) 退休后开发的玩具级终端模拟器，其作者对开发的哲学观点颇受关注。
• multiplexer：终端复用器（如 tmux、zellij、herdr、orca 等），群内讨论提及 herdr 更轻量，orca 则是为 AI 加插件的重型工具。
• Vicinae：一个基于 Wayland layer 层的应用启动器/菜单，能安装 Raycast 插件，但在 Niri 等窗口管理器中无法调大小。
• Noctalia：一个 Emacs 发行版/配置框架，有插件展示、launcher，但插件排序只用字母，被用户吐槽。
• Telega：Emacs 的 Telegram 客户端，基于 TDLib，支持补全、Sticker 显示等。群内出现了补全 bug 和 Sticker 透明背景的 patch 讨论。
• Kanata / Keyd：Linux 下的键盘重映射工具。Keyd 维护缓慢，Kanata 采用类 Lisp 配置，支持 tap-hold、combo 等高级功能，可实现与 QMK 固件相似的层布局。
• XDG 规范：Linux 下目录配置标准，被吐槽很多 CLI/TUI 程序不遵守，在 $HOME 下乱建目录。
• Combo / Tap-Hold：键盘客制化概念，combo 指同时按下多个键触发动作，tap-hold 指定按与长按不同功能，容易误触需精细调校。
• FSF Copyright Assignment：向自由软件基金会转让代码著作权，过程漫长（约一月一回复），且会追问是否使用 AI 生成代码。

---

💎 碎片知识与金句拾遗

• 抱怨平台霸道：“这公司办不下去别办了算了，但凡改套餐之后给我加点量或者给老用户多点权益呢？”
• 对 DeepSeek 的期待：“等谁都不如等 deepseek，他这样子搞依旧能赚钱，说明其他的还要黑心的多——也就是他所谓的资本想要的 20 倍利益。”
• Mitchell Hashimoto 的轶事：Terraform 作者之一，公司被 IBM 收购后退休，Ghostty 是他的“玩具项目”；有群友羡慕“这么年轻就退休”，另一人补充 “surge 的老刘也退休了”。
• 代码提交流程的黑色幽默：“总共三个人盘问，吓哭了”；“跟面试无区别了”；“我去回答了一些问题后，他们没回邮件”。
• 使用 AI 生成 Patch 的窘境：“patch 是 ai 弄的，我没法回答提交 patch 时的一些问题”。
• 对 Cursor 的惊叹：“cursor 当时的 diff 刚出来我可是口水流了一地啊，就想着 Emacs 内能有”。
• 键盘客制化金句：“别人拿到这个键盘都得先思索半分钟，感觉比给硬盘加密都有用”。
• Telegram 新号限制实战：新号不能太频繁发言，某用户因在小说群玩文字游戏，号直接没了。
• 笔记本网卡计划报废：“我才过保没多久，网卡开始掉了……他们厂商可能就是都算好了，哪个零件在什么时间之后容易坏”。
• 起英文名的脑洞：“让我儿子继承你的英文名，后面加一个二世，叫 Lucius II，LVCIVS II”；“带我儿子先把 QQ 号养起来”。
• 开源项目的自嘲：“总是感觉你晚生了几年，错过了笔记火热那一段时间”；“非得以成败来论的话，这个世界很难有趣，因为满眼的失败，失败之多，多不胜数”。
• 工具评价：“Windows 的 dired 打开文件夹多的文件特别特别卡”（指 Emacs 的 dired 在 Windows 上性能差）。
• 字节跳动动态被戏谑：“豆包飞书合并，有一种 QQ 的既视感”。

---

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

• Rust 重写的 Sunshine：有人提到用户用 Rust 重写了串流服务 Sunshine，已在编译，该项目可以关注其稳定性和性能提升。
• Kanata 键盘重映射：因其类 Lisp 配置、tap-hold 与 combo 支持，正逐渐取代 Keyd，适合追求键盘层定制且需要 QMK 风格功能的 Linux 用户。
• Emacs 表格布局引擎 grid-table：已实现横向与纵向单元格合并，意在向 Excel 方向靠拢，并计划将技术移植到 org-supertag 的 table-view 中。该项目源于作者对 Emacs 内完善表格布局的实验，值得跟踪。
• org-supertag 笔记系统：以标签（集合）方式管理笔记，挑战 org-roam、denote 等路线，作者强调“不以成败论有趣”，其设计思路与技术实践可作为知识管理工具的新参考。
• Cursor 的 API 接法与性能细节：Cursor 团队曾提到数据传输是最大瓶颈并定向优化，这股对工具链速度的极致追求是否能在开源 CLI 中复现，值得技术强人深挖。
• Codex 限额绕过技巧：网页文件库 + zip 解压的方式已被证实可行，后续能否发展成通用 Workflow 或与 Emacs 深度整合（如 diffs.el 的集成分支），是兼具实用与趣味的研究方向。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的，不是 Codex 又砍了多少额度，而是一个更硬的判断：AI 编程正在从“谁模型最强”转向“谁能把不稳定算力变成稳定工程产出”。额度、工具链速度、diff 体验、FSF 对 AI patch 的追问、Emacs 里自造 diffs/grid-table，这些看似散乱，其实都指向同一个问题：AI 不是替你写代码的魔法，而是把工程系统里的薄弱环节放大了。

1. 额度焦虑暴露的是“无预算工程”的失败

一个长任务吃掉 30% 周限，表面是平台黑心；但工程上更关键的是：很多 AI 编程流程没有成本模型。

以前写代码的成本主要是人的时间，现在变成了“人类注意力 + 模型额度 + 上下文污染 + 工具链延迟”的组合成本。群里说用 Kimi 出想法、Codex 校验想法，比让两个 agent 自动循环讨论靠谱，这个判断很重要：多模型协作的价值不在“自动化程度更高”，而在“把不同不确定性隔离开”。

可验证的工程判断是：一个 AI workflow 是否成熟，不看它能不能一口气跑完大任务，而看它能不能把任务切到每一步都有明确输入、明确验收、明确回滚点。否则所谓 agent，只是在用更贵的方式制造不可审查的变更。

2. Cursor 被羡慕，不只是因为模型，而是因为它减少了摩擦

群里反复提到 Cursor 工具链调用快、composer 快、diff 体验好，甚至有人说当年看到它的 diff “口水流一地，想在 Emacs 内能有”。这不是 UI 洁癖，而是工程效率的核心：AI 修改代码之后，真正决定能不能进入生产的，不是生成瞬间，而是审查、理解、局部接受、回滚和再次修改。

所以 diffs.el 这种东西有意义。它不是重复造 ediff，而是在补 AI 时代 Emacs 缺的那块：面向 hunk、评论、外部读取、agent 协作的 diff 基础设施。以后编辑器的护城河可能不是“能不能接大模型”，而是“能不能把模型输出变成可审计的工程对象”。

3. “开源项目要什么就自己动手”在 AI 后变成了新常态

telega patch、noctalia PR、grid-table 横纵向合并、Kanata 迁移配置，这些都说明一件事：AI 降低的不是“写代码”的门槛，而是“动手修自己工具链”的心理门槛。

但 FSF 追问 AI patch 所有权，也提醒了另一面：AI 可以加速苦力活，却不能替你承担解释责任。你提交的 patch，如果自己无法解释设计取舍、边界条件、测试方式，那它仍然不是你的工程成果。AI 时代的开源贡献，最低标准会从“我写了”变成“我能证明它为什么这么写”。

4. grid-table 和 org-supertag 的意义在于：玩具项目也可以产生真实基础设施

晚间关于 grid-table 的讨论很有意思：起点不是“我要打败 Excel”，而是在 Emacs 里实验完善表格布局，再迁移到 org-supertag 的 table-view。这里的关键不是实用主义，而是作者自己高频使用、自己被问题折磨、自己愿意长期打磨。

“作者用得越勤，质量大概率越高”这句话很朴素，但很准。个人知识系统、Emacs 包、键盘布局这类工具，最怕做成展示型项目；真正有生命力的项目，通常来自一个人对自己工作流的持续偏执。

可继续实践的方向：把今天这些讨论收敛成一个小型 Emacs AI 工程栈实验：用 diffs.el 承接 AI patch 审查，用明确 issue 驱动小 PR，用 Kanata/快捷键减少上下文切换，再记录每次 AI 任务的额度、耗时、diff 大小、返工次数。别只感叹哪家模型更强，直接测：什么样的流程能以最低摩擦产出可解释、可维护、可合并的代码。