Geekinney

外观

Emacs 社区日报 2026-09-06

约 4846 字大约 16 分钟

2026-09-06

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

Emacs 社区日报 2026-09-06 手绘图
Emacs 社区日报 2026-09-06 手绘图

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：Emacs 解释器性能优化——从 eval_sub 到编译器

本日讨论的绝对焦点是 Emacs Lisp 解释器的性能优化。群友 astra 分享了一个具体优化：将 eval_sub 函数中对简单情况的 early return 路径拆分成独立的 helper 子函数。其核心逻辑是：eval_sub 本身非常复杂，每次进入时编译器需要保存大量寄存器；而早期返回路径其实不需要这些完整栈帧和局部变量空间。通过函数拆分，可以大幅减少寄存器保存开销。

  • 基准测试：使用埃氏筛法（100 万以内求素数），baseline 为 280ms，优化后加速 1.113×。
  • 讨论焦点：群友认为此思路合理，但强调需要更好的 benchmark 和真实场景测试。并延伸出对 Elisp 编译器本身的批评——advice 机制"太巨魔"，从编译器角度看难以做更多优化。
  • 后续动作：有人建议建立专门的"Emacs 源码优化"讨论群，甚至考虑用 AI 辅助熟悉代码库、寻找优化机会。一个冷幽默是"直接梦到高频调用函数太大可能会影响性能"。

专题二：video.el 与 Canvas 渲染——Emacs 媒体能力的边界

围绕 video.el（一个 Emacs 视频播放器）展开了深入的技术讨论。开发者 0WD0 分享了一个新分支 jjosh/appkit-vnext，并提出了一个关键设想：将渲染函数抽出来，用 Canvas 实现 image-canvas-mode，以替代内置 image-mode（其性能不佳）。

  • 技术路线：目前 video.el 通过动态模块（C 语言）与后端通信，支持跳转时间等操作。但开发者倾向于走 IO 通信接入 ffmpeg，避免动态模块。
  • 性能疑问：群友追问"Canvas 显示图片是否会影响滚动性能"，开发者回复"我这里是不会感到不正常的卡顿"，并指出动态模块加速可能是关键差异。
  • 设计洞察：播放视频时按 F 键隐藏所有 UI，形成一个独立的 frame，看起来和 mpv 几乎没有区别。inline-play 功能可内嵌播放 GIF，不影响页面滚动，被认为"这才是强大的地方"。
  • 上游贡献：有人建议将动态模块代码作为参考提交给 Emacs 上游，作为"纯 vibe"参考代码，由开发组重写后集成。

专题三：配置管理哲学——Monorepo vs 独立模块

关于 Emacs 配置的组织方式，群友展开了架构级讨论。核心矛盾：是采用 Monorepo 统一管理，还是将独立功能拆成模块单独发布？

  • 主流观点：Monorepo 的最大优势是版本管理——一个 commit 能同时关联多个相关项目，无需处理版本兼容问题，回滚也方便。Rust 官方采用"Monorepo + 独立模块 + bot 自动合并"的模式（如 rust-analyzer 在 src/tools/ 下），是成功案例。
  • 个人实践：有人表示已将十几个项目放进 Monorepo，并计划将独立模块拆出后写 Makefile 方便用户安装。也有人使用 jj 的 change id 来弥补不同仓库间 commit ID 不一致的问题。
  • 灵魂金句："配置得自己写才高雅"——有人承认自己的配置是 AI 生成的，但已经逐渐脱离 doom 开始攒自己的配置，因为"doom 有多疯狂，拿 rg 搜索一下 HACK 关键字就知道了"。

🔑 关键概念与技术解析

  • eval_sub：Emacs Lisp 解释器中负责表达式求值的核心函数。由于函数体庞大，每次进入时编译器需保存大量寄存器，这成为性能瓶颈。优化方式是将 early return 路径拆成 helper 函数，减少不必要的寄存器保存。
  • advice 机制：Emacs 中用于修改函数行为的机制（类似 AOP 切面），群友认为它给编译器优化带来了很大阻碍，因为运行时函数可以被任意包装。
  • plz：Emacs 中的 HTTP 客户端库，群友计划将其替换掉以支持连接复用（HTTP/2），因为"emacs 不支持 http/2"。
  • composer（telega）：Telega（Telegram 客户端）中新增的组件，用于组合底部可显示的行，重构 input area 后减少了流式插入时的底部抖动。
  • jj change id：jj（Jujutsu）版本控制工具中的概念，用于在不同仓库间追踪同一变更的 identity，弥补多个仓库 commit ID 不一致的问题。
  • inline-play：video.el 提供的功能，允许在 buffer 内嵌播放 GIF/视频，且不影响滚动性能。

