Geekinney

外观

Emacs 社区日报 2026-09-05

约 5628 字大约 19 分钟

2026-09-05

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

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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：AI 辅助 Elisp 开发体验的分化

群内围绕 AI 模型在 Emacs Lisp 开发中的表现展开了长线讨论，核心关注点是不同模型在括号平衡、语法修复、长上下文稳定性上的差异。

  • vritser 分享：官网的 deepseek-v4-flash 在 elisp 编写中“没咋碰到数括号情况”，且配合 dsh-emacs 项目自带的 lisp 语法检查脚本，AI 可以快速修复问题，避免陷入“数括号循环”。
  • 部分群友持保留意见：第三方 API 的 deepseek-v4-flash 输出“神一把鬼一把”，怀疑官方存在灰测（模型切换），甚至有“被干成 deeprouter”的调侃。
  • 对 sol（可能是某 AI 模型）的评价极高：“sol debug emacs 配置的能力独一档”“用 sol 可以写上万行的 elisp package 而不出错”。
  • 已确认的已知问题：超长上下文时质量下降，存在代际差异。

专题二：Emacs 多光标（multicursor）之争

从 neovim 支持 multicursor 的消息切入，引发了 Emacs 是否支持、以及“为什么 Emacs 不够流行”的争论。

  • 有人质疑“都说 emacs 很强大，怎么没有 multicursor”，随即被群友反驳：“emacs 十几年前就支持了”（multiple-cursors.el）。
  • 有群友认为 Emacs 生态存在“vim 间谍”，破坏 c-mode、image-mode、windows 等模块的效率与使用体验——显然是一种玩笑式的阴谋论。
  • 更理性的讨论聚焦于 macrursors（新插件）与 multiple-cursors.el 的对比：
    • multiple-cursors.el 存在“多光标复制的内容不会 joji（聚合/合并）起来”的问题。
    • macrursors 的速度太慢，karthink 曾 fork 二开，在 issue 中表示有计划写新的，但后续没有消息。
    • 有人对比了 macro 与 multicursor 的本质区别：multi cursor 每个操作都有实时反馈，且操作完选中不消失；而 macro 操作完选中就消失，需要重新选中。

专题三：Emacs 生态的性能优化与 AI 时代的上游贡献

深夜时段，讨论转向如何用 AI 优化 Emacs 生态包，以及未来优化方向。

  • 有人计划用 AI（如免费额度）优化 multicursor 和 scrollview。
  • 对 magit 的评价两极：有人觉得“依然很卡”，也有人指出按 performance 页面优化后“其实还好”。
  • libgit2 被点名“始终跟不上上游”，是 magit 卡顿的底层痛点之一。
  • 有人更倾向于优化 elisp interpreter / jit，认为 jit 性能已接近 Lua，但仍有“抠的空间”。
  • 共识是：AI 时代应该尽量审查代码后提交上游，而不是 fork 后自娱自乐。

🔑 关键概念与技术解析

  • igc 分支：Emacs 的垃圾回收（immortal garbage collector）相关分支。群内报告 igc3 分支出现 (wrong-type-argument stringp nil) 错误，master 已有修复 4fb098ae，但 igc 快一个月未合并，需手动 cherry-pick。
  • dsh-emacs：vritser 使用的 Emacs 配置/环境，界面实现被称赞“非常好”，内置 lisp 语法检查脚本，与 AI 配合可快速修复括号问题。
  • deepseek-v4-flash：DeepSeek 推出的新模型，群友反馈官网版本在 elisp 编写中括号处理良好，但第三方 API 输出不稳定，疑似官方存在灰测。
  • macrursors：一个较新的 Emacs 多光标插件，支持通过 use-package 配置，可标记所有 lists/symbols/sexps/defuns/numbers/sentences/lines 等，但目前速度偏慢。
  • libgit2：magit 依赖的底层 Git 库，因始终无法跟上上游 Git 的发展，成为 magit 性能的瓶颈之一。

