Geekinney

外观

Emacs 社区日报 2026-08-19

约 6272 字大约 21 分钟

2026-08-19

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

Emacs 中文讨论组

🎯 核心热点与专题探讨

【专题】Org-mode 与中文排版的 parser 困境

今日讨论中最具技术深度的话题，围绕 Org-mode 对中文标点与行内标记（=code=、*bold*、/italic/）的解析缺陷展开。

问题现象：

  • 当代码标记内容包含 / 且紧邻中文时，如 =armQuery/executeQuery=。模板/阿巴阿巴。 会被 parser 错误解析，= 与 / 发生交错识别，渲染异常
  • 中英混排时 org parser 未尊重中文标点边界（如「。」），导致标记语法误判
  • Markdown-ts-mode 表格对齐在中英混排场景中将中文按单宽度处理，对齐错乱

根本原因分析：

  • Org-mode 的正则表达式 parser 未将中文标点视为词边界（word boundary），这是 CJK 处理的老问题
  • Markdown 生态的 CommonMark 规范允许 a*b*c 形式（取决于实现支持分歧），而 org 的 parser 行为更保守，本质上是 spec 模糊 + 实现保守的双重产物
  • Emacs 核心维护者中缺乏中文母语者，CJK 相关问题长期积压

解决方案探讨（均有争议）：

  • 零宽空格（ZWS）方案：官方推荐的 escape 方式，但群友普遍反感——不可见、难排查、需配套显示/导出过滤逻辑。有人直言「到处插 zws 是人想出来的解决方案吗」
  • word-category 改断行：类似换行逻辑，利用 Unicode 字符类别识别中文标点边界
  • 引入左右强调标记：类似 Markdown 的 <strong> 显式标记
  • 定制化 parser / org treesitter：有人理想化地提出，但被指出「org 本来就没有 spec」，实现难度极高

核心金句：

「纯粹的维护者偷懒或者说没有需求」 「有没有可能主要是 org-mode 的问题」 「我们需要 org treesitter……正则表达式当 parse 爬一爬啊」

结论倾向： 多数人认为这是 parser 设计缺陷而非用户用法问题，但修复牵扯 spec 修订、兼容性、中文词边界定义等多层复杂度，短期内无明确方向。有人发起倡议参与 org-mode 上游讨论并写 patch，但因工作压力（995）难以付诸行动。

【专题】Emacs 架构：屎山 or 智慧结晶？

围绕 Emacs 代码质量的评价出现两种对立观点。

正方（捍卫者）：

  • Emacs 是兼容平台最多的编辑器，为覆盖海量平台必然引入复杂度
  • C source code 代码质量本身不错，所谓「屎山」是 GPL 格式化风格难看 + 单文件破万行 + 高耦合共同造成的观感问题
  • 属于「数代工程师的智慧结晶」

反方（批评者）：

  • Lisp 与 C 深度耦合，渲染、通信、计算都要访问或调用 Lisp 对象，缺乏隔离层
  • 全局状态多，维护海量 Lisp flag
  • 纯 C 写接口直接使用 OS 原生 API，不搞跨平台统一抽象
  • 戏称「有 vim 间谍混进核心开发者队伍，故意制造高耦合」

有趣断言：

「Emacs 代码很抗 AI，因为 AI 绝对改不动」

其他小话题

Windows 平台 Tramp 兼容性： 群友反馈 Windows 下 Emacs 的 tramp 无法使用自带 ssh/sshx 连接远程服务器，仅 plink（Putty 提供）可用。已在 emacs -Q 下复现，尚未提交 bug。正值 Emacs 30.2 在 UOS20「旧世界」龙芯架构上编译成功的消息被分享，凸显 Emacs 跨平台能力与短板并存。

Harper 语法检查工具： Pillip 正在将 Harper（writewithharper.com）的 Emacs 集成包 flymake-harper.el 推往 ELPA。Harper 做语境级语法检查（大小写误用等），超越 enchant 的单词级检查。群友实测 Chrome 扩展后认为建议质量不稳定，单字建议常错，但速度确实快。另有 harper-ls 可作 LSP 后端配合 Eglot 使用。

