Geekinney

外观

Emacs 社区日报 2026-08-20

约 5190 字大约 17 分钟

2026-08-20

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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：Org-mode 中文强调标记的空白问题

从凌晨的“光标移动”话题衍生而来，群友在中午集中讨论了 Org-mode 中文加粗/斜体必须加空格 的痛点。核心矛盾：*强调* 在中文语境下必须写成 中文 *强调* 中文，否则标记不生效，这破坏了中文排版美感。

讨论中提出的候选方案（来自群友的一张表格）：

写法评价问题
「强调」视觉最好本身有引号语义
〔强调〕最适合做自定义语法键盘输入稍麻烦
【强调】太强更像标签/标题
[强调]不推荐Markdown 链接、编程语法冲突
〈强调〉不推荐容易与篇名号混淆
《强调》不推荐已有明确的书名号语义

最终解决方案：一位群友给出了修改 org-emphasis-regexp-components 的正则方案，允许标记直接与非 ASCII 字符相邻，而不需要空格：

'("-[:space:]('\"{[:nonascii:]"
  "-[:space:].,:!?;'\")}\\[[:nonascii:]"
  "[:space:]"
  "."
  1)

效果：中文*粗体*内容、中文/斜体/内容 均可正常解析。但 ASCII 英文字母仍不能作为边界（foo*bar*baz 不会误触发）。群友提醒需检查 org-element 的解析是否同步正确，但该群友表示“我这里够用了，不管了”。

专题二：Human Emacs —— 反对 LLM 代码的 Fork

深夜话题，源于 lobste.rs 与 r/emacs 上关于 Human Emacs 的讨论：一个只允许手打代码、拒绝 LLM 生成代码的 GNU Emacs fork，签名者包括核心开发者 Alan Third。

各方观点：

  • 部分群友认为这是“反知识传播”行为，因为工作单位在训练大模型，明确反对这种对知识传播的阻挠。
  • 也有人认为社区与开发组“隔离”，不会对 GNU Emacs 产生实质影响。
  • 有群友指出技术上的死穴：GNU Emacs 可以合并 Human Emacs 的代码（只要有人做了 FSF copyright assignment），但反之不行。因此 GNU Emacs 最终会功能更多更好用，Human Emacs 没有竞争力。
  • 还有人调侃“找一个签署过的人用 LLM 洗稿一下🌚”即可绕过限制。

专题三：Telega 图片预览的流畅性原理

群友 zdn 发现 telega 中预览图片“出奇的流畅”，猜测是因为 telega 把图片切成块（切片）渲染，并提问是否有对应的包。另一位群友给出了 image-slice 项目链接。此话题停留在初步探讨阶段，未展开实验。

🔑 关键概念与技术解析

  • org-emphasis-regexp-components：Org-mode 用于控制强调标记（粗体/斜体/代码等）边界的正则组件。通过调整其四个组成部分（前后缀边界、中间内容、标记前缀、标记后缀），可以改变标记的解析规则，使其支持中文相邻标记。
  • telega-sis-mode：一个通过 AI 生成的 Emacs 包（github.com/Eason0210/telega-sis），实现在 telega 编辑区自动恢复输入法状态，光标移动到不可读区域时自动切换为英文。原理是利用 telega-chatbuf--input-marker 判断光标是否在输入区，并用 buffer-local 变量记录上次区域，只在区域变化时调用 SIS，不依赖 Meow。
  • image-slice：将图片切分为多个切片进行渲染的技术，telega 利用此机制提升滚动流畅度。GitHub 项目：LuciusChen/image-slice
  • Human Emacs：一个只接受人类手写代码、拒绝 LLM 生成代码的 GNU Emacs fork 计划，由社区发起并得到部分核心开发者签名支持。
  • org-modern / evil-org：前者是 org-mode 的现代美化包，后者为 evil-mode 提供 org 支持。凌晨讨论的“光标无法移动到行尾”问题最终被确认为 evil-org 的配置问题，而非 org-modern。

