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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：Emacs 五十周年与 Stallman 工具生态的怀旧讨论

群聊以「EMACS 五十周年」拉开序幕，引发了对 Richard Stallman 及其工具链（Emacs、GCC、GDB）的个人使用回顾。讨论中一位群友分享了自己“各用了一年”的经历，被另一人误读为“你用了 Stallman?”，随后澄清是“他写的这些工具各用了一年”。这段轻松的对话不仅致敬了自由软件运动的历史，也侧面反映了 GNU 工具在开发者日常工作中的深远影响。

专题二：org-table-widget 渲染性能优化与表格边框问题

这是群内最激烈且技术深度最高的话题。群友指出 org-table-widget 处理 500 行表格仅需 100ms，而 valign（另一种表格渲染方案）则需要 2600ms，性能退化严重。随后，针对“表格边框不连续”的痛点，大家提出了多种解决方案：

• 等宽字体方案：直接切换字体，简单有效。
• SVG 渲染方案：根据行高动态设置表格线高度，已被一位群友成功应用并展示了美观的效果。
• 行高匹配字体：选用与表格线相同行高的字体。
• etaf 方案：有群友推荐了 etaf 和 exc.el 中的处理逻辑，并讨论其在可编辑 buffer 中的适配性，但 etaf 作者表示目前并未考虑 undo 信息绑定等复杂编辑状态。

此外，有群友分享了自己对 valign 打小 patch 来提升性能的经验，但也观察到“退化好严重”的现象，并感叹“稍微改几个地方就有很大提升”。最终，通过修改配置关闭 padding（如 tessera-thread-inner-top-padding 等）解决了 TUI 下的显示问题。

专题三：Gnus 与新闻组（Usenet）的新探索

群友 κόσμος 分享了一个新项目：通过 gh（GitHub CLI）和 GraphQL API 为 Gnus 实现了一个 GitHub 后端，可订阅 issues、pulls、discussions 的更新并能直接回复。这引发了关于新闻组（NNTP）的怀旧讨论：

• 群友 κόσμος 通过 eternal-september 服务器访问 comp.emacs 等新闻组，感叹“进入永恒九月了”，并称其为“真暗网”。
• 有人提到中文新闻组 cn.fan 依然活跃，但帖子多为老资历的 Usenet 用户，且历史上存在 GBK 编码乱码问题。
• 有人分享了挖掘到的历史博客文章《Death of Newsgroups》，并惊讶于“一封 email 就是一个带 head 的文本文件”，感叹现代聊天软件给用户留下了错误的印象。

这段讨论体现了开发者对传统分布式通信协议的怀念与对新方案（如 Gnus + GraphQL）的探索热情。

专题四：Emacs 开发与 bug 修复

深夜时段，有群友报告了一个 2016 年引入、直到现在才被发现的 bug，触发条件有三：1. 异步 TLS 连接握手未完成；2. 同时代码在等待另一个进程的输出（accept-process-output 未传 JUST-THIS-ONE）；3. 对方握手数据恰好在此期间到达。该 bug 会卡住 telega （Telegram 客户端），即使消息已发出。群友借此讨论了 macOS 历史上曾内置 Emacs（近年才移除）及苹果用 LLVM 取代 GCC 的背景。

🔑 关键概念与技术解析

• valign：一种 Emacs 表格渲染/对齐工具，用于提升表格显示效果，但在处理大表格（如 500 行）时性能极差（2600ms），不如 org-table-widget（100ms）。
• etaf：一个 Emacs 库，提供了灵活渲染方案（如将文本渲染为 SVG），可用于解决表格边框连续性问题，但在编辑状态（如 undo 绑定）支持上尚不完善。
• accept-process-output：Emacs 中用于等待子进程输出的函数。若不传 JUST-THIS-ONE 参数，可能引发竞态条件，导致异步 TLS 握手阻塞。
• GraphQL API（GitHub）：通过 gh CLI 访问，用于实现 Gnus 后端订阅 GitHub 更新，无需依赖邮件通知。
• NNTP/Usenet：网络新闻传输协议，用于访问新闻组（如 comp.emacs、cn.fan）。群友将其比作“暗网”，需专用 newsreader 客户端访问。
• tessera-thread-inner-top-padding：TUI 模式下 Emacs 表格的 padding 配置项，调整后解决显示问题。

