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

Emacs 中文讨论组

🎯 核心热点与专题探讨

1. illumos 桌面体验：生态成熟度之痛

群友询问 illumos 发行版（如 Tribblix）的桌面体验，但讨论迅速转向现实困境。有人提到十年前用过 SmartOS（仅服务器场景），或看过 Solaris 虚拟机折腾，但桌面驱动支持几乎全军覆没。核心观点是：除了 Linux，其他 Unix 系系统在桌面硬件兼容性上均无法跟上，FreeBSD 虽尝试兼容 Linux 驱动，但效果仍有限。这反映出 illumos 这类 Solaris 后代系统更偏向服务器/云场景，桌面生态仍是硬伤。

2. org-mode 的 nvim 移植：丐版与完整性的博弈

围绕 org.nvim 项目，群友展开辩论。核心矛盾是：org-mode 的“事实标准”是 emacs 实现，除非 nvim 能直接运行 elisp，否则任何移植都只能是“丐版”。但另一方认为，nvim 支持 org 能扩大用户群，反哺生态。随后有人抛出 nelisp 项目（存在两个同名仓库），试图将 emacs 核心移植到 nvim，但多数人认为意义有限。还有群友用 AI 辅助快速生成了 tree-sitter org parser，展示低成本原型验证的可行性。

3. Emacs 新渲染特性落地

群友分享了一条 emacs 上游 commit：为 underline/overline/strike-through face 提供统一支持（涉及 pgtk/x11/windows 后端）。合并后，GUI 用户拉取 master 即可体验。这是 emacs 文本渲染能力的增强，对非 Linux 终端用户尤其友好。

🔑 关键概念与技术解析

• illumos：基于 Solaris 内核的 Unix 系统家族，衍生出 Tribblix、SmartOS 等发行版，常用于云基础设施，但桌面生态薄弱。
• org-mode：emacs 中的层级笔记/任务组织模式，具有“单一事实标准”的配置和文件格式，移植到其他编辑器通常只能部分兼容。
• nelisp：两个同名项目（altermo/nelisp 与 zawatton/nelisp），目标是把 emacs 核心（或 elisp 运行时）嵌入 neovim，以实现原生 org 支持。但主流观点认为技术复杂度高且意义有限。
• pgtk/x11/windows：emacs 的三种图形界面后端，分别对应 GTK、X11 和原生 Windows，新 face 特性已统一支持。
• fcitx5-remote -c：输入法切换命令，实际生效条件苛刻：需要配置两个输入法，且第一个必须是英文，否则无法自动切到英文模式。可用 busctl 直接调用 Rime 的 SetAsciiMode 绕开限制。

💎 碎片知识与金句拾遗

• “unix 就犯了一次大错, 也就几年, 结果一直没有人用了. 除了apple.” —— 对 Unix 历史错失的惋惜。
• “linux 几乎不犯错”、“Windows 天天犯错” —— 群内对系统稳定性的调侃，虽有夸张，但反映开发者偏好。
• “移植真的是，非常有前途，而且比较简单。” —— 对将成熟软件移植到新环境的乐观态度。
• “我vibe一个tree sitter org parser只花了一点点token” —— AI 辅助开发极大降低了原型成本。
• 具体配置提示：Linux TUI 中 Ctrl+Backspace 无响应，建议绑定 M-DEL；Ctrl+2 在终端中会被映射为 C-@，属于终端转义问题。
• 工具推荐：kkp 是一个按键映射工具，通过 SSH 也能正常使用，解决远程终端键位问题。
• 新特性线索：emacs 的 underline/overline/strike-through face 已合并，GUI 用户可体验（链接见聊天记录）。

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

• nelisp 项目（https://github.com/altermo/nelisp 与 https://github.com/zawatton/nelisp）：将 emacs 运行时移植到 neovim 的尝试，尽管争议大，但技术方案可能催生新的编辑器生态。
• emacs 新 face 支持：上游 commit 4b76d570d0249d0bd422462361dd627555281ffe 实现了跨后端渲染一致性，对 GUI 用户是重要改进。
• fcitx5 的 busctl 切换方案：busctl call --user org.fcitx.Fcitx5 /rime org.fcitx.Fcitx.Rime1 SetAsciiMode b 1 可作为脚本化的输入法控制手段，值得深入实践。
• tree-sitter org parser：群友用 AI 快速生成 parser，表明树状语法解析在 org 生态中的潜力，可作为轻量级 org 解析器研究方向。

观点延伸

当天几组讨论其实指向同一个判断：软件的“可移植性”往往只解决了表面接口，真正难移植的是长期积累下来的生态契约。illumos 的桌面困境、org-mode 在 nvim 中的争论、TUI 按键与输入法问题，看似分属操作系统、编辑器和桌面配置，底层却都在问：一个系统到底把哪些行为当成了稳定承诺？

