Geekinney

外观

Emacs 社区日报 2026-05-21

约 3178 字大约 11 分钟

2026-05-21

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

Emacs 中文讨论组

好的，作为资深技术社区编辑和信息架构师，我已分析完这份群聊记录。今天的话题核心是 Emacs 生态的深度痛点与新版本的迭代状况，夹杂着一些开发者群体特有的幽默与吐槽。

🎯 核心热点与专题探讨

专题：Emacs 31 “Cut” 版本与稳定性之争

群聊中后段集中讨论了 Emacs 31 的新版发布机制——“Cut”分支。

  • 核心痛点：开发者们发现，新安装的 Emacs 31 (从emacs-31分支构建) 在加载某些包（尤其是 vertico 和 magit）时会出现 set-local 函数未定义的错误。
  • 问题溯源与解决方案：经过查证，set-local 函数是在 2026年4月3日才被提交到 Emacs 主仓库的。这暴露了 “Cut” 版本机制的一个关键问题：分支在特定时间点 “cut” 出来，但后续的小补丁和功能合并是持续进行的，如果用户构建的版本过老（例如聊天中提到的“4月1号版本”），就会错过这些关键的修复。解决问题的方案是升级 Emacs 源码到最新提交，或更新相关 compat 包。
  • 对于“Cut”版本的深度理解：用户们澄清，Emacs 31 的 “Cut” 并非完全的冻结。正如聊天中引用的 release-process 文档所示：“Phase two: fixing and stabilizing the release branch”。这意味着新的功能和修复从 master 合并到 emacs-31 分支是常态。因此，用户需要持续跟踪分支的最新提交，而非固守一个 “cut” 的时间点。
  • 用户选择：一位用户展示了他在 NixOS 上如何通过 overrideAttrs 指定特定 Git commit 来精准锁定 Emacs 31 版本的技巧，这体现了一种对构建流程进行精细控制的硬核应对方式。

插曲：Emacs 行高、Emoji 与中文阅读的困境

这本质上是关于 Emacs 中文本与表情符号渲染的矛盾。

  • 问题：Emacs 的 line-spacing 是在每行字符上额外增加间距，无法从根本上解决中文字体因过高导致的视觉拥挤问题。而 Emoji 的渲染（尤其是 telega 中的头像）又容易破坏行高的一致性，导致“头像裂开”。
  • 尝试与挫败：用户尝试通过 patch 解决 Emoji 导致的行高溢出，但随后发现连 line-spacing '(1 . 1) 这种设置下，图片切割问题依然存在，必须设为0。这表明，Emacs 要想优雅地处理混合非拉丁字符和图片的复杂排版，仍有很长的路要走。
  • 一个有趣的调侃：有人提议“单独做个高的英文字体用”，这实际上是一种曲线救国的思路：通过使用更高字面高度的英文字体来对齐中文的高度，从而消除行高差异。

🔑 关键概念与技术解析

  • set-local：Emacs 31 中新加入的一个函数，用于设置缓冲区局部变量。该功能是 Emacs 31 发布周期中的一个重要补丁，其缺失导致一些依赖于该函数的包（如 magit, vertico）无法在较早的 “Cut” 版本上正常工作。
  • cut 分支：指 Emacs 在发布正式版前，从 master 主线独立出来的一个稳定化分支。该分支会接受错误修复和稳定的功能合并，但不再引入激进的重构，目的是为最终发布做准备。群聊中讨论的 emacs-31 分支即为此类。
  • overlay (在 Emacs 上下文中)：虽然聊天没有直接说明，但讨论 Emoji 导致行高问题的本质是 Emacs 的 overlay 机制——例如 goggles 包和 telega 中的图片、Emoji 都可以被实现为 overlay。这些 overlay 的尺寸和位置会影响其所在窗口的排列，从而导致排版混乱。这是 Emacs 排版引擎的一个核心局限。
  • elfeed 升级：一个具体的 Commit 被提及作为“升级太对了”的例子，这是关于 RSS 阅读器 elfeed 的某个改进，体现了 Emacs 社区对具体插件稳定性和功能迭代的持续关注。