💎 碎片知识与金句拾遗

  • nelisp benchmark：群友推荐了 nelisp 项目（一个用 Rust 实现的 Emacs Lisp 解释器），它带有 benchmark 集合，可用于解释器优化测试。一位群友说"nelisp 挺好的，其实我通过它实现了一个类似 org-capture 的 app"，但后来发现"脚本 + raycast 快捷键调出更方便，就没发布了"。
  • AI 与开源贡献："用 LLM 发现优化机会应该是合法的吧"，随后有人反问"为什么不合法？"，并透露"我现在的配置都还是 AI 搞得，然后让它用 org 来把代码切细一些给我看"。
  • 技术幽默：提到"什么费马猜想（"和"然后飞机出事"，暗示某个技术挑战像数学猜想一样困难；"纯 vibe"成为本期流行词，指"完全没有实据、纯粹凭感觉"。
  • Emacs 视频生态：群友发布了 B 站视频广告（BV1SUbW6ZEBC），并吐槽"tg 竟然没有做 bilibili 的支持"；还有人分享了 neo-emacs 配置（https://github.com/sincebyte/neo-emacs），被调侃"在 neomacs 里用 neo emacs"。
  • .clangd 和 .clang-format：有群友认为 Emacs 源码库中这两个文件存在问题，需要报告给上游。
  • 日常琐碎："给 emacs 发邮件好费脑子"，"我今天点击了大概 100 多次微软的文档"。
  • 基础配置心态："（如果是个人项目）拆出去也不会有几个 PR"，"但是折腾这些东西挺有意思的，也算是基础设施"。

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

  1. eval_sub 函数拆分优化：核心思路值得推广到其他大型热路径函数（如 Fcar、Fcdr 的内联），建议用 elisp-benchmark（O3 编译选项）和真实场景进一步验证。
  2. video.el 的 jjosh/appkit-vnext 分支：该分支重构了渲染层，抽出了渲染函数，有望独立出 Canvas 渲染模块，取代内置 image-mode。关注其 inline-play 和隐藏 UI 的全屏播放设计。
  3. nelisp 项目：作为一个 Rust 实现的 Emacs Lisp 解释器，不仅提供了 benchmark，还成功跑出了 org-capture 应用，值得研究其解释器设计。
  4. telega 的 composer 重构：虽然解决了大部分抖动，但"测试了更多场景发现还是有部分轻微抖动"，说明底层的渲染调度仍有优化空间，可能与 Emacs 的 redisplay 机制相关。
  5. Monorepo + 独立模块的自动化同步：Rust 的做法（bot 自动合并）值得借鉴，尤其是如何处理"独立模块能力超出上层所需"的问题。

观点延伸

今天最值得咀嚼的不是“Emacs 又快了 10%”或者“Emacs 也能放视频”，而是同一个判断：Emacs 的下一层竞争力，不在配置花样，而在运行时边界能不能被重新工程化。

1. eval_sub 的优化价值，不是 1.113 倍，而是把玄学变成可审计假设

把 eval_sub 的 early return 路径拆到 helper，绕开复杂函数入口处的寄存器保存和完整栈帧开销，这个思路很“底层”，但并不神秘。它的可贵之处在于能被验证：baseline 280ms、埃氏筛 1.113 倍，只是第一层证据；真正要成立，还需要 elisp-benchmark、O3 构建、真实包加载、交互命令、GC 压力下的对照。

这里的工程判断很明确：Emacs 解释器优化不能靠“梦到热函数太大”，但可以从这种梦开始，落到 perf、汇编、调用频率和真实 workload。反过来，advice 被吐槽“太巨魔”也不是情绪问题，而是动态扩展能力对编译器假设的破坏。一个系统允许运行时任意改写行为，就很难要求编译器像静态语言那样大胆内联、消除分支、缓存调用关系。自由不是免费的，它的成本会出现在优化器的保守性里。

2. video.el 的关键不在“像 mpv”，而在“不打断 buffer”

单独 frame、按 F 隐藏 UI，做到“看不出是 Emacs 窗口”，这当然有趣，但它更像把 Emacs 包成播放器。真正有张力的是 inline-play：GIF 或视频嵌在 buffer 里，还不明显拖慢滚动。因为这触碰的是 Emacs 的核心契约：文本、结构、媒体、交互能不能共处在同一个编辑表面。

所以 Canvas、动态模块、IO 接 ffmpeg 的路线之争，本质不是实现偏好，而是边界选择：动态模块可能带来性能和低延迟，但也增加分发、崩溃隔离和上游接受成本；IO 方案更可移植，却要证明吞吐、同步、seek、redisplay 抖动都能扛住。能播放不是结论，滚动不卡、输入不抖、mode-line 不乱，才是编辑器语境下的结论。