1. org.nvim 的关键问题不是“能不能解析”，而是“兼容到哪里为止”

tree-sitter parser 可以很快做出，标题、列表、代码块等语法也能较容易展示出来；但 org-mode 的价值并不只在语法高亮，而在编辑命令、属性、链接、执行语义、稀有语法和用户配置共同形成的行为体系。因而“丐版”不是贬义，而是一个工程事实：移植项目必须明确兼容边界。

更可靠的路线不是宣称“支持 Org”，而是列出可验证的兼容矩阵：解析覆盖哪些语法，修改后能否保持结构，导出结果是否一致，链接和任务状态如何处理，哪些行为明确不支持。这样，nvim 支持 Org 才可能成为生态扩展，而不是制造一个名称相同、语义逐渐分叉的新格式。

2. AI 降低的是原型成本，不是维护成本

“用一点点 token 做出 tree-sitter org parser”很有启发性：过去需要先投入大量基础设施的想法，现在可以快速得到可运行样品。但原型越容易生成，越需要测试来定义它是否真的有用。对解析器而言，工程门槛至少包括真实文档样本、错误恢复、增量编辑、格式保持和回归测试；对编辑器功能而言，还要验证不同终端、GUI 后端、输入法和远程连接下的实际行为。

因此，AI 最适合把“要不要做”提前变成可运行证据，而不应直接替代兼容性设计。一个 parser 是否值得继续，不看它能否解析示例，而看它能否在一组公开、可重复的文档和编辑操作上稳定通过。

3. “统一支持”必须同时覆盖语义层和边界层

Emacs 新增的 underline、overline、strike-through face 跨 pgtk、X11、Windows 合并，说明功能真正完成的标准不是某个后端能显示，而是多个后端的行为被纳入同一抽象。相反，TUI 的 Ctrl+Backspace、Ctrl+2、repeat-mode 和 fcitx5 切换问题，则暴露了终端与输入法之间的边界契约并不统一。

可继续研究的方向是：为 Org 移植建立一套小型“兼容性实验室”，用固定文档、编辑动作和导出结果比较 Emacs、nvim 实现及 parser；同时把 TUI 按键和输入法控制纳入同样的黑盒测试。真正成熟的移植，不是看起来像原版，而是在边界条件下仍然可预测。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题】Claude 订阅生态：从“用不起”到“用不上”

本次讨论最激烈的主题围绕 Claude 订阅展开，几乎贯穿全天。核心痛点集中在封号、KYC（实名认证）和价格体系三方面：

• 封号危机：一位用户国庆第一天醒来即收到“account has been suspended”，三个老号全部沦陷，此前 20x 额度“一去不复返”。新注册账号全被要求 KYC，即使能付款也随时可能被封。有用户尝试退款，但“卡着扣款日封的”就没退成。
• 区域限制与对策：讨论出多条“求生路径”——iOS 美区渠道相对最稳，注册登录时需用高质量美国 IP；支持银联支付，但支付之前必须过 KYC；有用户为搞新号特地买新域名做 email routing，结果卡在 KYC 环节。有人提到 AMP 等套餐有 Opus 用量，比中转“没那么冤大头”。
• 价格敏感度：有用户算了一笔账——“考虑到封号概率，是不是相当于 $40 一个月”。也有人指出“便宜是靠封号不退钱来补贴的”。中转渠道被形容为“随便搞搞就 1k 没了”，且夜间不稳定。
• 模型能力对比：Claude Opus 5.5 获得高度认可，“太屌了”“除了贵之外没其他问题”。有用户用它 23 小时烧了 $100，彻底重构了整个架构，交互性能“单步更新达到微妙级”。OpenAI 则被多次吐槽——“算力和数学对线有啥好处，还不如留给用户”，“GPT 那个💩样子能用？”。

【专题】创作软件套件：Adobe 的“死缓”与替代品现状

凌晨的讨论围绕创作软件替代方案展开，白天又呼应了“Adobe 还没死吗”的吐槽：

• Photoshop：已有人全面转向 Affinity，免费，但没有 Linux 版是痛点。
• Lightroom：照片管理 + 轻 Raw 处理。有人提到理论上 Apple Photos 能做，但“相机 raw 会跟手机拍的 jpg 混在一起”“整天 xjb 改 feature 的态度信不过”。推荐了 LAP（照片管理工具）和 Rawtherapee（Raw 处理）。
• AE：被认为目前没有靠谱替代——“AE 是动画类的合成软件，更风格化和 2d 化，也能做 mg 动画”。