💎 碎片知识与金句拾遗

  • “不要在 org/md 里面用 ligatures，会把一些符号标记成连字导致 org 标记渲染错误” —— 一个很弱智但容易被忽视的问题。
  • telega 查看图片快捷键：光标移动到图片消息上 → RET 打开 → i + / i - 缩放 → i o 保存。“原来还挺方便的。”
  • 中文斜体的字体问题：中文字体斜体时会 fallback 到其它字体，Emacs 的斜体渲染“有些字体会 fallback 其它字体去，就识别不到对应字体的斜体类型，得自己单独去设置”。
  • 字体混搭工作流：霞鹜文楷用的是 Warcraft-Font-Merger；maple-font 是自己写 Python 脚本调库。群友感叹“换好了，但大小虽然一样，楷体看上去就是更小”。
  • “零宽空格原来是有宽度的” —— 一个冷知识。
  • magit discard 与 hjkl 冲突：群友提问后得到解决：spc k 即可，或者 evil-collection 里有选项。
  • Emacs 默认配色：“原生的配色一直觉得挺好的，醒目不刺眼” —— 对默认主题的肯定。
  • Canvas 合并进 Emacs：有人提到可以播放视频、改善 PDF/EPUB 渲染、画动图；也有人尝试与 widget 结合但效果不佳。“感觉可以在 emacs 里面复刻 jupyter 了。”
  • flymake 可以接 compilation buffer：“有个统一的列表界面是好的”，hl-todo 已经可以接入。
  • r/emacs 是 anti LLM 的大本营：“之前在上面发了个帖，问 AI 和 emacs 有啥结合的，哇，那场面，个个都来叼我。”但“现在 r/emacs 上反对 AI 的氛围没有一年前那么明显了”。
  • 关于 Human Emacs 的嘲讽：“大家每个人 fork 一个 gnu/emacs 玩吧，然后我们搞一个 crazy/emacs，就叫 love/emacs 吧”，“蹬 llm 从头写一个 emacs”。

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

  1. org-emphasis-regexp-components 中文适配的完整验证：群友只验证了显示层面，未检查 org-element 的解析结果。后续可进一步验证这一正则方案对 org 各类操作（如 org-ctrl-c-ctrl-c、导出等）的兼容性。
  2. telega 图片切片渲染机制：telega 的流畅滚动源于切片渲染，image-slice 是否可作为通用方案解决 Emacs 大图预览卡顿问题？值得跟进实验。
  3. telega-sis-mode 的通用化：当前实现不依赖 Meow，仅通过 buffer-local 变量与 SIS 配合。是否有更简洁的实现方式，以及能否推广到其它聊天客户端（如 erc、eiq）？
  4. Emacs Canvas 能力边界：合并后的 Canvas 支持播放视频与 SVG 动画，但群友尝试与 widget 结合效果不佳。未来可探索其在 Jupyter 式交互、数学动画演示等场景的潜力。

🧠 Hermes GPT-5.5 观点延伸

中心判断：Human Emacs 想防御的东西，在工程上不可验证。"手打"不是代码的性质，是编写时发生过的历史事件；事件过后没人能审计它。

  1. 对称性论点当晚就被修正了：没有 FSF copyright assignment，GNU Emacs 同样合并不了 Human Emacs 的代码。真正的不对称在输入侧——GNU Emacs 的瓶颈从来不是缺代码，是缺 reviewer。用"禁 LLM 产出"给自己限流，等于把"作者没用工具"当成质量代理指标，两个变量本不相关。群里那句"不用 llm 迭代速度肯定不如 nvim"点破了本质：这是产能竞争，道德表态改变不了供需。

  2. "找一个签署过的人用 LLM 洗稿一下"不是调侃，是形式化证明：任何靠人工审查执行的来源禁令，都败给不可区分性——洗过的补丁与手打的补丁在字节层面无法区分。要强制执行只有工具层监控，那比病症更糟。所以这条规则注定退化成小圈子的社会规范，对 hobbyist fork 够用，但不构成对软件质量的任何保证。

  3. 更反讽的一层：上游现在就不收 LLM 代码，fork 的触发条件是一个尚未发生的未来事件。一个以"如果 GNU 哪天接受"为前提、分不分裂取决于别人决策的 fork，是政治宣言，不是工程分叉。宣言有价值——把"代码应否标注来源"推到台前；但把它当技术方案讨论，就错位了。

  4. 同一天的最佳反讽是 telega-sis-mode：AI 代写的包，正常发布、正常讨论。这个社区的实际工程实践早已 LLM 混合，反 LLM 只是修辞规范。真正的共识藏在讨论质量里：没人反对 AI 辅助，反对的是未经 review 的产出直接入库。LLM 把稀缺资源从"作者"挪到"审者"——政策该管的是验收责任，不是来源。