💎 碎片知识与金句拾遗

• “Stallman 开发的工具真好用”——对 GNU 工具链的朴实赞扬。
• “valign 干到 2600ms 了”——对 valign 性能的直观吐槽。
• “我用 svg 弄好了”，随后展示截图并惊呼“Σ(°ロ°)好看”——SVG 渲染方案的成功实践。
• “感觉没什么好办法”——面对复杂问题时的务实态度，随后给出两种具体方案。
• “现代聊天软件给我留下了错误的印象”——对 Usenet 历史文章的感慨，提醒人们理解底层协议的本质。
• “以前 macOS 上还有 X11 呢”——对 macOS 技术变迁的怀旧。
• “这个代码还是 2016 年引入的 bug，10 年了，才发现🤣”——对隐蔽 bug 的无奈与幽默。
• “千帆” ——一个中文新闻组服务器，群友由此解释了 cn.fan 活跃用户多为老资历 Usenet 用户的原因。
• “一封邮件似乎切成多个 section，每个 section 用不同的编码”——对 MIME 多部分邮件结构的亲身观察。

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

• Gnus + GraphQL 后端：κόσμος 开发的 Gnus GitHub 后端（可能开源在 https://github.com/brsvh/emacs-tessera），通过 gh 与 GraphQL 交互，实现对 GitHub 更新的一站式订阅与回复。这是一个极具潜力的方向，有望将 Gnus 引入现代开发工作流。
• etaf 渲染方案在可编辑 buffer 中的应用：群友提到 etaf 可用于渲染表格线，且可能嵌入可编辑 buffer。尽管目前对 undo 绑定支持不完整，但值得关注其未来演进。
• Emacs 表格渲染性能优化：从 valign 的 2600ms 到自定义 patch 后的显著提升，以及 SVG 渲染方案的落地，表明该领域仍有大量优化空间，尤其对大型 org 表格的用户体验提升明显。
• 新闻组（Usenet）复兴可能性：在聊天软件泛滥的今天，新闻组仍被部分开发者视为“暗网”般的存在，但 cn.fan 的活跃度表明其社区价值未消亡。值得探索如何让新一代开发者更容易接入（如现代 Gnus 配置或新客户端）。

观点延伸

今天群里最值得反复思考的不是五十周年，而是两件看起来无关、其实同一个问题的事：表格渲染的 2600ms，和 Gnus 里那几十万条未读。

慢的从来不是算法，是默认路径

同一张 500 行表格，org-table-widget 约 100ms，valign 到 2600ms，差一个数量级。但群里紧接着出现的是“稍微改几个地方就有很大提升”——这说明 2600ms 不是这套方案的复杂度下限，而是默认实现路径带来的额外开销：整表重排、逐行测量、每次滚动都重算。工程上的判断很直接：先怀疑调用路径和缓存粒度，再怀疑算法。一个能被小 patch 砍掉大半的耗时，通常意味着有东西在做本该被缓存的工作。

用 SVG 画表格线，是拿可编辑性做抵押

“根据行高设置表格线高度”确实好看，但它把最终像素从文本层搬到了显示层。麻烦不在渲染，在边界：光标往哪落、复制出去是什么、undo 归谁。etaf 一侧的回答很诚实——“整个就是一个 buffer 的处理，没考虑这么细”。这不是能力问题，是这类方案的结构性欠账：显示态与编辑态一旦分离，成本不会消失，只会推迟到第一次真有人在渲染区里打字时暴露。相比之下“换成等宽字体”最土，却是唯一不新增抽象层的解法——先把约束恢复，再考虑写渲染器。

新闻组没有复活，复活的是“可编程的收件箱”