💎 碎片知识与金句拾遗

  • “sol debug emacs 配置的能力独一档”——对 AI 模型的极高评价。
  • “用 max 好几个小时做复杂分析才用了 5%，感觉以前同规模都是 15 往上。”——关于某模型 token 节省的体感数据。
  • “贵了，但不乱读各种无关内容了，所以省 token 了。”——对某模型的务实评价。
  • “如果代码我自己审核过，一般会提交上游；没有审核过的就 fork 然后自娱自乐。”——AI 时代的上游贡献原则。
  • “magit 按 performance 页面优化后其实还好”——magit 卡顿有缓解方案。
  • “为什么不是 emacs 呢。为什么呢，真奇怪。”——对 vim/neovim/helix 流行而 Emacs 不流行的疑惑，引发了对 Emacs 生态的反思。
  • “将 neovim 跑在 neomacs 的 neoterm 里”——调侃性的“终极方案”。
  • 有人提到开发了 App，但“群友都没有体验，体验了也没用反馈”，感叹宣传不够；Google 开发者账号审核很慢。

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

  1. macrursors 插件：作为 multiple-cursors.el 的潜在继任者，其“选中不消失、实时编辑”的特性值得关注。群友已分享完整 use-package 配置，可自行体验。目前已知瓶颈是速度，未来有优化空间。
  2. igc 分支修复：4fb098ae 这个 commit 解决了 igc3 分支的 vc-dir 报错，但 igc 长期未合并 master，值得关注 Emacs 垃圾回收方向的最新进展。
  3. Elisp JIT 优化：群友认为 jit 性能已接近 Lua，但仍有“抠的空间”，可作为深度性能优化的研究方向。
  4. AI 驱动的上游贡献流程：群友提出“审查后提交上游，未审查则 fork 自娱自乐”的工作流，在 AI 生成代码的背景下，这一模式值得推广与验证。

观点延伸

中心判断：今天真正值得咀嚼的不是“哪个模型更会写 Elisp”，也不是“Emacs 到底有没有 multicursor”，而是：Emacs 生态正在被迫把“可塑性”升级成“可验证的工程闭环”。没有闭环，AI 只是高配补全；有闭环，小众生态反而可能比主流生态更快修复长尾问题。

1. 模型差异不是玄学，反馈回路才是分水岭

群里对 deepseek-v4-flash、sol、opus 的评价分化很大：同一个方向上，有人觉得官网版本写 Elisp 不再“数括号”，也有人觉得第三方输出神鬼莫测。这里最重要的线索不是模型名，而是 vritser 提到的 dsh-emacs 内置 Lisp 语法检查脚本。

这说明 AI 写 Elisp 的关键不是“模型是否天生懂括号”，而是有没有即时、低成本、机器可判定的反馈。括号平衡、宏展开错误、byte-compile warning、包内测试，这些东西一旦接进循环，模型能力会被放大；反过来，没有检查器，再强模型也会在长上下文里慢慢漂移。工程判断很简单：以后评价某个模型“会不会写 Elisp”，不能只看一次生成结果，而要看它在语法检查、测试、局部修复、多轮上下文压缩后的稳定性。

2. Emacs 不缺功能，缺的是把旧能力重新产品化

multicursor 争论表面上是“Emacs 有没有”，实际是“有”和“好用”之间的断层。multiple-cursors.el 很早就有，很多人也在用；但复制内容聚合、实时反馈、选区保持、性能这些细节，决定了它在现代编辑体验里是不是还能被拿出来正面比较。macrursors 的出现正好说明问题：需求不是新需求，而是旧能力需要重新工程化。

这也是 Emacs 生态常见病：功能先于体验，能力先于路径。用户问“为什么不是 Emacs”，不一定是在问特性表，而是在问默认体验、性能边界、维护节奏和可发现性。一个插件如果需要用户懂历史、懂替代品、懂配置，才知道它能解决问题，那它在产品层面就已经输了一半。

3. AI 时代的上游贡献，核心是审查权不能外包

“自己审核过就提交上游，没审核过就 fork 自娱自乐”这句话很硬，也很对。AI 可以负责搜索优化点、生成 patch、跑局部实验，但不能替维护者承担语义责任。尤其是 magit、libgit2、Elisp interpreter、JIT 这类位置，性能优化不是把热点代码改短，而是不能破坏几十种边界条件。

可继续实践的方向：选一个小而真实的目标，比如 multiple-cursors.el 或 scrollview 的具体慢路径，建立 benchmark、复现用例、AI 生成候选 patch、人工审查、提交上游。不要先喊“优化 Emacs”，先证明一个闭环能稳定产出可合并的改动。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

本次群聊涉及多个主题，核心讨论集中在几个高频话题上：GPT-6 模型的上线体验与额度消耗、Emacs 生态的最新进展（NeoEmacs/neomacs、video.el、ebox/etaf 框架）、以及 操作系统/终端工具的生态争议。此外还穿插了关于 Agent 编程范式、开源社区文化、硬件选购等话题。