🔑 关键概念与技术解析

  • rc 版本：Release Candidate，发布候选版本
  • ZWS (Zero Width Space)：零宽空格，Unicode U+200B，肉眼不可见。Org-mode 官方用它来断词阻止标记解析，但编辑体验争议极大
  • CommonMark：Markdown 的标准化规范，tree-sitter-markdown 主要基于它。对 a*b*c 这类无空格强调标记有明确定义，而 GFM 等早期实现存在分歧
  • tree-sitter：增量解析框架（此处代指新版 Emacs 的 ts-mode 系列主模式，如 markdown-ts-mode），相比正则 parser 能更准确处理嵌套结构
  • Gnus：Emacs 内置的邮件/新闻组客户端，用于阅读 GNU 邮件列表（ML）
  • AGENTS.md：记录 AI 辅助规则的仓库文件。Emacs 项目的规则是：禁止 AI 生成代码、禁止用 AI 写 bug 报告
  • FSF 版权协议：向 GNU Emacs 提交代码前需签署的版权转让/授权文件。目前大部分国家（含中国大陆）已支持电子扫描签署，不再强制邮寄纸质件
  • Edit Indirect：Emacs 中在一个 buffer 内编辑另一个 buffer 片段的技术，常被用来编辑长文档的局部
  • VS16：Unicode Variation Selector-16，Emoji 的变体选择符（控制是否以 emoji 形式显示）。输入法 emoji 编码序列中多/少 VS16 会导致显示异常
  • Harper：开源的英语语法检查引擎（writewithharper.com），专注语境级和建议性检查，支持 LSP
  • Flymake：Emacs 内置的语法检查框架，目前仅支持提示错误，尚不能应用修复（code action）
  • SIS：Smart Input Source 或类似输入法管理机制，用于在 Emacs 特定模式切换中英文输入状态
  • Meow：Emacs 的模态编辑框架（类 vi 但更轻量）
  • PragmataPro：一款覆盖广泛 Unicode 字符的等宽字体