有人把 GitHub 塞进 Gnus，立刻被问“怎么不如构造 nnrss”。质疑是对的：拉取 issues 只是又一个 feed，RSS 早能表达。真正卡人的是后半句——换台机器打开就是几十万未读。协议负责提供数据，产品负责维护状态；Usenet 的“暗网感”不在于 NNTP 多神秘，而在于它从来没有一层替你把服务器、身份、已读同步做完。同一段讨论里“一封邮件就是一个带 head 的文本文件”的惊讶也是同一个根源：协议能被看见，人才可能接手。所以这波 Gnus 后端的价值不在读，而在于证明接口可编程，老客户端就能长出新入口——代价是你得自己维护两套并不共享的状态模型。

可继续做的一件事

拿一张真实的 500 行表，把首次渲染、单行滚动、编辑一个单元格三种操作的耗时分开测，看 valign 的 2600ms 里各占多少。如果“编辑一格”的代价远高于“滚动”，那 SVG 方案省下的就不是性能，只是视觉。这个结论比任何一条配置项都更值得写进文档。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题一】Neomacs：用 Rust 重写 Emacs 的"地狱开局"与社区传播困境

本次聊天围绕 eval-exec（群内称"neo"）主导的 Neomacs 项目展开，一个旨在用 Rust 重新实现 GNU Emacs 的激进实验。讨论集中在两个核心矛盾：

1. 技术打磨与用户预期管理的拉锯

• 用户发现 Neomacs 在 (undecorated . t) 配置下会绘制一个自定义标题栏（高约 30 像素），且与 neo-tab-mode 冲突。AI 被用来生成最小复现脚本（RUST_LOG 控制日志输出），提 issue 甚至 PR。
• 开发者在权衡：太早公开宣传，会被 r/emacs 老用户骂到封号（他本人已被 Reddit 封禁）；但不公开又难以找到测试者。大家认为"开源项目应该自己用几个月稳定了再公开"，只有 web slop 才拿 demo 宣传。
• 最终共识：先猥琐发育，等稳定可用再一鸣惊人，甚至建议去 r/neovim 而非 r/emacs 宣传。也提到"绝大部分代码是验证 100% 兼容 gnu/emacs 的测试代码"。

2. AI 在开源项目全流程中的"幽灵化"

• 从写代码、提 issue、回 PR、发邮件到 Reddit 宣传文案（用 AI 润色英语），全部由 AI 代劳。
• 有成员感叹"AI 真他妈无敌，自己一行不看，还能刷 github 贡献值"，也有人提到"vibe open source 大势所趋"，但维护压力随之增大。
• 同时引出"AI 羞耻感"讨论：有人认为仔细看 AI 代码经常能发现问题，文档同理；也有人自我洗脑"ai写的就是我写的"。
• 延伸至 LibreOffice 新闻：TDF 要求贡献者披露 LLM 使用，但代码中仍发现三处明确提及 Claude/Copilot——"大型开源项目基本上不太可能完全避开 LLM"。

3. 技术债务与 Rust 重构的代价

• Neomacs 起初内核是 C，只重写前端；后来用 Rust 重构 elisp VM，"非常麻烦"，导致开发者忙到不冒泡。
• 对 Wayland 的支持（DataGrip 在 Wayland 下体验差）是部分人转向自己写工具（如 keydock）的动机。
• 有人表示"无论多么复杂的问题，我相信我都能解决"，但"就看付出什么代价"。

---

【专题二】Wayland vs X11：一瘸一拐的"半成品"与被卸载的 XWayland

群内多次围绕 Wayland 展开辩论，尤其是与 Steam、游戏和远程方案的兼容性问题：

• 痛点：Steam 仍依赖 X11/XWayland 与一堆 lib32 包，有人装了 89 个包后放弃，直接卸载 XWayland，"所有 x11 的滚出"。
• 批评："红帽在强推一个半成品给社区用，甚至半成品都算不上"，交互（UX）糟糕，systemctl/journalctl 等命令太多记不住。
• 辩护：Wayland 严格隔离导致跨窗口交互被禁止，但这是安全设计；river 博客文章解释了 compositor 的职权——"Combine all buffers from visible windows into a single buffer to be displayed by the kernel"。
• 现状：niri 在笔记本上体验好，但 workspace 切换动画与鼠标操作被认为不如 i3；GNOME 的标题栏 hover 效果甚至被拿来反衬 Winit 绘制的 Neomacs 标题栏。
• 金句："Wayland 像个瘸腿的"，"systemd 更像那个半成品（但调度和管理没问题）"。