专题一：GPT-6 上线——速度、额度与体验的拉锯战

群内凌晨 4 点发现 GPT-6 上线，随即引发一波体验热潮。讨论集中在以下几个焦点：

  • 速度的“先快后慢”：多位群友反映，凌晨刚放开时速度极快，但随着使用人数增多，白天速度明显下降。有人感叹“美国作息的胜利”，有人调侃“算力不够，用户太多了，互抢并行的线程”。
  • 额度消耗的玄学：有人反映 GPT-6 minimal 做通用任务“又快又准确”，但消耗速度依然“杠杠的”；也有人发现随着缓存命中率提高，token 消耗速度下降。有群友分享配置项 remote_compaction_v2 = true 来解决 compaction 耗时长的问题。
  • 与 5.6 的对比：部分用户反馈 GPT-6 的前端 UI 能力似乎“退化了”，“还不如 5.6”，但也有用户认为在代码生成、语义编辑方面“进展迅速”。

痛点与解决方案：模型速度受限于算力与用户量的动态平衡，额度消耗成为 Pro 用户的核心焦虑。解决方案包括开启 remote compaction、使用更低推理级别（如 minimal/medium）配合“high 设计 + light 执行”的分层策略。

专题二：Emacs 生态的“文艺复兴”——从 ebox/etaf 到 NeoEmacs

群内多位 Emacs 核心玩家展示了近期成果，尤其围绕 ebox/etaf 前端框架 和 NeoEmacs (Rust + GPU + elisp) 展开了热烈讨论。

  • ebox/etaf：由群友 geekinney 开发的 Emacs 专用前端框架，支持盒模型、flex/grid 布局，以及盒模型属性变化时的增量更新。被群友称为“划时代的 Emacs 专用前端框架”，并计划次日发布 ebox（纯视觉展示，无交互）。
  • video.el：另一个群友 0WD0 开发的视频/图像渲染库，利用 slice 将多图拼成一张大图，避免文本换行时图片被截断，并支持左右键切换选中图片。正在接入 Emacs 的 canvas API。
  • NeoEmacs 构建进展：有群友成功在 Linux 上构建 neoemacs，遇到 llvm codegen 慢的问题（开启了 LTO），并分享了 RUSTFLAGS="-C target-cpu=native" 的优化建议。有用户反馈字体缩放因子 font scale 2.0 未生效，以及 buffer 切换动画因重构被暂时破坏。
  • Emacs 与 Agent 的融合：有群友提出“emacs 的 agent 不需要 skill，写在函数名和 docstring 就行”，并分享了通过 monorepo 维护修改 elisp 文件的 agent 库的经验。有人感叹“atomic-change-group”这类底层 API 的存在。

争议与碰撞：群内对 Vim 用户的“布道士”风格表达了强烈不满，尤其是针对“vim 教主韦易笑”在 Emacs 主群中的“阴阳怪气”言论。有人主张“团结一切可以团结的力量”，也有人认为这类人“搞技术的目的是不纯粹的，为了装逼”。

专题三：操作系统、终端与开源生态的批判性讨论

从 Windows 的没落、macOS 的“玻璃特效”，到 Linux 桌面的 Wayland 困境，群友展开了跨平台的大讨论。

  • Windows 的“倒掉”：有人直言“微软在毁 Windows”，“十几年前的 Windows 要比现在优秀太多”。认为 Windows 为了兼容历史包袱而拖垮自己，而 Linux 社区也不给力，Wayland 多年仍未完善，色彩管理至今未正式上线。
  • macOS 的“拉胯”与“封闭”：部分群友吐槽 OS 26 的“玻璃特效”难看，且与 iOS 融合耗费大量精力。但也有人承认苹果的 ARM 处理器仍是“世界性能第一”，公司财报“健康到夸张”——97% 利润返还股东分红，研发投入仅占 3%。
  • 终端工具的“加法”与“减法”：群友批评国内终端/Agent 服务软件“一直在做加法”，“没有人专注终端本身做减法”。国外软件原本“专注于小领域做精，然后大家一起生态配合”，现在也有向国内学的趋势——有人认为是因为 AI 降低了人力成本，导致“廉价劳动力”泛滥。

🔑 关键概念与技术解析