💎 碎片知识与金句拾遗

  • AI 污染幻想：有用户脑洞大开，认为如果 Meta 用员工电脑数据（比如一个重度 Emacs 用户）训练 AI，最终会训练出一个“只会用 Emacs 干活，聊天发邮件刷 RSS 都在 Emacs 里”的模型。这是个半开玩笑的嘲讽，但也折射出开发者群体对自己工作流的极致执念和对通用 AI 的某种文化解构。
  • goggles 插件：当被问及“后面布灵布灵闪的是什么包”时，回答是 goggles。这可能是 Emacs 生态中一个用于高亮某个特殊状态或事件的视觉反馈插件，具体功能不详。
  • Matrix 桥接困难：“好像这边又看不到 matrix 的消息了”——这暗示该群聊很可能是一个由 Matrix 桥接到 Telegram 的混合群组，且跨平台的消息同步存在偶发性的断联和回溯问题。这是现代极客社区基础设施的一个常见痛点。
  • igc 崩溃：提到 my igc feels easy to crash。igc 可能是指某个 Emacs 内部或第三方 GC（垃圾回收）相关的功能或包，说明其稳定性仍有待提升。
  • 从 NixOS 叛逃到 Mint：“已经叛逃mint了。” 理由是“nixos用起来不能随便装野deb包”。这反映了 NixOS 的声明式系统稳定性与 Debian/Ubuntu 系（Mint）的便利性与灵活性之间的经典权衡。尽管有用户提出“nix包+野deb”的折中方案，但显然对当事人而言，后者的易用性胜出。

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

  • Emacs “Cut” 分支的构建与调试：对于希望使用 Emacs 31 最新稳定版本的开发者，掌握如何从源码构建特定分支（如 emacs-31），并根据 commit 历史解决包兼容性问题，是一项很有价值的技能。
  • set-local 函数在 Emacs 31 中的引入：可以查阅 admin/release-process 和 etc/NEWS 来了解 Emacs 版本号与管理流程的演进细节。
  • elfeed 的 67e8526 提交：深入查看该提交内容，了解 Emacs RSS 阅读器的最新优化方向，这对于 RSS 重度使用者很有参考价值。
  • NixOS/Guix 上的 Emacs 覆盖技术：聊天中有人展示的 overrideAttrs 技巧展示了如何精细控制 NixOS 上 Emacs 的版本，这对于在非滚动发行版上跟踪 Emacs Git 分支的用户是一个可复用的模板。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题】Vibe Coding 的现状、成本与反思

群聊围绕“Vibe Coding”（一种依赖AI自动生成代码的编程方式）展开了激烈讨论，主要聚焦于其带来的软件质量下降、成本失控以及正确使用方式。

  • 软件质量普遍下降：多名成员观察到近期多个软件（如Slack）出现了“特别低级”的bug，引发了对“全民皆vibe”现象导致软件质量下滑的担忧。甚至有成员直言“vibe用完额度，拉出来全是💩”。
  • 成本与额度焦虑：大家普遍吐槽Pro额度的消耗速度。有成员反馈“一个目标干了一夜，干了我一半的pro周额度”，而Plus用户则表示“两个需求烧掉周限额30%多”，显示出对资源消耗的普遍焦虑。
  • 模式与策略争论：关于如何高效使用AI Agent，形成了两种观点。
    • 激进派：倾向于“起手就是yolo”，追求全自动化，但也被指出“会跑偏，太偏了”。
    • 保守派：建议“手动 yes，看着他做”，分步确认，例如在半小时内完成一个AND/OR/NOT语法和strace追踪规范的需求。
  • Vibe的中性化：有成员提出“好好vibe的话，感觉vibe也是一个中性词了”，并引用“simon willams的vibe是好vibe”，暗示如果策略得当，Vibe Coding可以是一种高效的工具而非纯粹的质量毒药。

【专题】终端多路复用器新秀：RMUX 与 Neomacs 生态系统