---

【专题三】AI 编程范式：Agent、Subagent 与"返工率"的博弈

• 讨论 Claude/Codex 的 subagent 是否用低级模型：主 agent 复核是否需要额外 token？高级模型指挥低级模型返工很多，但 Claude/Codex 内部返工很少。
• Codex 支持 Kitty Graphic Protocol，能在终端显示宠物/侧边栏，但被吐槽"设计用于常驻就有点可怕了"。
• 有人提到自己的 Codex 比别人的聪明，也有人气得想哭。
• 对 Gemini 的评价："gemini是最不像屁眼的"（上下文不明，但可能是对额度策略的吐槽）。
• 关于 CUA（Computer Use Agent）：glm 删掉才放代码，Codex 也不开源 CUA。推荐 codeburg——一个同时反 LLM 和反 Crypto 的工具，但"对面就这么对线，只能上检测手段，又容易误杀"。

---

【专题四】在 Emacs 里做微信/QQ 逆向：从 ntqq-rs 到 wechat-rs

• 有人从魔改 napcat 开始，后来用 Rust 重写为 ntqq-rs（Emacs-qq 后端），现在开始搞 wechat-rs。
• 核心担忧是腾讯封号（"封了可能就是永久"），所以必须充分逆向、拿小号测试；有人倾向"截图 OCR + 自动输入流"，更安全且应用面广。
• emacs-qq 的前端仓库是公开的，后端是私有 repo（"要不鹅子看到太危险了"），可以邀请可信成员加入组织。
• 有人已在 Emacs 里用 QQ 稳定不风控，还传教室友成功。

---

🔑 关键概念与技术解析

• Neomacs：用 Rust 从零实现 GNU Emacs 的项目（eval-exec/neomacs）。目标是 100% 兼容 elisp 与 GNU Emacs 生态，目前仍是 WIP，且大部分代码是兼容性测试。
• neo-tab-mode：Neomacs 作者自己开发的模式，用于替代 menu-bar 和 tool-bar，目标是实现 JetBrains 风格的折叠式菜单，目前尚不完整（M-x 找不到该函数）。
• undecorated：Emacs/Neomacs 配置中的一个标志，设为 t 时隐藏系统标题栏，但这会让 Neomacs 绘制一个默认高约 30 像素的自定义标题栏，可能造成遮挡 bug。
• Winit：Rust 的跨平台窗口创建库。Neomacs 使用它，因此标题栏行为可能与 GNOME 原生窗口不同（如 hover 高亮）。
• RUST_LOG：Rust 应用（如 Neomacs）的日志过滤环境变量，可设为 TRACE/DEBUG/INFO 等，用于调试。
• Compositor（合成器）：Wayland 下，负责将所有可见窗口的 buffer 合成为一块最终由内核显示的 buffer。在 X11 下需要独立的混成器实现特效，Wayland 自带。
• CUA（Computer Use Agent）：AI 直接操作电脑界面的代理技术。群内讨论其对开源态度（glm 删过代码、Codex 不开源）。
• Kitty Graphic Protocol：让终端能显示图像的协议，Codex 支持它，可在终端渲染宠物等图形。
• ntqq-rs / wechat-rs：Rust 实现的 QQ/微信协议后端，作为 Emacs 聊天插件（emacs-qq）的服务器端。
• Waterfox/输入法模型（推测）：群内提到"优化输入法模型"、整句准确率 90%、9B 方案需 19G 显存、8.5G 显存自用方案、2B→0.8B 会降两个点，说明在跑本地小模型做输入法预测。

---

💎 碎片知识与金句拾遗

