Geekinney

外观

Emacs 社区日报 2026-09-19

约 3299 字大约 11 分钟

2026-09-19

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

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

Emacs 中文讨论组

🎯 核心热点与专题探讨

Emacs 在 Windows 下外部进程调用的性能瓶颈 群内围绕 Emacs 调用 git 等外部程序时的高开销展开深入讨论。核心问题集中在 Windows 环境下 shell-command 的调用流程：

  • 即使通过 (setq exec-suffixes '("" ".exe" ".bat" ".cmd")) 优化后缀查询顺序，Emacs 仍会稳定触发 3 次 QueryOpen 调用，无法绕过。
  • 完整调用代价为：创建进程 + 3 次 QueryOpen + 一次打开 + 执行。普通 cmd 则无此额外查询。
  • 有成员用 AI 扫描代码后指出这是 Emacs 的“兼容性包袱”所致——启动前需进行路径转换、判断可执行性、符号链接类型等，代码耦合度极高。
  • 有人提议做缓存优化，但需要 GPT/Claude 协助分析庞大源码，群友甚至以 20 USDT 赞助鼓励“天才程序员回归撬动上世纪神秘代码”。
  • 最终计划邮件联系维护者确认进程开销问题。

🔑 关键概念与技术解析

  • QueryOpen：Windows NT 内核中用于检查文件属性的系统调用。Emacs 在每次进程启动时重复调用 3 次，导致额外 I/O 开销，普通 cmd 不触发。
  • exec-suffixes：Emacs 变量，控制 exec-path 中可执行文件的候选后缀。尝试设置为 ("" ".exe" ".bat" ".cmd") 可减少后缀轮询，但无法消除底层 QueryOpen 重复调用。
  • Clojure + Minecraft：Clojure 运行于 JVM，可通过 REPL 直接操作 Minecraft 对象，与 Kotlin 类似，均能开发 Mod。

💎 碎片知识与金句拾遗

  • “这就是调用一次 git 的代价” —— 指完整进程创建 + 3 次查询的固有开销，在 Windows 上无法通过配置层面消除。
  • “子进程启动成本主要还是 createprocess 吧，怎么改都快不起来可能” —— 暗示 CreateProcess 本身是瓶颈，非查询次数。
  • “想优化也可以做，搞搞缓存什么的也可以，不过太麻烦了，我需要一个 gpt 或者 claude 帮我分析一下” —— 表达对 AI 辅助逆向老代码的渴望。
  • “这种场景不能弄个 cache 吗，每次都猜好傻逼” —— 对 Emacs 缺乏文件属性缓存的直接吐槽。
  • 群内有人以 20 USDT 赞助支持改进 Windows 体验，体现开源社区的现实激励模式。

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

  • Emacs 进程调用源码优化：若未来有人联系维护者获得解释，可进一步探索 callproc.c 和 process.c 的实现细节，考虑引入文件属性缓存或延迟符号链接判断。
  • Clojure 的 Minecraft Mod 开发：鉴于 Clojure 可直接操作 MC 对象，可调研 clojure-minecraft 相关生态，作为 JVM 语言跨领域应用的潜力案例。

观点延伸

当天讨论真正值得咀嚼的，不是“Emacs 在 Windows 上慢”这个结论，而是一个更具体的工程判断：当兼容性逻辑、路径探测和进程启动被揉进同一条调用链时，局部配置优化只能削掉表面成本，无法改变系统的结构性开销。exec-suffixes 可以减少候选后缀带来的查询次数，却无法消除找到目标之后仍然发生的多次 QueryOpen。这说明“少猜几个后缀”和“重新设计进程启动路径”根本不是一个层级的问题。

1. 先把成本拆开，再讨论优化

群里对 CreateProcess 和 QueryOpen 的争论很关键：前者可能是不可避免的启动成本，后者则更像 Emacs 为了兼容不同文件形态而付出的额外成本。如果没有分别测量路径搜索、文件属性判断、进程创建和真正执行所占的时间，直接提出缓存方案，很容易把优化目标搞错。尤其是一次 git --version 的微基准，不能自动代表长时间运行的交互场景；但它足以揭示调用链中是否存在稳定、重复、可疑的系统调用。

因此，第一步不是“把缓存加上”，而是建立可复现的基准：固定命令、固定路径、比较不同后缀配置，并记录冷启动与热启动差异。只有确认重复查询占据了值得优化的比例，缓存才有工程意义。

2. 缓存不是免费午餐，兼容性代码最怕失效判断

“每次都猜”确实愚蠢，但“永远相信上次猜对”同样危险。可执行文件可能被替换，路径可能变化，符号链接和文件类型也可能改变。若缓存只记住“某个命令对应某个后缀”，风险相对可控；若缓存连文件存在性、可执行性和解析结果都长期复用，就必须处理失效、并发和跨平台语义。更现实的方案可能不是全局缓存，而是缩小探测范围、延迟低概率判断，或让明确路径直接走一条不经过完整兼容性探测的快速路径。

这也是老代码优化最难的地方：性能问题通常不是某一行多调用了一次 API，而是历史上积累的安全检查彼此纠缠。删掉一个判断可能让常见路径变快，也可能破坏某个没人再记得的边界条件。

3. AI 适合考古，不适合替工程师下注

群里提到让 GPT 或 Claude 扫描源码，这个方向有价值，但 AI 最适合做调用链梳理、条件分支归纳和候选实验设计，不能替代系统调用追踪与回归测试。面对耦合很高的 process 相关代码，可靠流程应是：先让 AI 标出路径，再用最小实验验证每个假设，最后只提交能被基准和测试支持的改动。AI 可以降低理解旧代码的门槛，却不能凭“看起来合理”证明缓存不会制造兼容性回归。

可继续研究的方向，是围绕 Windows 进程启动建立一组最小基准和追踪样例：比较 shell-command、直接进程调用与普通 cmd 的系统调用序列，确认真正值得优化的阶段，再评估“快速路径”或窄范围缓存，而不是一开始就重写整套兼容性逻辑。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

Neomacs 的日常使用与生态进展

今日讨论围绕 neomacs 展开，核心话题包括其日常可用性、bug 复现以及社区发展。多位群友尝试在日常环境中使用 neomacs，并在 telega 中复现了光标显示 bug，且反馈字体显示过细的问题。此外，有成员在 macOS 上尝试运行 neomacs 时遇到 doom-after-init-hook 错误，怀疑与 doom-modules 读取有关。值得注意的是，neomacs 作者 eval_exec 受邀参加 EmacsConf 并发表演讲，引发群友对其英语口语能力及演讲准备的讨论，甚至有建议使用 AI 生成演讲稿并由人翻页。此外，群友也提及了 neomacs 的 Windows 支持状况，目前虽可编译但未经测试。

🔑 关键概念与技术解析

  • Neomacs：一个基于 Rust 和 GPU 加速的 Emacs 替代实现，支持 Elisp 语言。它旨在提供更现代的渲染和交互体验，但当前仍处于早期阶段，存在诸多兼容性和稳定性问题。
  • Doom Emacs：一个社区维护的 Emacs 配置框架，提供丰富的预配置模块。本次讨论中，用户在 neomacs 下运行 Doom 配置时出现错误，反映出 neomacs 对现有 Emacs 生态的兼容性尚不完善。
  • D2：一种现代图表描述语言，被群友认为比 Mermaid 更简单易用，尤其适合文本生成图表场景。

💎 碎片知识与金句拾遗

  • Pimax Crystal Super VR 设备：群友分享了使用体验，认为其“最不支持 Linux”，但用户沉没成本过高。推荐购买时需谨慎，尤其是对 Linux 用户。
  • VR 显示 bug 排查经验：一位用户花费一天时间调试 VR 显示问题，最终发现将主显示器刷新率从 240Hz 降至 60Hz 即可解决，并指出该问题源于 2019 年修复过的显卡驱动 bug 回归。
  • GitHub 新增防护设置：有群友发现 GitHub 现在支持某种防护设置，推测是为了防范 AI bot 的抓取行为。
  • 游戏与 AI 辅助：有群友感叹“电子阳痿”，并表示缺一个一起玩游戏的人；另一群友分享在玩节奏天国多人模式，体验有趣。
  • Mac mini 与 VR 组合：有群友设想购买 Mac mini 搭配 VR 眼镜使用，但被提醒仍需高性能显卡支持。
  • 本地 AI 联想输入法：群友询问 Windows 下支持本地 AI 联想的输入法，有人推荐了“轻剑”输入法。

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

  • Neomacs 的 Windows 支持：目前虽可编译但未测试，未来可能成为跨平台 Emacs 替代方案的重要方向。
  • simpc++-mode：群友计划将 simpc-mode 升级为 simpc++-mode 并发布到 maple，以提升 C/C++ 编辑速度，值得关注其后续进展。
  • CUDA 推理在手势追踪中的应用：有群友打算在手势追踪项目中使用 CUDA 推理，这可能是 VR 交互领域的前沿探索。
  • AI 生成的演讲辅助：群友建议用 AI 生成演讲稿并由人翻页，这种“AI 辅助演讲”模式或将成为技术会议的新趋势。

观点延伸

当天最值得咀嚼的，不是“neomacs 能不能日用”，而是一个更硬的问题：当新实现试图接入成熟生态时，真正的产品边界究竟由什么决定？从 telega 中可复现的光标显示问题、字体过细，到 Doom 初始化阶段出现 doom-modules 缺失，再到 Windows “能编译但从未测试”，这些并不是零散的小 bug，而是在提醒：兼容性不是“能启动 Elisp”这么简单，而是要覆盖渲染、窗口、字体、异步交互、配置加载和生态约定的一整套行为契约。

1. “可日用”必须从口号变成测试矩阵

neomacs 已经能让用户开始尝试，这是项目从演示走向真实使用的重要一步。但真实用户会把 telega、Doom、复杂字体配置和跨平台环境一起带进来。只验证核心编辑功能，无法证明它具备日用能力。更可靠的判断方式，是建立按场景划分的兼容性矩阵：启动配置、文本渲染、光标与窗口、包管理、终端交互、邮件聊天客户端，再分别记录 Linux、macOS、Windows 的通过状态。

这也解释了为什么“能编译”远远弱于“有人持续使用”。前者证明构建链路存在，后者才开始暴露系统边界。

2. AI 可以降低表达成本，但不能替代责任主体

群里关于 EmacsConf 的讨论很有张力：有人建议用 AI 准备演讲稿，人只负责翻页。这种模式确实能降低英语口语和演讲准备的门槛，但它只解决了表达层，不解决理解层。一个技术项目能否讲清楚，取决于作者是否知道哪些兼容性问题尚未解决、哪些平台只是理论支持、哪些设计取舍值得解释。

因此，AI 最适合承担“提纲整理、术语润色、演练问答和讲稿压缩”，而不是替人构造项目叙事。越是早期、越是有争议的项目，越需要作者亲自对事实负责，否则演讲会把不确定性包装成成熟度。

3. 工程现实总会击穿单点性能崇拜

VR 讨论里，4090 的算力、注视点渲染、CUDA 推理和显示延迟被放在一起，但把刷新率从 240Hz 降到 60Hz 才解决问题的经历，说明系统体验往往不是由最强硬件决定，而是由最脆弱的接口决定。GPU 算力、显示链路、驱动版本、设备软件和延迟预算必须整体看待；任何一个环节的回归，都可能让“理论上更强”的方案失效。

可继续研究的方向，是把 neomacs 与 VR 手追放在同一个工程框架里观察：为高交互系统建立最小可复现样例、兼容性矩阵和性能基线，而不是只记录“能不能跑”。真正可扩展的项目，靠的不是一次惊艳演示，而是问题能够被稳定复现、定位和回归验证。