Geekinney

外观

Emacs 社区日报 2026-09-07

约 5244 字大约 17 分钟

2026-09-07

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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：Emacs 解释器性能优化——eval_sub 拆分实验

这是一条贯穿全天的主线。群友 @zdn_y（后续以“zdn”指代）对 Emacs 的 C 核心解释器 eval_sub 进行了函数拆分优化，并引发了一系列围绕 benchmark 方法论、GC 干扰、AOT vs JIT 的深入讨论。

实验细节与结果：

  • zdn 将 eval_sub 拆分为 eval_sub_1，通过 objdump 确认指令数量减少（少了一堆 push），并分享了 commit 0076b8df578。
  • 用素数求和测试（200 万以内）观察到了约 5%~10% 的纯解释执行提升。
  • 但在 elisp-benchmarks 测试集上表现不佳：移除了 elb-scroll、inclist、inclist-type-hints 后，平均普遍变慢约 1%，很难断定是噪声还是真实回归。
  • zdn 在 macOS M4 Pro 上测试，另一位群友在 Windows 上复现时也有类似现象。

讨论焦点：

  • GC 干扰：多位群友指出，多数 benchmark 的大头是 GC，解释器跑得再快，如果 GC 占比高，整体收益也会被稀释。
  • benchmark 方法论：有人质疑 elisp-benchmarks 的可靠性（其为 native-comp 作者同一人所写，初衷是测 native-comp 效率），且默认会 byte-compile，导致纯解释执行的优化难以直接评估。zdn 修改了 elisp-benchmark-run 直接解释运行，但一轮就要跑 15 分钟。
  • 优化收益的现实意义：群友 κόσμος 提出“对用户来说，卡的感觉完全来自延迟而不是吞吐”，因此单纯把 lexical frame 提升 2-3x 可能实际体验中根本感觉不出来。他更建议关注 redisplay 和阻塞主线程的 UI 事件循环。
  • NTC (native-comp) 的争议：有人质疑 eln（机器码）相比 elc（字节码）在日常使用中无感甚至倒退。zdn 分享了自己的采样结果（20 组进程采样），实际表现不如 elc，但某些库有了 eln 缓存后明显更好。群友指出 native-comp 只是 AOT 编译，不是真正的 JIT，没有 trace/PGO 优化，因此对数值计算提升大，对其他场景帮助有限。

方案探索与后续计划：

  • zdn 计划继续挖掘优化点，并攒一批消融测试（ablation tests）验证收益。
  • 有人建议做 e2e benchmark（把 magit、vertico、eglot 等真实场景纳入），但 κόσμος 认为“覆盖完整”不太可能，且“性能问题 >=90% 出在用户配置上”。
  • 最终 zdn 感叹“等我退休再考虑优化 emacs 吧”。

专题二：Windows 上的 TSF 输入法支持与 telega 编译困境

群友 eli（或 eli 相关讨论）打算为 Emacs 实现 Windows TSF（Text Services Framework）输入法支持。Windows 11 已默认切换到 TSF，而 Emacs 仍在使用老旧 IME。讨论焦点：

  • TSF 的实现难度：微软官方最简单的 TSF 示例项目约需 6000 行代码，用 C 语言还要翻倍。有群友建议直接手搓 COM（微软组件对象模型），并举例 DirectWrite 实现彩色 Emoji 也是这么做的。
  • 动态模块的语言选择：Emacs 动态模块接口支持 C 和 Rust，但可以薄封装后调用其他语言。群友猜测用 C++ 直接写可能不太可行，但通过 C 桥接是可行的。
  • telega 在 Windows 的编译问题：这是另一个具体痛点。telega-server 完全使用 POSIX API，Windows 上必须用 MSYS 环境构建，但编译 tdlib（Telegram 数据库库）时又需要 UCRT 环境，导致头文件冲突。zdn 给出了详细的解决步骤（安装到独立目录、设置环境变量），并提供了完整的安装指导（见代码块）。
  • 社区建议：群友建议向 telega 作者贡献 Makefile 修改（-I 改成 -idirafter），或者提供预编译的 telega-server.exe 以降低门槛。

专题三：Emacs 启动速度与加载优化