• "开源不都这样。"（面对 bug 的无奈）
• "感觉别的事情，无论是啥，都没有用 AI 搞 Rust 开心。"（极客的快乐源泉）
• "我对语言没啥忠诚，什么牛逼用什么。"——转而又说"现在写 C# 也很爽，反正不是我写，哈哈哈"。
• "用 AI 提 issue 太方便了！"——AI 自动生成最小复现脚本（./neomacs -Q -l reproduce_bug.el）。
• "就是方便呀！……交代完了，出去遛狗了。不知道能不能修好。"（开发者日常）
• "AI 真他妈无敌，自己一行不看，还能刷 github 贡献值。"
• "我感觉我的 codex 比别人的聪明。"（经典 AI 玄学）
• "我只等 3 天后的 astra 发布。"（AI 模型圈子的追逐）
• "就算发 6.1 额度已经削得不想用了不是吗？"——"我的观点不会因为某段时间厂商模型能力变强或者给出优惠变化。我宁愿给其他家多送点数据。"（模型忠诚度）
• "兄弟们，沉星之序太好玩了，巨上头。"（游戏推荐，后续讨论它是"究极推箱子"、Jai 写的、Windows only、但 Proton 可跑）
• "我买了一条 48GB 八百多块，当时应该直接 64×4。"——"只要有一家大模型公司破产，内存价格马上降。AI 已经呈现泡沫特征了。"（硬核玩家内存囤货论）
• "为了查 3 毛钱，还要不影响下班，那才叫压力。"（运维老兵回忆）
• "现在谁都可以 vibe。我只关心自己用了。"（开源心态转变）
• "快乐也不快乐。不快乐是因为有傻逼，快乐是因为自己想要就能得到。"（开源维护者的心理写照）
• "我现在用 emacs 打字都费劲😭"（新手在群里哀嚎）
• "感觉我还是有一点 ai 羞耻感，vibe 有种怪不好意思的感觉。"——"加一。因为自己仔细看代码经常就能看出问题，别人仔细看看应该也能看出来。文档也是同理。"（AI 代写的心理障碍）
• "给自己洗洗脑，ai写的就是我写的。"（自我安慰法）
• "这也能直接对？"（看到输入法整句准确率演示时的惊叹）
• "主要是需要一些足够刁钻并且对于人类来说也能判断出来的句子。"（评测输入法模型的难点）
• "Reddit 对带链接的 post 管理十分严格：1. 已发过的 post 不要随意动链接；2. 同一时间段发同一链接的多篇 post 会触碰限制。"（被封号后的经验之谈）
• "第一印象不好的话，后面很难板正，可能用户就不会再试了。"（开源项目发布策略）
• "Google 要求 12 个人连续测试两周才能上架，安卓凑不到测试人数，iOS 一百多人，安卓才 3 个人。"（社区冷启动难题）
• "用 AI 做很快乐，手写感觉这辈子完不成个有用的项目。"（AI 时代开发者的普遍心态）
• 羊肉串与"纸上印刷油墨铅毒"的微博段子：讽刺消费者对无关细节的过度担忧，群内反应："谜底在最后一句，上微博是什么感觉？——都一样，千夫所指。"
• 俄罗斯时差与喀山历史：zevlg 在伏尔加河河畔的喀山（离莫斯科时区快 1 小时），"长得几分亚裔"的原因可追溯至金帐汗国历史，当地还出生过列宁、克伦斯基与泛突厥主义理论家优素福·阿克楚拉。
• "20x 的 50% 周限"——登录某模型服务时消耗的配额量（推测为 Claude Opus 的每周限额消耗 50%）。
• CopyQ 用户在升级 GNOME 51 前应读 issue #3768。
• 飞书/AI 机器人选型：推荐给每个同事一个 Bot，群聊与个人助手分割；记忆系统与长任务 loop 编排器是关键；有人提到"豆包也是字节家的，飞书自带 CLI 比较稳妥，但 skill 要自己精简"。
• 音乐播放器推荐：sonora（"不推荐的话心里过不去"）。
• 一个朋友纯 vibe coding（不懂 elixir）用 DeepSeek 花约 240 块做出了"一个微信功能基本都有了"（群聊、视频、语音、私聊）的应用。