💎 碎片知识与金句拾遗

  • 禁用 echo area 保存提示：macOS 下已有取巧方案（参见 emacs-china 帖子），但实测仍会轻微闪一下，Windows 下问题依旧
  • Gnus 阅读邮件列表：「读 ML 倒是适应一下 gnus 就很好用了」——有人推荐使用 gnus-modern 包改善 Gnus 界面，不过作者尚未将其独立发布
  • Emacs 兼容性实证：Emacs 30.2 在 UOS20「旧世界」龙芯电脑上成功编译，兼容性确实名不虚传
  • AI 修复开源项目的体感：多位群友用 Codex 修好各自开源项目的小问题，感慨「买了 20x plan 最大的用途就是经常给开源拖拉机修小问题」。另有群友调侃开源收入「可能支撑不起我每个月的 GPT 订阅」，别吃开源饭了，去吃 OpenAI 的开源饭——有 5000 star 就可免费用 6 个月 Pro
  • 中英混排表格对齐：markdown-ts-mode 将中文按单宽度计算导致表格错位，这是一个具体且高频的跨语言排版痛点
  • Org-mode 折叠可用性缺陷：光标在 ...（折叠标记）后面时，tab 无法展开折叠内容。群友贡献了一段 org-cycle-tab-first-hook 代码，折叠后光标在边缘时自动跳转到标题头并展开。建议 org 上游提供定制选项：层级较深时 Tab 不应让光标跳到最后
  • Windows 下的 Emacs 使用心得：设置 scoop shims + 将 git 加入 PATH + 开启 beta unicode，日常使用除 curl 偶发乱码外无大碍
  • 中文输入法与 Emacs：使用 Meow 模态编辑时，normal 模式下自动切英文，完美解决「按 r 前多按一次回车」的输入法困扰。非模态用户可用 (add-hook 'viper-vi-state-hook (lambda () (w32-set-ime-open-status nil))) 实现类似效果
  • 字体兼容性吐槽：一个 LIGHTNING MOOD BUBBLE（U+1F5F1）Emoji 引发了「no font available」的显示问题。PragmataPro 覆盖了该字符，Apple Symbols 无法显示。Emoji 编码序列中的 VS16 缺失/重复是输入法常见数据质量问题
  • 「matrix 这个 html 支持太广那不是在 emacs 里很难搞」——Element/Matrix 的 HTML 渲染范围过广，间接吐槽 Matrix bot 用 Rust 写的还会 panic
  • Emacs 音译梗：有人调侃「vim 间谍混进了 markdown-ts-mode 的开发」和「vim 间谍混进核心开发者」来解释令人不满的设计
  • orgdown / commonorg：有人提到曾有人尝试做 org 的标准化类似物「orgdown」，未成。群友不切实际地畅想搞个 commonorg 或 orgtsmode 重写
  • 工作生活平衡金句：「人为什么要上班」「晚上快十点了才到家，感觉要等我被裁掉才行了」——道出开源贡献者的现实困境，995 消磨精力，开源梦只能等「被裁后」实现

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

  • flymake-harper.el / harper-ls：Pillip 正在推往 ELPA 的 Harper 集成令人期待。虽然 Chrome 实测建议质量不够理想，但这是 Emacs 生态少有的语境级语法检查器，作为 LSP 后端配合 Eglot 的 harper-ls 值得试用
  • Gnus + ML 的现代工作流：群友提到「gnus-modern 包」尚未独立发布，若能继续打磨，对需要参与邮件列表（含 Emacs devel）的开发者很有价值
  • Org-mode 中文词边界 patch：虽然讨论未得出结论，但「用 word-category 改进断词识别」是一条具体的 patch 思路。有精力的开发者可参考 CommonMark 的 a*b*c 处理方式与 org 现有 escape 机制，先发邮件参与 org-mode list 讨论
  • Emacs 30.2 在 UOS/龙芯平台的编译：跨平台编译细节未展开，但对信创生态部署 Emacs 有参考意义

本节讨论时间跨度：2026-08-19 07:22 ~ 23:37，共 299 条消息 主要讨论者：κόσμος、zdn、Lucius_Chen（皮皮虾）等 气氛主线：从 Emacs 日常使用 → org 中文解析之痛 → Emacs 架构批判与辩护 → 开源贡献现实困境，技术浓度与吐槽交织。

🧠 Hermes GPT-5.5 观点延伸

中心判断：org 的中文标点解析问题，本质上不是 parser 写错了，而是 org 没有 spec。当语言本身没有被定义时，parser 的行为就自动成为事实标准——今天群里所有技术路线之争（ZWS、word-category、org-treesitter），其实都是在绕开"org 到底是什么"这个上游问题。

  • ZWS 是官方答案，但它是坏答案。 零宽字符当语法，等于把不可见的数据损坏写进规范：grep 不到、diff 看不出、复制粘贴会在文件间扩散，排查成本全部转嫁给使用者。"到处插 zws 是人想出来的解决方案吗"这句吐槽不是情绪，是准确的工程判断——它是对维护者成本最低、对用户成本最高的方案。

  • markdown-ts-mode 能做对，靠的不是 tree-sitter，是 CommonMark。 tree-sitter 要 grammar，grammar 要 spec。CommonMark 把强调定界写成可判定的 flanking 规则并附带官方测试集，parser 才有"对错"可言；org 恰恰没有这个。所以"我们需要 org treesitter"是口号不是方案——在 spec 存在之前重写 parser，等于给 undefined behavior 写实现，谁都验证不了。

  • 群里真正可行的路线是 word-category。 Emacs 的断行逻辑已经在用 word-category 处理中文边界（word-wrap-by-category），把同一套 Unicode 类别判定挪到强调标记的定界规则上，是改动面最小、且有现成参照系（CommonMark 的定界规则）的 patch。它不需要先发明一个 commonorg，只需要承认"标点不是词的一部分"。

  • 这同时解释了"Emacs 抗 AI"的悖论。 同一个群里，Codex 分分钟修好雾凇 emoji 的 VS16 数据——因为编码规范明确，有 oracle 可对拍；而 org 中文解析没人修、AI 也修不动——不是因为代码更难，而是正确性没有定义。AI 改不动无 spec 的系统，人也一样；这跟"屎山"无关，跟"无标尺"有关。

可继续实践的方向：先别写 patch，先写 test corpus。收集 50-100 条中英混排强调用例（含 =x/y= 紧邻中文标点、标点两侧加粗等），逐条标注期望行为，发到 org-mode 邮件列表。这是在给 org 种 spec 的种子：先让"什么算对"可判定，修复才有意义。比畅想 orgtsmode 靠谱一个数量级。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：AI 辅助开发的边界与"无人值守"困境

这是今日群内最具思辨深度的讨论，围绕"AI 能否真正做到无人值守开发"展开。

核心痛点： 有群友直言对"AI 无人值守开发"持怀疑态度，即使采用多代理并行与 worktree 拆分工作范围，依然难以逃避一个根本矛盾——AI 对问题的理解永远不如人类深刻，而人类自身对问题理解不够深刻时，又会向 AI 提供错误的上下文。

三个不确定性： 讨论中提炼出 AI 开发中必然面临的三种失控模式：

  • 一些没说的，它做了；
  • 一些说了的，它没做；
  • 一些说了的，做歪了。

深层归因：

  • 当前 AI 最大的瓶颈在于与人类的交互方式——人类不具备像工具那样快速理解已生成上下文的能力，只能一点点检查；
  • 即使不断"grillme"（反复追问），模型也会在过程中不断偏离目标；
  • 注意力机制有限，且存在熵增效应，导致上下文不断被污染；
  • 随着项目规模膨胀，上述问题只会愈发严重。

务实解法（群友实践）： 一位群友分享了自己回归"辅助模式"的工作流：

"我要求大模型给出思路、架构，以及大概的代码，我自己来实现，一旦发现实现不对劲就立即回馈给模型。要求它明确按照我的想法去走，只让上下文停留在当前问题上。"

这个方法的核心在于缩短反馈环，将 AI 的职责限制在"思路与架构"层面，而非放任其自主决策与实现。

专题二：Emacs 与 Windows 的远程连接方案之辩

围绕"从 Linux 连接 Windows"的场景，群内展开了对多种技术路线的比较：

方案优势限制
Tramp + SSH（plink）配合 eglot 可用Windows 自带的 SSH 服务连不上，需用 PuTTY 的 plink
Tramp + SMB无需 SSH 服务，原生可用运行命令需依赖过时的 winexe；dired 默认会跑 git 等命令，受限
Tramp-rpc理论上支持 Windows，概念更现代群友实测未能正常工作

还补充了一个关键知识点：coreutils for Windows 的出现让 Windows 侧的 Tramp 支持变得更可行，因为 Tramp 对 POSIX 环境（如 bash）有依赖。

另有一位群友表示自己从不用 Tramp，直接 SSH 过去用 vim 改配置——简单粗暴但有效。

专题三：Telega（Emacs 的 Telegram 客户端）字体渲染疑难杂症

现象： 群友在 Windows 版 Emacs 中使用 telega 时，发送的贴纸（"猫猫"）出现异常"切割"，被拆分成块状。

排查过程：

  1. 怀疑是同一行有其他字符导致开裂，但头像显示正常，排除该可能；
  2. 通过 describe-char 检查字符属性，未发现明显异常；
  3. 用 (line-pixel-height) 测量行高，发现与 slice 高度不一致；
  4. 最终定位：字体设为奇数大小（150）导致问题，改为偶数（140）后正常。

教训： 群友总结道，字体 size 换算后（除以 10）为 15 时就有问题。另一位群友补充曾在 Linux 主群讨论过"字体奇数大小"问题，但当时没想起来。讨论中还推荐了 IBM Plex Mono 作为替代字体，并给出了自动选择字体的 Elisp 循环示例。

专题四：Rust target 目录的管理新动向

群内分享了一则简短但值得关注的消息："rust 社区终于想到要解决 target 目录的问题了吗"。虽然未展开细节，但这指向 Rust 项目长期存在的编译产物空间膨胀问题，暗示社区或官方可能已有新的解决方案在酝酿。

🔑 关键概念与技术解析

  • Tramp (Transparent Remote Access, Multiple Protocol)：Emacs 内置的远程文件访问框架，支持通过 SSH、SMB、rpc 等多种协议远程编辑文件与执行命令。
  • plink：PuTTY 套件中的命令行 SSH 客户端，常被用作 Tramp 连接 Windows 的底层传输工具。
  • coreutils for Windows：GNU coreutils 的 Windows 移植版，提供 ls、rm、cat 等标准 POSIX 命令，降低了 Tramp 在 Windows 侧的依赖门槛。
  • Tramp-rpc：新提出的 remote procedure call 协议支持，理论上比传统 SSH/SMB 方案更轻量、更现代。
  • winexe：较老的工具，用于从 Linux 远程执行 Windows 命令，年代久远，维护状况不佳。
  • corfu：Emacs 的轻量级补全框架，基于 completion-at-point-functions（capf）机制，通常需配置手动触发（如 Tab）。
  • telega-completions-setup-capf：telega 提供的 capf 补全设置函数，需在 telega-chat-mode-hook 中调用才能启用 @ 提及等补全。
  • Telega：Emacs 的原生 Telegram 客户端，基于 tdlib 库实现。
  • tdlib / telega-server：Telegram 官方的底层通信库与 telega 的服务端组件，原本在 Windows 上需自行编译，群友已掌握打包方案。
  • agent-shell：Emacs 中集成 AI agent 的交互工具，今日有群友反馈其卡顿严重。
  • Hard Reset：AI 模型上下文的硬重置机制，讨论中提及"banked reset 才是真正有用的"，暗示当前重置策略中存在部分无效操作。
  • herdr：一个新兴的终端多路复用工具，群友实测感觉比 tmux 更舒适。
  • multica：用于辅助科研工作的工具，由一条 X（Twitter）链接引出，具体细节未展开。

💎 碎片知识与金句拾遗

  • Emacs 内置命令是被忽视的宝藏。 多位群友分享了高频使用的冷门命令：

    • C-x C-o（delete-blank-lines）：消除多余空白行但保留一个，非常常用；
    • C-x [ / C-x ]：跳转到上一个/下一个分页符（^L），无分页符时跳转文首/文末；可用 M-< / M-> 跳转页首/页末；
    • M-l / M-u：快速转换单词为小写/大写；
    • C-q xxx：直接输出转义字符；
    • delete-region：使用频率极高但常被忽视，建议自行绑定键位。

  • 思想火花： "如果熟悉内置命令，并优化得好，可能还真的不太需要那么多第三方包来帮忙。"

  • Telega 定制通知的困局： 修改 telega-notifications-msg-temex 后，拿到的是消息 ID 等元数据而非用户文本，想拿具体内容需要"让 AI 扫描源码"或自行 hack。Windows 上系统通知更是需要写 C# 来实现。

  • Agent-shell 性能吐槽： 有群友直言"被 agent-shell 卡成翔"，但该工具声称支持 tramp，具体兼容性存疑。

  • Kitty 终端的图形协议： 群友分享道，kitty 拥有图像显示接口且"效果还不错"，如果 Emacs 在终端上接入 kitty 的接口，或许能解决很多显示相关问题。目前是否有类似工作尚不明朗。

  • Doom Emacs 冷知识： 有群友学着 Doom Emacs 的方式配置 first-file / first-input hook，结果启动时间反而更慢了——"优化"有时候得不偿失。

  • Hard Reset 的"小巧思"： 群友提醒，模型重置（Reset）中只有 "banked reset" 真正有效，某些号称 Reset 的机制形同虚设。这种阴招"A\ 都想不出来"。

  • 航天冷知识： 朱雀三号遥二火箭（2026-08-19 发射）成为我国首款成功入轨并实现陆地回收的运载火箭，着陆点位于甘肃省民勤县。外观与猎鹰 9 号的相似性引发"可回收技术相互模仿"的讨论，群友淡定评价："我们一向摸着石头过河。"

  • Windows 下 Emacs 字体的坑： 除了奇数字号问题，还提到"合成数（如 16）没有问题"。排查方法：用 (line-pixel-height) 核对行高是否与预期一致。

  • 实用资源分享： awesome-windows-on-linux（GitHub 上整理的在 Linux 上使用 Windows 的精选资源）、IBM/plex 字体仓库、群友 zHaOdANiuu 的 .emacs.d 配置（含字体设置）。

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

  • Telega 在 Windows 平台的打包分发：群友已掌握打包 tdlib 和 telega-server 的方法，若整理成脚本提交给 msys2 官方，可让 Windows 用户免编译直接使用——有实际的社区贡献价值。

  • Tramp-rpc 对 Windows 的支持：理论上存在，但群友实测未成功。若能调通，可能成为替代 SSH/SMB 的第三种优雅方案。值得关注其进展或问题所在。

  • Kitty 图形协议与 Emacs 的整合：Kitty 的图像显示接口（graphics protocol）若与 Emacs 结合，有望解决终端模式下 Emacs 的诸多显示问题（如图像切割、行高校准）。目前似乎无人尝试，存在空白机会。

  • 字体大小奇数导致的渲染异常：这似乎是 Emacs/HarfBuzz 渲染中的一个边缘 case。若能在主群汇总并复现，可考虑向 Emacs 上游提交 bug report。

  • 多代理 AI 开发中的"上下文熵增"问题：讨论中提出的"熵增导致上下文污染"是一个值得进一步探索的理论框架——是否可以通过强制性的上下文快照与回滚机制来对抗这种退化？这或许是多代理系统设计中的一个关键课题。

🧠 Hermes GPT-5.5 观点延伸

中心判断：三种失控模式不是三个 bug，是一种病。 没说的做了、说了的没做、说了的做歪，归根结底是模型在对抗一个未被精确表述的目标。群友那句"如果有人可以做到精确完美地提供上下文，那么可能做到无人值守开发"本身就是反证：上下文是否完美，只有当你已经彻底理解问题时才能验证；而验证成立的那一刻，无人值守已经失去意义。所以"回到辅助模式"不是退让，是把验证通道放回它唯一高效的位置——人身上。

一、熵增的真正对手是固定的阅读带宽。 讨论点出"熵增导致上下文污染"和"规模膨胀只会更严重"，这里的不对称被低估了：生成在加速，人的复核速度是常数。无人值守跑得越久，审查负债越大，三种失控只是漂移累积到不同阶段的症状。这也解释了为什么不断 grillme 也救不回来——追问本身同样在往上下文里加熵。

二、辅助模式其实可以工程化。 "要思路、架构和大概代码，自己实现，发现不对劲立即回馈"——本质是让人充当测试套件：偏差在编译和行为层面被即时抓住，而不是事后 review。同一天的另一句"最难的地方确实是需求明确、验证方法明确"就是它的形式化表述。而"gpt pro 给个产品样例它自己设计好了，比我强多了"并不矛盾：设计端强、执行端漂移，恰好是辅助模式成立的证据。

三、Emacs 侧有同构证据。 当天两个相邻话题讲的是同一件事：内置命令是"挖不完的宝藏"，"熟悉内置命令、优化得好，可能真的不需要那么多第三方包"；而照搬 Doom 的 first-file/first-input hook 反而拖慢启动。机制堆叠自带熵税——包多不必然强，hook 多不必然快。agent 编排层也在收同样的税：上下文里"机器自己的话"占比越高，自我泛化越容易，而自我泛化正是偏移的源头。

四、字体 bug 是"验证方法明确"的正面教材。 排查路径——describe-char、line-pixel-height 对比 slice 高度、锁定奇数 size——没有一步靠猜，诡异 bug 几分钟塌缩。无人值守开发缺的正是这套测量：代码跑通不等于意图达成，而意图目前没有可执行的测量工具。

可继续研究/实践： 把赌注从自治转移到可验证性。强制 agent 每次变更附带能失败的验收脚本（测试先行、类型当契约），让意图以检查的形式固化进仓库，而不是靠人重读上下文复核。一个可做的实验：最小 agent 工作流，唯一规则是"生成必须携带验收脚本"，对比辅助模式与无人值守两种设定下偏差的发现时延与数量。若差距主要来自发现时延而非发生频率，就证明无人值守的唯一短板是那条串行的验证通道——剩下的才是工程问题。