围绕“启动 0.6 秒”和“org 加载慢”展开：

  • 群友分享自己的配置启动时间 0.6 秒，缓存好 0.5 秒。
  • κόσμος 分享了自己给 load-path 做 cache 的经验，org 加载时间缩短到 200ms 左右。
  • 有人提到 org 应该“闲时直接增量加载”，magit 等也是类似策略（放入队列，等你打开时已载入完毕）。
  • 有人提到 package-quickstart 可以把所有 autoload 变成一个文件，再编译成巨大的 elc。
  • κόσμος 补充：把 winner-mode 关掉后感觉跟手了一点；Emacs 没有 regexp compile 可能也是一个可改进的点（考虑到正则的用量极大）。

🔑 关键概念与技术解析

  • TSF（Text Services Framework）：Windows 现代输入法框架，替代了老旧的 IME。Windows 11 已默认切换到 TSF。Emacs 目前仍使用旧 IME，需要重写输入法支持才能适配新框架。
  • eval_sub_1：对 Emacs C 核心解释器 eval_sub 函数进行拆分后得到的子函数，目的是减少指令数量、避免不必要的分配。
  • eln vs elc：eln 是 native-comp 编译出的机器码文件，elc 是字节码文件。前者用 GCC 的 JIT 接口（gccjit）生成，但本质是 AOT（Ahead-Of-Time）编译，并非真正的运行时 JIT，没有 trace/PGO 优化。
  • IGC（Incremental GC）：Emacs 的增量垃圾回收实现，支持用户中断。整体延迟和性能会变差。
  • telega-server：telega.el（Telegram 客户端）的后端服务进程，完全基于 POSIX API，Windows 上需要在 MSYS 环境构建。
  • tdlib：Telegram 官方数据库库，编译时依赖 UCRT 环境。在 Windows 上与 telega-server 的 MSYS 环境存在头文件冲突。
  • elisp-benchmarks：用于测试 Emacs Lisp 性能的官方 benchmark 套件，由 native-comp 作者同一人编写，默认会 byte-compile。
  • UCRT / MSYS2：UCRT 是 Windows 通用 C 运行时；MSYS2 提供了 POSIX 兼容环境（包括 pthread、signal 等头文件），常用于在 Windows 上构建需要 POSIX API 的程序。
  • load-path cache：对 Emacs 的 load-path（加载路径）建立缓存，减少启动时目录扫描和文件查找的开销。
  • gccjit：GCC 的 JIT 编译接口，native-comp 用它生成机器码，但只是“纯当编译器用”，没有 trace 或 PGO 优化。

💎 碎片知识与金句拾遗

  • 回一封邮件我花了1个小时左右 —— 群友感叹 Emacs 配置的日常维护成本。
  • 我感觉 modeline 最慢的是 breadcrumb，我自己给所有组件做了异步缓存，modeline 只需要渲染字符串 —— 群友分享优化 mode-line 的经验。
  • κόσμος: 15 秒 native 样本中，redisplay 调用树占 34.8%，但其中 mode-line 路径占 20.2 个百分点；IGC trace/fix 占 39.8%，并与 redisplay 重叠 16.3 个百分点。也就是说当前最有希望的共同来源不是“画字太慢”，而是 redisplay 在重算 mode-line、分配 Lisp 对象，进而触发 IGC 扫描。 —— 这是对 Emacs 性能瓶颈的深度剖析，几乎算是 folklore 已知结论的验证。
  • 或许 modeline 改成异步渲染的就能解决一大问题 —— 提出具体的优化方向。
  • emacs 好多设计感觉都很不 scalable —— 对 Emacs 架构的批判。
  • 当 AI 大人带我学习工业解释器的妙妙优化了 —— 用 LLM 辅助阅读 Emacs C 代码。
  • 你编译 telega-server 的时候会有头文件冲突 —— 关键教训：tdlib 和 telega-server 的构建环境不兼容，需要分开安装。
  • file as database😈 —— 对 org-mode 纯文本数据库设计的吐槽。
  • 我感觉是草台班子的感悟还不够深 —— 自嘲。
  • 国内现在对 windows 的二次开发是不是在变少？Windows 开发现在真的有岗位吗 😂 —— 就业市场的讨论。
  • 唉 monkey patch —— 对 codex-ide 使用过时 json 函数的无奈。

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

  1. eval_sub 拆分的消融测试：zdn 提到“攒起来跑消融测试”，如果持续开发，可以关注其后续 commit，或自行复现（素数求和 + elisp-benchmarks）。
  2. TSF 输入法实现：如果群友成功给 Emacs 加上 TSF 支持，将是 Windows 用户的重要里程碑。即使只写了设计文档也值得关注。
  3. telega 编译问题的 Makefile 修复：群友提到用 -idirafter 替代 -I 即可解决头文件冲突，这是一个可贡献给上游的 patch 方向。
  4. elisp-benchmarks 的改进：多位群友指出其缺陷（默认 byte-compile、GC 干扰、覆盖不全），如果有更好的 benchmark 方案出现会很有价值。
  5. Modeline 异步渲染：κόσμος 提出将 mode-line 渲染与主线程解耦，这是一个潜在的性能优化方向，值得实验。