【专题】Emacs 定制与性能：从滚动修补到 10ms 交互

Emacs 相关讨论分散但持续，呈现“硬核玩家”的日常：

• 滚动问题：横向滚动在显示行号时有锯齿/光标错位问题，有用户“让 AI 裁切”后光标会跑到行号内、实际位置在屏幕之外。有人提到“如果同一页有短行和超长行，光标在短行上，长行就滚不过去了”——这是一个“很难权衡”的取舍。
• 透明与模糊：换到 emacs-plus patch 后支持透明和模糊，“透明和模糊很重要”，但有人表示“透明也就刚开始有点意思，后面都关了”“显得很廉价”。当前配置是“模糊 20，透明 70”。
• 性能重构：使用 Claude Opus 5.5 彻底重构后，“交互接近直接操作 emacs buffer 的性能”，所有常规复杂交互在 10ms 以内——这被认为是“etaf 的性能问题得到了彻底的解决”。

【专题】Rust 开发者的存储困境

一个看似闲聊却引发共鸣的话题：Rust 项目的中间构建产物体积惊人。

• “neomacs 占用了 72G，磁盘只剩 51G”
• “Rust contributor 都是几个 T 的 SSD 吗”——有人晒出“两个 4TB NVMe SSD + 128GB 内存”的配置，被调侃“任性开发，激情开发，放肆开发”
• 提到“Rust 的大项目甚至调试不了，二进制产物太大超 4GB 了”
• 留的空间太小会导致“写放大”

【其他热点】

• 尊界 V800 刹车踏板支架连断三根：懂车帝实测 3 台全部被踩断，同为华为系的智界 V9 无恙。群友评价：“油门踩断我知道是安全设计，刹车踩断也太幽默了吧”。
• 芯片封装技术疑问：有人追问华为逻辑折叠芯片为什么必须从底部穿孔副 die 供电，而非从侧面绕过去——无明确解答，但问题本身很有深度。
• SQL 焦虑：“上班了不会都要面对几百行的 SQL 吧”——收到建议“天天写就好了”，以及 duckdb/polars 的对比。

🔑 关键概念与技术解析

• KYC（Know Your Customer）：Claude 新注册账号要求的实名认证流程。对国内用户而言，即使能付款，KYC 仍是最大的拦路虎。群内讨论确认“中国护照做 KYC 可以（X 上说的）”，但支付问题不是问题，“支付之前要 KYC”才是问题。
• AMP 套餐：第三方 Claude 订阅服务商，提供 Opus 模型用量，被群友认为是比中转“没那么冤大头”的替代方案。
• etaf / ebox：群内成员自研的 Emacs 相关项目，本次经 Claude Opus 5.5 重构后性能达到“单步更新微妙级、常规交互 10ms 以内”。
• LAP：一个照片管理工具（julyx10.github.io/lap/），被推荐为“很牛逼”的照片管理方案。
• Rawtherapee：开源 Raw 格式图片处理软件，被推荐作为 Lightroom 的替代。
• emacs-reader：基于 Emacs 的 PDF 阅读器，性能优于 pdf-tools，但“连文本搜索都不支持”，群友通过 patch 增加了高亮、滚动手感、索引缓存等改进。
• sioyek：文献阅读器，支持“super fast search”——先建索引，再用索引毫秒级搜全本，群友正在为其编写 patch。
• Code Agent 工作流：群友分享的使用模式——传统交互式聊天规划后一次性执行，以及“做 MVP、阶段性验收”的渐进式方法。核心观点：“只有 Claude 能够驾驭超长的任务”。

💎 碎片知识与金句拾遗

• “牛马不会发言，比如我”——“牛马才会发言，解决了温饱问题的话谁家好人会上来看群学技术呢”
• “自从 claude codex 火了之后，我对游戏就失去兴趣了”
• “GPT 烂到假期不想用它来写东西”“只有 astra 智商在线”——随后“先取消订阅了，先订阅 claude 一段时间”
• “我让 ds 做数学题，做一会儿说不好意思我刚刚的思路是错了，然后又用一个错的思路”——对 DeepSeek 数学能力的吐槽
• “我其实第一时间把 fable 烧光，然后再用 opus”——Claude 用量策略分享
• “百度到底给他什么创伤”——对某 AI 封号策略的调侃
• 关于 Clude 封号风险：看到“别人在和 claude 聊自杀相关的话题，因为 claude 怕承担法律责任，所以不能直接封禁”——美国法律不允许，但国内会提供相关组织电话
• “透明不好，显得很廉价”——对 Emacs 透明效果的审美判断
• “假期过去了，claude 额度，我还没用完，只用了 82%”——凡尔赛式额度管理
• “随便啥操作都要一秒多，得开始优化了”——对 jjosh 性能问题的观察
• 关于存储：硬盘“长期只剩 10%”会引发“写放大”问题——技术细节值得关注
• “我的 vpn 是小水管”——共享 300M 视频文件时的无奈
• “音乐 100 首，边听音乐边写博客”——开发者的日常配乐需求
• “换到 emacs-plus 的 patch 了，他带有透明和模糊”——版本迁移的实用提示
• 关于 Emacs 波浪线：“org-remark 可能用到”“这个重要”——“因为 Windows 估计是有 dpi 问题吧，绘制出来的波浪线几乎看不到”
• “用 jev 来裁剪上下文”——上下文管理工具推荐
• “我还是不习惯在 emacs 里读 pdf”——对 PDF 阅读场景的保留意见
• “我加了好几个 patch：高亮变成预览.app 样式、滚动手感变成 mac、统一弹窗滚动模式、保存本地索引 cache、加速建索引”——AI 辅助开发的高效实践
• “ai 真好用”——多次出现，是本次讨论最真实的注脚

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