---

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

• Neomacs 的 CI 硬件方案：作者想用闲置的 48×2+32×2 笔记本内存 + 2TB 机械盘 + 移动 SSD，买板 U 小主机（如铭钒、7545HX）组一台跑 CI 的机器。这也引发了内存价格与"AI 泡沫破裂"的讨论。
• keydock（LuciusChen/keydock）：Linux 上模仿 Hammerspoon 的窗口管理工具，配合 AI 自动扒系统 API 的写法值得关注。
• herdr-app（herdrdev/herdr-app）：新出的开源 app，X 上吐槽多，但值得观察后续迭代。
• ffmpeg-skill（kajisho5/ffmpeg-skill）：被群友评为"好东西"。
• dimble（fif7y/dimble）：群友称赞"渲染好看"，与审美相关，可能是新的 UI 渲染库。
• owly（t4t5/owly）：被批评"根本不行，连设备都不能被苹果设备发现"。
• thinkrail / thinkxxx：基于 pi 的新工具，被点名"想玩玩"。
• CopyQ + GNOME 51：剪贴板工具与 GNOME 升级的兼容性问题，值得跟进 issue #3768。
• 本地输入法模型优化：群友自研方案（8.5G 显存，整句准确率 90%），并尝试从 2B 降到 0.8B（会降两个点），评测集需要"足够刁钻且人类也能判断的句子"。这是边缘案例挖掘的好方向。

观点延伸

中心判断：今天真正有张力的地方，是 AI 已经把开源协作的整条流程都接管了，唯独“信任”这一环没有被自动化，而非“Rust 能不能重写 Emacs”。那个 30 像素自定义标题栏的 bug，从定位到最小复现、提 issue、合并，全程由 AI 跑完；这段流程里唯一没有被加速的，是“别人凭什么相信这个项目能长期活下去”。

一、发布节奏表面上关乎礼貌，实际上是信号成本问题。

“只有 web slop 才有个 demo 就宣传”“第一印象不好的话，后面很难板正”——这不是老派洁癖，而是在陈述一个信息经济学事实：作者自己先用几个月，是外界唯一一个低成本就能读到的“质量担保”信号。AI 可以代写 issue、PR、英文润色和宣传文案，唯独代劳不了“我拿它当了三个月主力编辑器”这件事。账号被封、改链接触发限制，本质上是同一套机制的暴力版本：社区在用摩擦成本给信号定价。所以“猥琐发育”真正的含义是把有限的信任额度留到能兑现的时候再花，而不是单纯胆小。

二、subagent 返工率的差别，根子在验收器，而不在模型层级。

群里的观察很尖锐：高级模型指挥低级模型，返工很多；Claude/Codex 内部调度，返工很少。直觉解释是“人家内部模型更强”，更可能的解释是：厂商内部给 subagent 的是一份可执行的验收标准，包括测试、类型、lint 和 diff 边界，而我们在外面给的常常只是一句自然语言目标。返工本质上是“错了能不能被机器立刻发现”的问题，跟理解力无关。这条判断可以被证伪：同一批任务，给验收命令和不给，返工次数可能差一个量级。

三、AI 羞耻感，本质是可审查性焦虑。

“自己仔细看代码经常就能看出问题，别人仔细看看应该也能看出来”——这句把羞耻感说透了。它跟道德无关，跟担保人缺位有关：代码署你的名，质量却没人真正背书。TDF 要求披露 LLM 使用，解决的是署名与责任归属，并不解决质量——披露不等于审查。判断标准很简单：你交付的东西有没有一条别人能一键复跑的验证路径。

可继续实践：给自己的 AI 协作做一周小实验，每次委派记三件事——目标描述、验收命令、返工轮次。对比“只有自然语言目标”和“附带可执行验收”两组数据。如果返工率真的差一个量级，那么“怎么把目标翻译成验收”就该被当成比 prompt 技巧更基础的能力来练。