可继续研究/实践

最值得做一个小型“Emacs 运行时实验台”：一边收集 eval_sub、Fcar、Fcdr 这类热路径优化在真实配置中的收益；一边用同一套滚动、redisplay、输入延迟基准测试 image-mode、Canvas、video.el inline 渲染。少争路线，多产出可复现数据。Emacs 社区真正缺的不是想法，而是把想法压成 benchmark、补丁和上游能理解的工程证据。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：Neomacs/Emacs 的 Canvas 渲染与 Media 模式演进

群内多位开发者围绕 neomacs（一个基于 Emacs 的现代编辑器）的 Canvas 渲染、媒体播放（video.el/media-mode）以及字体显示等实际问题展开了激烈讨论。

  • Canvas 渲染的困境：有成员表达了对 image-mode 切换到 canvas 渲染的复杂性的不满（“失败 image-mode想间谍换成canvas渲染还是太麻烦了”），随后一位成员宣布“已经换好了”，并分享配置，引发了后续调试。核心痛点集中在字体缩放不一致——默认缩放字体大小不一致、分隔线颜色不同、窗口 divider 消失，以及 emacs 本身支持透明背景而 neomacs 尚不支持。
  • video.el 的重新设计：有成员提出“video.el 播放视频时是否有声音”，随即引发关于媒体能力的讨论。有人调侃“你不是 video.el 你是 media.el”，因为该模块实际支持视频、音频和图片。随后有人提出新的设计思路：全屏可通过打开独立 frame 并使其全屏来实现，而非依赖单一 buffer 渲染。
  • 动态模块导致崩溃：多次出现“又崩一次”“我的 emacs 因为这东西这几天崩太多次了”，以及“动态模块风险比较大”的反思。最终有人报告“疑似修好了”，并有人提交了 GitHub issue（#350）用于追踪字体/渲染问题。

结论：社区正在积极探索 Emacs 的 Canvas/Media 能力边界，但动态模块的稳定性与渲染一致性仍是突出痛点。

专题二：AI Agent 编排工具的“实用性”之争

围绕 yc-software/qm、multica、herdr、get-bb 等异构 Agent 编排工具，成员展开了深度批判性讨论。

  • 核心观点是 qm 没有做统一包装（Unified Wrapper），而是走“极致实用主义”路线——将所有上下文直接丢进 Prompt（被称为“Context Lake”），不进行规范化。
  • 有成员分享了自己围绕 multica 构建专用 hermes（含状态机 dirge 包装） 的尝试，发现工作量过大，“还不如写一个跨平台自己的 app”。
  • 对 get-bb 的评价是“编排原语比 lody/orca 多，甚至比 herdr 还多”，但 env 透传不支持，因此决定不提交 issue。
  • 对 herdr 的批判集中在：编排 skill 写得不好，应该告诉 agent 用 send-key 传递消息，而不是像监视 subagent 一样读取 worker 终端。
  • 对 Astra 的评价：“非常会 jj”（疑似指代码审查/生成能力），且多位成员感知“astra 变快了”。

结论：开发者对当前 Agent 编排工具的一致性、透传能力和状态管理普遍不满，认为“编排的本质问题在 runtime 层面，而非原语数量”。

🔑 关键概念与技术解析

  • Canvas 渲染（Emacs Canvas Mode）：Emacs 原生支持的一种新型渲染方式，可以在 buffer 内嵌入图形界面元素（如视频、图片、自定义绘制），无需依赖外部终端模拟。讨论中涉及 image-canvas-mode 的配置与字体缩放问题。
  • Crystal 的 --release 标志：等价于 -O3 --single-module，用于高性能编译优化。群内用它类比 neomacs 的某种编译/渲染模式。
  • Context Lake：指一种设计模式——将所有上下文数据不加规范地全部丢入 Prompt 供模型处理，避免了中间层编码，但缺乏结构化。
  • TTY 透传与 tmux 层：在 Agent 编排工具中，传递终端 ID（TTY ID）和 tmux 层，以确保子进程能获得正确的终端环境。讨论中指出部分工具未支持 env 透传。
  • jj workspace 与 worktree 兼容：jj（Jujutsu）版本控制的 worktree 兼容终于实现，使得 magit 可以在 jj workspace 中使用。