1. Claude Opus 5.5 驱动的架构重构范式：23 小时烧 $100 完成整个架构重构的实践路径，值得关注其“交互接近直接操作 emacs buffer 的性能”的技术实现。
2. emacs-reader fork（codeberg.org/0WD0/emacs-reader/）：已加入多个 patch（高亮样式、滚动手感、索引 cache、建索引加速），虽“不支持文本搜索”，但“性能强很多”，适合作为 PDF 阅读器的候选方案。
3. sioyek 的 super fast search：基于索引的毫秒级全文搜索，群友正在为其编写 macOS patch，值得跟进其“portal 和引用 popup”功能。
4. Rust 中间产物优化：neomacs 占 72G、二进制超 4G、调试困难的现实问题，群友提出“target 中间产物压缩”思路——这对大型 Rust 项目有普适参考价值。
5. 华为逻辑折叠芯片供电问题：打孔供电牺牲副 die 8% 面积、打 8 万多个孔，为什么不能边缘接电——问题本身极具前沿性，值得追踪技术解析。

观点延伸

当天最值得咀嚼的，不是“Claude 比 GPT 强多少”，而是一个更现实的判断：强模型正在把软件工程的瓶颈从“能不能写出来”推向“能不能放心交给它持续改下去”。群里一边有人用 Opus 5.5 花 23 小时重构 ebox、etaf，把复杂交互压到 10ms 以内；另一边又有人明确说，复杂任务仍然只敢做 MVP、分阶段验收，只有 Claude 似乎能驾驭超长任务。两者并不矛盾，反而说明了 Agent 工程的分界线已经出现。

1. 长任务能力的核心不是输出长度，而是保持系统约束

一次性完成大规模重构，真正难的不是生成很多代码，而是在数十个局部决策中持续保持架构目标：数据流不能被破坏，交互延迟不能反弹，声明式接口不能为了性能被全部牺牲。群里提到“接近直接操作 Emacs buffer 的性能，同时保留上层好用的声明式写法”，这比单纯的 benchmark 数字更有价值，因为它同时包含了性能目标和设计约束。

因此，评价 Code Agent 不应只看它能否“做完任务”，还要看它能否主动建立验证边界：哪些指标必须测，哪些行为不能变，哪些模块应先迁移再清理。没有这些边界，所谓长任务很可能只是一次大规模、难以回滚的代码生成。

2. 个人知识系统最容易输在“可引用性”，而不是存储能力

“把多个 Emacs app 统合成类似 CRM”的想法，以及跨平台聊天记录难以互相 quote 的问题，指向同一个底层矛盾：信息收集并不难，难的是在新的上下文里准确引用原始事实。邮件、聊天、PDF、笔记如果只有全文搜索，没有稳定的来源、时间、对话关系和局部引用，最后得到的只是一个更大的信息堆。

这也解释了为什么 sioyek 的索引搜索、emacs-reader 的本地 cache、PDF 高亮和 popup 等细节值得重视。个人知识系统的关键能力不是“把所有东西放进 Emacs”，而是让未来的自己能用极低成本回到证据现场。性能优化服务于这个目标，而不是单纯追求更快的界面。

可继续研究/实践

可以为一次真实的 Agent 重构建立最小验收协议：记录关键交互的基线延迟、内存和行为样例，要求 Agent 每完成一个阶段就运行同一组回归测试，并保留可引用的变更说明。与此同时，为聊天和 PDF 数据设计统一的引用对象：来源、时间、原文片段、上下文关系和稳定标识。前者验证 Agent 是否真的能承担复杂任务，后者验证知识系统是否真的能帮助下一次判断。