群聊中出现了两个与终端和编辑器相关的新/热项目：RMUX 和 Neomacs，并引发了对其能力与社区关注度的讨论。

  • RMUX (Rust编写的原生终端多路复用器)：通过Rust日报分享后，引发了“能打么？”的疑问。讨论者将其与现有方案（zellij、tmux）对比，认为zellij工作流与tmux不同，而RMUX的特色在于“Demo视频做得不错”，并且它声称支持Windows，这一点引起了兴趣——“这个牛🤔”。但也有成员评价“这个 vibe 味太重了”，暗示其宣传或功能可能过于依赖AI。
  • Neomacs 的性能挑战与开发环境：开发者长期吐槽Neomacs（用Rust实现的Emacs）的性能问题。例如“系统莫名其妙重启了”，怀疑是OOM或内存不稳定导致的。有成员展示其i9-14900K“马力全开”跑集成测试，并感叹“要是我有128核心的CPU就好了”。此外，还遇到“启动是白屏的，看不见字体”的bug，经排查发现是“默认的foreground不小心改成白色了”。

🔑 关键概念与技术解析

  • Vibe Coding：一种编程范式，指开发者主要通过自然语言描述需求，让AI（如ChatGPT, Claude）自动生成代码，开发者更关注结果而非具体实现过程。群聊中的讨论表明，它已是普遍现象，但存在质量、成本和策略上的考量。
  • yolo / auto：在AI Agent编程上下文中，指不同自动化程度的模式。
    • yolo: 全自动模式，Agent自主决策和执行所有步骤，效率高但容易偏离预期（“会跑偏”）。
    • auto: 半自动模式，Agent执行会请求用户确认（“手动yes”），可控性更强，成本也相对较低。
  • 平面单位距离猜想：由ChatGPT证明的一个严肃数学猜想，其思路被认为“人想不到”，展示了AI在理论探索上的潜力，与软件开发的“vibe coding”形成对比。

💎 碎片知识与金句拾遗

  • Emacs AI Agent 架构畅想：有成员提出一个新颖的构想：“如果 emacs 的 buffer 实际上是一个共享的数据池。那么适合 emacs 的 AI Agent 应该基于 buffer 的特性来展开。尤其是多 agent 编排这个问题。” 并分享了一篇相关博文《Emacs AI Agent 架构：基于 Buffer 状态共享…》。
  • 超级CPU的渴望：开发者对高性能计算的朴素需求：“唉，要是我有 128 核心的 cpu 就好了”。这源于编译Rust项目（Neomacs）和跑测试的时间压力。
  • 排查系统崩溃的实用技巧：当系统重启后，使用以下命令查看重启前的日志：
    sudo journalctl -b-1
    但需注意：如果重启前日志未刷新到磁盘，则无法排查。
  • 生活关联：有成员提到“日常使用 superchat 做简单的查询”，可能是AI聊天工具的日常使用。
  • Intel CPU 的“雷”：一位使用i9-14900K的开发者吐槽“这个cpu太雷了，内存xmp都跑不起来，我自己调的参数高负载的时候容易挂”，反映了个体CPU体质差异带来的稳定性问题。

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

  • RMUX (Rust-based terminal multiplexer)：一个声称支持Windows的Rust原生终端复用器。其Demo视频展示了编排能力，值得关注其在多平台兼容性、性能以及与Rust生态的整合程度。项目地址：https://rmux.io/
  • 基于Buffer的Emacs AI Agent架构：成员提出的“多Agent编排”思路，将Emacs Buffer视为共享数据池。这为在Emacs生态中构建更智能、协作式的AI Agent提供了新的设计范式。相关文章值得深度阅读：《Emacs AI Agent 架构：基于 Buffer 状态共享…》
  • 平面单位距离猜想的证明：由ChatGPT独立完成，证明思路与传统数学界截然不同。虽然可能难以复现或应用，但其展现了大型语言模型在抽象数学推理上的能力边界，具有里程碑意义。