另一个当天悬案（纯工程向）：org 中文强调的正则方案留了个五分钟就能验掉的问题——有人提醒"检查一下 org-element"，当事人回"够用了"。跑一遍 org-element-parse-buffer，看 中文*粗体*内容 在 AST 里是否真成为 emphasis 对象；导出、链接、agenda 是否静默丢格式，全取决于它。改显示层不动解析层，是 Emacs 社区最爱的操作，也是最常见的静默事故来源。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：Linux 桌面环境设计之争——从 omarchy 到 KDE 的审美碰撞

群内围绕 omarchy 发布与 Linux 桌面环境设计理念展开激烈讨论，横跨多个话题线，核心矛盾点在于：Linux 是否应该向 Windows/macOS 用户妥协，提供“开箱即用”的体验，还是保持“定制化”的极客传统？

  • omarchy 现象解读：创始人 DHH（Ruby on Rails 作者）的个人流量与社区号召力是核心推动力。其“omakase”理念（作者认为好的就直接塞进去）吸引了不愿折腾的用户，但也引发担忧——“把 Windows/macOS 用户带入 Linux 世界”的策略是否会将 Linux 的“自由定制”本质带偏。
  • 审美对立：多位成员对 KDE 的“Windows 式深层 UI”和 Material Design 表达强烈不满，认为其“没有设计感”“丑了十几年”。相比之下，hyprland 等 Wayland 合成器被部分成员视为“更 Linux”的选择，尽管也存在“大圆角”等设计问题。有人感慨“在 arch 群里提出 kde 丑，没有一个人自知的”，侧面反映审美偏好存在圈层固化。
  • 技术 vs. 体验：讨论从 UI 外观延伸到更深层问题——有成员指出，即便 omarchy 这类发行版做了统一，用户安装第三方软件时依然会遇到“割裂感”，因为 Linux 生态“很多东西都统一不了”。底层网络、系统优化才是 Linux 发行版最该做好的方向，其余应交给用户。

专题二：AI 编程工具链（harness）的爆发与“vibe coding”热潮

白天到深夜，群内持续分享并对比 Claude Code、Codex、OpenCode、OMP、Grok 等多种 AI 编程工具，并出现“vibe coding”（用 AI 快速生成代码）一词的讨论。

  • 工具对比与体验：有成员表示“最近试了 claude codex opencode omp和grok”，并认为 OMP “打磨得确实还挺好”“最搭我口味”。Grok 被爆料“140万行 rust”，有人“对🦀切魅”，也被调侃“grok build vibe出来的吧”。
  • harness 的形态与体验：关于“harness”的讨论不止于 CLI 工具，还涉及 Emacs 内集成方案（如 superchat、Pi、bub 等）。有成员表达对“harness 前端交互”的执着，认为可能“走偏了”，而 Pi subagent 被指出“占用的上下文有点多”。
  • 对开发流程的反思：出现“如果 ruby 的速度能拉到和 java 和 c#层次，很多人怕是会直接抛弃这两个”的感叹，侧面反映 AI 工具在提升开发效率后，编程语言的性能差异可能成为新的瓶颈。

专题三：Emacs 配置优化与启动速度焦虑