本次聊天中出现了一些晦涩的缩写和特定技术概念，以下是简要解释：

  1. remote_compaction_v2：GPT-6 相关配置项，用于启用远程上下文压缩（compaction），可以显著缩短“compact 要好久”的等待时间。类似特性在 Codex 等 OpenAI 集成工具中也有。
  2. atomic-change-group：Emacs Lisp 中的一种原子变更组机制，用于在一组修改中实现事务性操作——要么全部成功，要么全部回滚。类似数据库事务的概念，在 Emacs 底层编辑中非常有用。
  3. slice（图像切片）：在 video.el 中，将多张图片拼接为一张大图，从而避免文本换行时图片被截断。通过 slice 可以让图片以“连续像素”形式显示，配合左右键切换选中图片、鼠标点击打开对应图片。
  4. canvas API（Emacs）：Emacs 的新接口，用于加速连续像素的显示。与传统的 image-mode 相比，canvas 可以显著提升大图/视频的渲染性能（传统 image-mode 在 19k 图像上 ctrl+滚轮需等待 1 秒以上）。
  5. ebox / etaf：Emacs 专用前端框架，支持盒模型、flex/grid 布局和增量更新。ebox 为纯视觉展示层，etaf 是配套的应用运行时，采用类似 Elm 的模型驱动视图更新。
  6. remote_compaction_v2：已在上面提及，属 GPT-6 相关配置项。
  7. LTO（Link Time Optimization）：链接时优化，在 Rust release 配置中启用 lto = true 可以提升运行时性能，但会显著增加编译时间（尤其是最后一步 llvm codegen）。
  8. RUSTFLAGS="-C target-cpu=native"：Rust 编译时针对本机 CPU 进行优化，可以提升生成代码的执行效率。与 LTO 配合使用效果更佳。
  9. awesome-tray：一个 Emacs mode-line 替代方案，群友推荐用于 NeoEmacs 的 mode-line 显示。

💎 碎片知识与金句拾遗

这里收集了一些不属于上述宏大主题、但非常值得记录的只言片语：

  • “这可比 agent 工具提供的 read 和 edit 好用多了”——群友在 monorepo 中维护修改 elisp 文件的 agent 库时感叹，直接操作 Emacs 底层 API 比 Agent 工具提供的抽象层更高效。
  • “我发现 emacs 的 agent 好像都不需要 skill，写在函数名和 docstring 就行了”——关于 Agent 与 Emacs 结合的重要观察，函数签名和文档本身就是最强的“skill”。
  • “清除 agents.md，上下文窗口设为512k，思考程度为高。天才程序员准备起飞”——一个极具幽默感的“起飞配方”，暗示 Agent 配置的极端化尝试。
  • “美国参议员要求 NSA 发布 VPN 使用指南，明确不同工具能否抵御外国监控”——这则新闻引发群友调侃：“最先进的 vpn 是中国伊朗毛子开发的吗”（笑）。
  • “旧松下 Let's Note 笔电……看上去憨憨的，但用起来意外地手感好”——有群友分享 Let's Note 的使用体验：比 MacBook Air 厚很多，但重量接近，接口齐全，键盘手感好，屏幕素质高。是日本政府标配电脑。
  • “拆墙装修的时候记得自己一个人拆，万一拆出钱了，不用见者有份”——群友在讨论买房时的一句玩笑，但也透露出对“法拍房”的微妙态度。
  • “cook 今年卸任，用 ai 通读代码发力了一下”——群友调侃 macOS 的变化，认为“MacOS 也要阿三化了吗”。有人回应“没有，OS 26 之拉胯，难以言说”。
  • “我觉得不是他们能正常交流的人类”——针对 Vim“布道士”的评论，强调开源社区应聚焦设计哲学而非互相对比。
  • “你记住这句话：有些人搞技术的目的是不纯粹的——装逼”——群友对“技术优越感”的直白总结，建议在任何渠道发布。
  • “2026年 19k 图像 ctrl+滚轮 1秒以后才响应”——关于 Emacs image-mode 性能瓶颈的具体吐槽，引出 video.el 和 canvas API 的讨论。
  • “现在 gpt 也喜欢这么配色的，难说”——关于某个新工具 Squad 的配色风格（Claude 配色），暗示 AI 工具的审美趋同。
  • “群友的token都好多的样子，我在考虑我要不要也升级一个月蹬一下”——表达了普通用户对 Pro 用户额度的羡慕，也反映了订阅模式的普遍焦虑。
  • “我最近把 token 给停了，准备出远门了就不能写代码了”——一种自律的“数字 detox”，也侧面说明 token 消耗与生活节奏的关联。
  • “cargo xtask fresh-build --release”——NeoEmacs 的构建命令，群友分享的构建流程。
  • “master 上有修复，但是还没合并过来，gpt 建议：git cherry-pick 4fb098ae3fa1ffa721214555b149d94caecc8d0c”——展示了用 GPT 辅助处理开源项目 bug 的典型工作流。
  • “我期待赛博菩萨变成恶龙”——对苹果从“创新先锋”到“服务巨头”的观察，既有赞赏也有担忧。

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