💎 碎片知识与金句拾遗

  • “编程的尽头是玄学 😃” — 面对 telega-server 在 Windows Emacs 31.1 release 版本无法使用的问题，作者苦寻无果后的感慨。
  • “重置卡感觉额度是缩水的 很不耐用” — 对 AI 订阅额度的抱怨。
  • “真正的高手都是将Token用到刀刃上，不会用的人只能大水漫灌。” — 关于 AI 使用策略的观点，反驳“额度不够”的说法。
  • “200 美元经常用不完…” — “给我，我拿来扫 emacs 源码” — 调侃高级订阅额度的用途。
  • “debug.emacs 成功” — 首次使用 gnus 发邮件到 debug.emacs，引起小范围共鸣。
  • “冷知识” — 突然抛出一个话题，但未展开。
  • “我想你应该去这方面查一下：emacs31 还不支持 org-mode 呢，后面是配置问题，还有 eln-cache 的问题” — 针对 telega-server 兼容性的排查建议。
  • “这个形容非常贴切” — 对“astra 非常会 jj”的评价表示认同。
  • “第一次用gnus发邮件给debug.emacs成功了” — 对邮件客户端配置的小成就分享。
  • “有声音吗？” “有的，支持视频，支持音频，支持图片” — 确认 media.el 的多媒体能力。
  • “分4个文件1个core…media-video-mode继承这2个mode” — 代码组织建议，但回应是“不太有必要”。

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

  • Hermes 自进化插件生态：社区已涌现多个方向的项目（super-hermes、hermes-dojo、hermes-workspace、hermes-plugins、colleague-skill），实现 Agent 自我提示词生成、性能监测、Web 界面整合、跨 Agent 通信等能力。值得关注“谁先把这套体系跑通”。
  • neomacs 的 Canvas/Media 模式：有成员提出用独立 frame 实现全屏的新设计，且 neomacs 尚不支持透明背景（而 emacs 原生支持）。这是一个潜在开发方向。
  • get-bb / herdr / qm 的编排对比：讨论中多次提及这些工具的原语数量、env 透传、TTY 传递等差异，但尚未有人做系统性对比测试。若深入评估，可产出有价值的评测报告。
  • Crystal 的 --release 标志与 neomacs 的渲染优化：群内类比提及，暗示可能存在相似的编译/渲染路径，值得深入对比。
  • Astra 的“jj”能力：有成员称赞其代码审查/生成能力，但未展开细节，若作为效率工具进一步调研，可能对开发者有启发。

今日有效讨论主要集中在 neomacs/Emacs 渲染问题与 AI Agent 编排工具两个专题。其他话题多为零散吐槽或资源分享，已尽量保留有价值细节。

观点延伸

中心判断：这天最值得咀嚼的不是“Emacs 多媒体变强了”或“哪个 Agent 编排工具更好”，而是同一个工程事实：一旦系统跨过编辑器、终端、模型、窗口系统和外部进程的边界，真正决定可用性的不是功能列表，而是 runtime contract。没有稳定边界，原语越多，崩得越隐蔽。

1. Canvas/Media 的问题不是“能不能渲染”，而是“谁对显示一致性负责”

neomacs 里 image-mode 切到 canvas、video.el 扩成 media.el，本身方向没错：Emacs 不该永远停在文本和外部播放器之间。但当天暴露的症状很典型：字体 scale 不生效、图标和标题栏比例不一致、divider 消失、透明背景缺失、动态模块反复崩。工程判断是：这不是单个 bug，而是渲染责任分层还没固定。

如果 canvas 只是“能画出来”，那 demo 很快；如果要成为日常编辑器能力，它必须回答：字体度量从哪里来，DPI/scale 谁统一，frame/window/buffer 三层如何继承主题，动态模块崩溃是否能隔离。用独立 frame 做全屏是个好思路，因为它承认“视频播放”不必硬塞回普通 buffer 生命周期；这是把交互边界重新划清，而不是在一个 buffer 里模拟整个窗口系统。

2. Agent 编排的痛点也不是“原语不够”，而是“边界不可检验”

群里对 qm、multica、get-bb、herdr 的批判，核心不是谁功能少，而是谁把责任推给模型。Context Lake 看似省掉统一包装，实则把协议、状态、权限、环境变量、终端语义都混成 prompt。get-bb 有更多编排原语，但 env 透传不支持；herdr 至少传了 TTY ID 和 tmux 层，却又让 skill 鼓励模型读 worker 终端，而不是用 send-key 做明确通信。这些细节很小，但决定了系统能不能被测试。

可验证的判断很简单：一个 Agent runtime 是否成熟，不看它能启动几个 worker，而看三件事：环境是否可复现，消息边界是否显式，失败状态是否能被机器判定。否则“编排”只是把不可控过程摆成看板。

可继续实践的方向

做一份小型对照测试：一边测 neomacs media/canvas 在 DPI、主题、崩溃隔离、全屏 frame 下的行为；一边测 Agent 工具在 env 透传、TTY 继承、send-key 通信、异常回收上的一致性。结论大概率会指向同一条原则：不要先追求更聪明的上层体验，先把 runtime 的契约写成能失败、能复现、能回归的测试。