观点延伸

今天最值得留下的判断是：Emacs 优化的关键，不只是让计算更快，而是决定哪些计算不该发生在用户等待的那一刻。 eval_sub 拆分与 mode-line 缓存，看似分别属于底层和配置层，实际在回答两个不同问题：执行成本能否降低，以及交互路径是否承担了多余工作。

1. 指令变少，不等于优化已经成立

群里的素数测试有提升，测试集却出现退化或接近噪声的结果。这不证明解释器优化没价值，只说明证据尚不足以支持“Emacs 更快了”。

应该区分三层结论：汇编变化解释机制，微基准验证特定路径，交互测试判断用户收益。三者不能互相替代。GC 也不只是需要排除的干扰：研究解释器本身时可以控制它，判断实际收益时却必须把它放回来。

当天已有让 AI 挖优化、跑实验的尝试。进一步说，Agent 最值得自动化的不是批量生成补丁，而是尝试推翻“这个补丁有效”的假设。 固定编译参数，交替运行基线与改动，保留退化用例，分别记录 GC 与总耗时，比一张漂亮的加速图更有价值。

2. “异步”不是答案，退出重绘路径才是

晚间采样把注意力引向 mode-line 重算与对象分配，随后有人分享“组件异步缓存，mode-line 只渲染字符串”。这比笼统地说“redisplay 慢”更接近可操作的边界。

但采样中的调用树重叠，只能提供排查线索，不能直接证明完整因果链。下一步应逐个关闭组件，观察分配量与交互延迟是否同步下降。

缓存也不是免费午餐：何时失效、允许旧多久、后台结果是否已经过期，都需要明确。把重计算塞进空闲定时器，并不自动消除主线程阻塞。真正的设计目标是：显示时只读取便宜的结果，更新可合并、可丢弃，旧结果不能覆盖新状态。

这个原则也适用于个人知识系统：原始笔记负责保存事实，索引和视图负责快速回答；不能每次打开界面，都重新理解整个知识库。

可继续实践：先做一个能判输赢的小实验

不必先追求“覆盖完整”的 benchmark。选定一个真实动作，例如连续移动光标，对比原配置、关闭可疑 mode-line 组件、缓存该组件三种状态；固定缓冲区内容与窗口布局，重复记录按键到显示更新的延迟分布、GC 和分配情况。

验收标准不是平均分变好看，而是长尾停顿减少，同时状态仍能正确更新。若只让启动更快、却把等待推迟到第一次操作，那不是消除了成本，只是换了付款时间。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：Emacs 生态的“文艺复兴”——从视频播放到 AI 集成