以下内容具有前瞻性或极具潜力，可作为技术雷达进一步研究：

  1. ebox/etaf（群友 geekinney 即将发布）——Emacs 专用前端框架，支持盒模型/flex/grid 布局和增量更新。这可能是 Emacs 在 GUI 渲染领域的一次重要尝试，值得关注其发布后的生态发展。
  2. video.el + canvas API——利用 slice 和 canvas 接口解决 Emacs 大图/视频渲染卡顿问题。群友计划将 image-mode 迁移到 canvas，如果成功，将显著提升 Emacs 的媒体处理能力。
  3. NeoEmacs（Rust + GPU + elisp）——这是一个用 Rust 重写 Emacs 的项目，支持 GPU 加速渲染。群友已在 Linux 上成功构建并运行，未来可能成为 Emacs 性能突破的关键方向。关注其 LTO + target-cpu=native 优化配置。
  4. GPT-6 的“high 设计 + light 执行”分层策略——有群友提出用 high 级别做设计、light 级别跑实现的模式，将额度消耗控制在 20% 以内。这是一个值得复用的 Agent 配置策略，适用于大型项目。
  5. remote_compaction_v2 配置项——对 GPT-6/Codex 用户来说，这是一个关键的性能优化开关，值得进一步验证其在长上下文场景下的效果。
  6. monorepo 维护 Agent 库——群友分享了通过 monorepo 管理修改 elisp 文件的 Agent 库的经验，这可能是未来 Agent 编程范式的一个重要方向。

观点延伸

今天最值得咀嚼的不是“新模型多快”，而是一个更硬的判断：Agent 真正能放大的，不是 prompt，而是宿主系统已经暴露出来的可操作结构。Emacs 之所以在这轮讨论里显得有后劲，恰恰因为它把编辑器内部对象、事务、函数文档、显示管线都摊在用户面前；AI 只是把这些旧能力重新点亮。

1. docstring 比 skill 更接近工程接口

“Emacs 的 agent 好像都不需要 skill，写在函数名和 docstring 就行了”这句话很尖。它不是说 skill 没用，而是说如果系统本身的 API 命名、参数、docstring、错误语义足够清楚，Agent 不需要额外读一堆外部说明书。atomic-change-group 这类机制尤其说明问题：AI 编辑代码最怕的不是写不出来，而是半写坏、不可回滚、无法界定修改边界。

所以可验证的工程判断是：面向 Agent 的系统，第一优先级不是“接入更强模型”，而是把操作面做成可发现、可组合、可回滚的接口。函数名、docstring、事务边界、差异检查、错误不吞，这些比宏大的 Agent 框架更可靠。今天群里提到 video--event-window 一类函数里用 condition-case 吞错，其实正好是反例：对人也许只是少报一个异常，对 Agent 就是切断反馈回路。

2. Emacs 前端问题，本质是文本结构不够用了

ewoc 更新 node 会整体重写，窗口宽度变化可能影响嵌入式视频进度；多图显示要靠 slice 拼成连续图像；image-mode 在大图缩放时卡到秒级。这些表面看是 Emacs 显示性能问题，底层其实是同一个矛盾：当 buffer 既要承载文本，又要承载状态化 UI，对象生命周期就不能再只靠“重画一段文本”解决。

ebox/etaf、video.el、canvas API 的价值不在于“把 Emacs 做得像浏览器”，而在于给 Emacs 补一层可局部更新、可保持状态、可计算布局的中间表示。DOM 不是网页专利，它是一种工程约束：状态在哪里，渲染边界在哪里，变化如何传播，哪些东西不该被重建。

可继续实践的方向很明确：先别急着做大而全的 Emacs GUI 框架，先做一个最小可验证样例：同一 buffer 中嵌入图片或视频，调整窗口宽度时布局可重算，但媒体对象不重建、播放进度不丢、错误可见、更新范围可测。这个样例跑通，比争论“Emacs 是否该浏览器化”更有价值。