从凌晨到深夜，Emacs 配置、启动速度、包加载策略和内置功能替代是贯穿一天的讨论焦点。

  • 启动时间痛点：有成员抱怨 Windows 下 Emacs 启动“得几十秒”，而分享者则展示“1.5s”甚至“0.9s”的成绩，并分享配置思路——参考 Doom Emacs 的 hack，彻底禁用运行时 eln 编译，大量使用 defer，删减用不到的边缘情况。
  • AI 驱动优化：有成员尝试用 Codex 优化配置但“没太大提升”，而另一些成员则表示“直接发给 codex 搞”，并互相分享 dotfiles 仓库。
  • 内置 vc vs. Magit：关于 Git 操作，有成员惊讶于“内置的vc速度是真快啊”“秒开”，而 Magit 的性能“一直是被诟病的”，由此引发关于 Magit-section 复杂度和刷新机制的讨论，甚至有人计划“尝试搞 editable-magit-section”或替换掉 Magit-section。

专题四：Anthropic 拒绝支持 AGENTS.md 标准引发争议

有成员指出 Anthropic 拒绝支持 AGENTS.md 标准，并称其为“邪恶的公司”。讨论从标准兼容性延伸到 AI 工具生态的“护城河”问题，并感叹“软件护城河没了啊”——“一个用户如果把一个软件用透，那么就可以用 codex 做出来一个差不多的”。然而，亦有成员表示自己“白嫖了几个问题第二天就给我封号了”“第二个基本秒封”，提示免费用户面临的封号风险。

🔑 关键概念与技术解析

  • omakase：omarchy 的设计哲学，源自日本料理“厨师发办”，意为“作者认为什么是好的，就直接往里面塞”，代表了“预制菜”式的开箱即用产品思路。
  • vibe coding：指利用 AI 工具（如 ChatGPT、Codex）以自然语言描述需求，由 AI 生成代码，强调“感觉/氛围”驱动的编程方式。群内吐槽“现在哪个不是 vibe 出来的”。
  • jj (jujutsu)：一个基于 git 的分布式版本控制工具，旨在简化 git 的工作流，提供更友好的命令和更清晰的冲突处理。讨论中提到“omp也有 jj 支持了”“还是 jj 好用啊”。
  • ActiveRecord：Ruby on Rails 的 ORM（对象关系映射）框架，因其强大的查询接口和 ActiveRecord Query Interface 备受推崇，被群友评价“没找到一个能打过 active record 的”。
  • agents.md：一个用于向 AI 编码工具（如 Codex、Claude）提供项目规范与背景信息的标准文件，旨在提升 AI 协作效率。Anthropic 被曝拒绝支持此标准，引发争议。
  • Mermaid：一个通过文本生成图表的 JavaScript 库。有成员希望将 org 导出为 mermaid，但受限于“需要在网页也能在图里按链接跳转”，认为“目标肯定不是图片”。
  • Material Design (MD)：Google 的设计语言，因手机信号图标等设计问题被群友批判“最丑”“没有设计感”，但也有成员表示“很牛逼”，并喜欢其“莫奈取色”等特性。