群内全天围绕 Emacs 展开了激烈的技术讨论，核心集中在以下几个层面：

  • Emacs 播放视频：群友分享了通过 libmpv + canvas 在 Emacs 内实现视频播放的尝试。讨论焦点包括：画中画模式、多行文本布局、自适应窗口大小、闪烁边框问题等。有群友认为“单线程重绘 canvas 对 Emacs 太残暴”，但也有人惊叹“画中画的感觉太棒了”。相关项目 video.el（https://github.com/0WD0/video.el）和 bili.el（https://github.com/emacs-im/bili.el）被提及，但 video.el 依赖 Emacs 32+ 的 master 分支才能使用。
  • Emacs 启动环境隔离：针对 Windows 用户，群友建议使用 runemacs 启动，以隔离 Windows 环境变量，避免 shell path 问题干扰 telega-server 等外部程序。这一讨论也引申出对 PowerShell 与 Unix shell 兼容性的吐槽。
  • Emacs 配置与生态：有群友提到“图标主题包要上 melpa”，还有人对 denote 的哈希索引功能进行探讨，显示出 Emacs 生态仍在活跃发展。

专题二：AI Agent 的“实战”与“翻车”

群内大量讨论集中在 AI 编程助手（如 Codex、Astra）的实际体验：

  • Codex 效率惊人：有群友称“Codex 5分钟给我搞了个视频播放器”，显示出 AI 编程工具在原型开发上的强大能力。
  • GPT-Astra 的 Computer Use：有群友分享了 GPT-Astra 能实时弹奏 MIDI 钢琴、自主通关《明日方舟》JT8-3 关卡的视频，引发了“AI 玩游戏”的讨论。
  • AI 代码质量问题：也有群友吐槽“astra写的代码怎么一坨😅”，显示出对 AI 生成代码质量的担忧。
  • Spec 驱动开发的反思：有群友提出“模型能力强了之后，spec 驱动开发已经逐渐失去了意义”，并指出如果 spec 是人写的就没什么关系，但像 OpenSpec 这类 AI 生成的 spec 框架可能已不再必要。

专题三：语音输入的革命性体验

这是本日讨论最热烈的实操话题之一，核心痛点在于如何高效、自然地通过语音与 AI 交互：

  • 豆包输入法备受推崇：多位群友力荐豆包输入法的桌面端语音转文字功能，称“用了就回不去了”，“完全都不用修改的”。
  • 本地 ASR 方案探讨：有群友分享用 whisper.cpp 实现本地语音识别，程序+模型仅需 100MB，流畅运行。但效果“不能完全的省心，还需要自己调整”，因此也有人推荐“白嫖 Groq Whisper”。
  • 硬件方案分享：有群友详细分享了自己从大疆领夹麦 → 罗德枪麦 → 小米蓝牙遥控器 2 的语音输入设备演进史。他认为小米遥控器“长条形的铝合金手感很好”，近场麦克风能避免误识别，且支持蜷缩在椅子上用各种姿势语音输入，体验大幅提升。

🔑 关键概念与技术解析

  • runemacs：一个用于启动 Emacs 的 Windows 专用程序，它隔离了 Windows 环境变量，避免 shell path 等系统配置干扰 Emacs 及其外部依赖（如 telega-server）。
  • libmpv + canvas：在 Emacs 内播放视频的技术方案。libmpv 负责解码视频帧，canvas 是 Emacs 32 新引入的画布组件，用于实时渲染视频画面。
  • telega-server：Telegram 的非官方客户端 telega 的配套服务程序，需要正确配置 tdlib 及 PATH 环境变量才能正常工作。
  • Computer Use：指 AI 通过视觉识别屏幕内容并进行交互操作的能力，如 GPT-Astra 能模拟真人操作电脑，完成弹钢琴、玩游戏等任务。
  • OpenSpec / Superpower：AI 驱动的软件规格说明（Spec）框架，旨在用 AI 生成代码开发规范。但群内讨论认为随着模型能力增强，这类框架已逐渐失去意义。