💎 碎片知识与金句拾遗

  • Emacs 内置 ASCII 表：凌晨时有成员提问“有没有内置的 asinc表”，得到回复“ascii表是有的”，并提及命令 (list-charset-chars 'ascii) 或 man ascii。有人感叹“ascii 图好像挺好用的”。
  • 博客主题搜索性能问题：有成员提到其 VuePress 主题的博客“搜索的时候风扇狂转”，怀疑是内置搜索性能不佳，并计划“回头反馈给作者”。另一成员回应“这种SSG的内置搜索都不咋的”。
  • AI 绘图流程图对齐问题：有成员抱怨“ai画的流程图每次都对不齐，感觉还是很烦人”，并推测“可能glm还不太擅长”。
  • KDE 设计“带偏审美”：群友抱怨“kde 带偏人们的审美”，认为其“只是在符合Windows用户的操作习惯”，但也承认“对于用户迁移来说倒也是必要的”。
  • “我系统都没有UI”：有成员表示“完全没有烦恼”，侧面反映部分极客对无桌面环境（headless）的偏好。
  • 采购视角下的技术支持：有成员分享采购经验：“我一般都提前拿好运维的东西，预估一下报价”，并提醒“如果没有人能接手，就按购买服务来采购;如果有人能接手，就以采购硬件的形式来”，因为“技术支持当然是坑，就好像开黑盒了”。
  • 生活与游戏：多人感叹没时间玩《黑神话：悟空》，有成员表示“我不喜欢玩这类3A”“动作游戏苦手”，也有“我比较喜欢战棋类、建造类”。有成员分享“我老婆会半小时进来骚扰我一下”。
  • Windows 下 Emacs 启动时间：有成员分享配置后启动时间从几十秒降至 1.1 秒左右，首次打开 2-3 秒，并提到“禁用运行时 eln 编译”“参考 Doom Emacs”。
  • omarchy 热度来源：群友指出其创始人 DHH 是“流量明星”，“mvc潮流就是他带起来的”，并评价“他很有个人魅力，社区号召力也很强”。
  • “黑猿”梗：有人错打“黑猿”（黑神话：钟馗），引发一阵调侃，被纠正为《黑神话：悟空》。

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

  • editable-magit-section：有成员提出要“尝试搞 editable-magit-section”，以解决 Magit-section 复杂度和刷新机制带来的性能问题，并计划“给majutsu简化一下代码”。这一方向或将影响 Emacs 生态中最常用的 Git 界面。
  • bub.build：被推荐为“极简，且完全插件化”的聊天室项目，可作为学习“复杂实例”的参考，或许值得跟进其架构设计。
  • majutsu.org：群友发布的新项目，被描述为“堆了很多屎山”，正在规划简化代码，值得关注其迭代历程。
  • terminal-code：https://github.com/zenbu-labs/terminal-code 被评价为“好抽象”，但未展开细节，可作为冷门工具观察。
  • ankole.agentbull.com：群友提到其文档“写得超级强”，并讨论“作为甲方采购视角”的价值，可研究其文档结构。

🧠 Hermes GPT-5.5 观点延伸

中心判断：“软件护城河没了”这句话，当天群里的讨论自己就把它证伪了一半。护城河没有消失，只是从“能不能做出来”迁移到了“愿不愿意重做一遍长尾”。

  1. Magit 悖论：人人喊“vibe 一个 vibgit”，却没人真的 vibe 出来。Magit 的性能被诟病多年，今天的讨论终于落到了具体工程判断上——magit-section 抬高复杂度、refresh 非增量、vc 靠异步所以秒开。这是可验证的结论，不是玄学。但别高估它：Magit 的价值大头不在 section 渲染，而在十五年攒下的 git 边界状态处理。所谓护城河，恰恰是 happy path 之外那 5% 的场景，而 AI 生成代码最弱的就是长尾。当天另一个证据与此呼应：有人让 Codex 优化启动配置“没太大提升”，而手调 1.1 秒的人靠的是“删减我用不到、Doom 会处理的边缘情况”——“用不到什么”是私有使用信息，不在 dotfiles 里，Codex 看不见。护城河的真实形态是隐性经验，不是代码本身。

  2. 护城河正在别处重建。同一天，群里一边感叹“软件护城河没了”，一边骂 Anthropic 拒绝 AGENTS.md、白嫖封号秒封。应用层的墙在塌，模型厂商的墙在砌：标准不兼容和账号风控就是新的墙。这对个人工具链有直接含义——越贴近某个厂商私有标准的工具，迁移成本越高；AGENTS.md 这类开放标准反而该被工具侧主动支持。

  3. “harness 前端交互走偏了”是当天最清醒的一句。大家都在卷 TUI 颜值，而真实痛感全在集成边界：grok 的 TUI 让 tmux 历史搜不到自己的对话、pi subagent 吃上下文。harness 的竞争点不在谁更像 IDE，而在上下文预算和宿主环境（Emacs/tmux）的贴合度——这两样都截不了图，所以没人拿来营销。

可继续实践：把“AI 重写存量工具”当对照实验跟踪——盯 majutsu 替换 magit-section 后功能覆盖是否回退。自己动手更简单：用内置 vc 跑一周，记下哪些时刻忍不住切回 Magit；那份清单就是 Magit 护城河的量化结果，也是“vibe 一个 vibgit”的验收标准。