💎 碎片知识与金句拾遗

  • “河北内卷网”（https://hebeineijuan.com）：免费收录河北各区县工厂产业，源头直达，“卷死同行”。群友评价“只要利润比种地高就能干”。
  • “windows当年完全没想过还有一天，不是人用 shell，而是机器用shell”——对 PowerShell 兼容性问题的精辟总结。
  • “我是在 pi 的全局的 agents.md 里面写了优先使用 Powershell 原生命令，成功率高了很多”——一个简单有效的解决 AI 调用 Windows 命令失败的方法。
  • “果蛆也不是很封闭，内核是开源的，只是UI之类的那套东西不开源”——关于苹果开源程度的调侃。
  • “我的图标主题包要上 melpa了”——Emacs 生态持续活跃的例证。
  • “现在主要是脑袋很混沌，嗓子很难受”——群友描述感染病毒后的症状，引发了关于“全球人感染”的调侃。
  • “Linux 就是拯救二手电脑的”——有群友以 2000 元购入二手松下电脑，并计划改装键盘、触摸板，装 Debian 系统。
  • “如果 Let's note 也便宜，又可以裝 linux 的話，我也想搞一個”——对松下笔记本的颜值与可玩性的认可。

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

  • Emacs 视频播放方案：video.el（https://github.com/0WD0/video.el）和 bili.el（https://github.com/emacs-im/bili.el）值得跟踪，代表了 Emacs 在多媒体领域的突破。
  • AI Computer Use 技术：GPT-Astra 的 Computer Use 能力展示了 AI 操控真实软件环境的潜力，可关注相关开源实现。
  • screenpipe（https://github.com/screenpipe/screenpipe）：一个基于屏幕截图的 AI 分析工具，可根据用户操作智能截图，具备 AI 建议、语音交流等功能。
  • openpi-dev/openpi（https://github.com/openpi-dev/openpi）：一个关于 Pi 的配置项目，群友认为“有点意思”。
  • simplify-codebase（https://github.com/tt-a1i/simplify-codebase）：一个用于简化代码库的 AI skill，值得关注。
  • diagram-design（https://github.com/cathrynlavery/diagram-design）：一个面向 drawio 的 skill，可用于生成各种风格的系统设计图。

观点延伸

今天最值得连起来看的，是“模型变强，Spec 框架是否还有必要”和“五分钟做出 Emacs 视频播放器”。我的判断：AI 正在压低实现成本，却没有替人消除产品取舍。代码越容易生成，越该把精力从描述实现步骤，转向定义什么算做对。

1. 可以省掉仪式，不能省掉裁决标准

上午对 Spec 的质疑，随后明确指向 OpenSpec 等框架，并非否定人写需求。这个区别很关键：如果模型生成文档，再按自己生成的文档写代码，两者一致，并不能证明它理解了用户。

晚上的播放器讨论就是现成反例：窗口变化时自动适配，还是保留手动缩放？默认新开窗口，还是留在原处？这不是模型能力不足，而是多个合理目标发生冲突。

有价值的 Spec 不必长，但必须能裁决争议。例如，首次打开自动适配，用户手动缩放后不再覆盖其选择。这是一条待验证的设计方案，不是群内共识；它的价值在于能写成测试，而不是听起来周全。

2. 五分钟证明“能做”，交互压力才检验“可用”

群友说播放器“没觉得卡”，同时明确尚未测试高分辨率视频。后续出现边框闪烁、自适应争议，以及对重绘和 GC 的担忧。不能把担忧当成性能结论，也不能把一次流畅播放当成架构验收。

对 Emacs 而言，关键不只是视频帧率，更是播放时还能不能顺畅打字、滚动和执行命令。一个值得实验的原则是：宁可丢弃过期视频帧，也别让编辑输入排队。需要记录输入延迟、GC 暂停和连续缩放时的表现，再决定取帧与重绘策略。把视频放进编辑器，不应让编辑器退化成播放器的附件。

3. 语音输入也说明：体验不是能力清单

遥控器使用者特意说，效率未必提高多少，改善的是姿势自由和按住即说。这比“支持语音”更接近产品判断：少一次伸手、少一次调整音量，可能比多一个模型选项更重要。

延伸到 Emacs Agent，语音最好用于表达意图，而不是替代每个按键。尤其“转写并润色”与“执行命令”应有清晰边界：说得顺，不等于识别得对，更不等于已经授权修改。

可继续研究／实践

拿播放器做一次小型对照实验：一组只给功能描述，另一组补上窗口行为、输入响应和资源释放的验收条件。使用相同环境与素材，比较首次演示之后的返工次数和人工修复时间。真正该淘汰的，是不能减少返工的文档；真正该保留的，是让错误更早暴露的约束。