Emacs 社区日报 2026-05-11

约 3640 字大约 12 分钟

2026-05-11

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

Emacs 中文讨论组

🎯 核心热点与专题探讨

【专题】Emacs 编辑器生态深度讨论：包选择、配置陷阱与AI融合

本次讨论围绕 Emacs 编辑器的多个方面展开，包括包管理、配置问题、LSP 对比、AI 集成以及 UI 开发。以下是关键议题的总结：

1. Diff 工具链的选择与优化

主流选择：diff-hl 仍是 diff 显示的主流包，但存在性能问题（尤其是在旧电脑上）。有成员指出需开启 diff-hl-update-async 以提升性能。
自定义美化：成员 roife 分享了对 diff-hl 的修改，直接通过 elisp 调整其显示形状（GitHub 链接）。讨论认为保留一定宽度（即 fringe 留白）在视觉上更佳。
与 Modal 编辑的冲突：diff-hl 与 meow 编辑模式存在联动 bug，尤其是 revert hunk 等操作会导致模式从 repeatmap 意外退回 normal。社区通过为 meow-shim 和 diff-hl-show-hunk 等函数添加 advice 来解决。

2. LSP 客户端之争：lsp-mode vs. eglot

elegot 支持者：认为 lsp-mode 过于臃肿，依赖重。
lsp-mode 支持者：指出 eglot 缺乏自动化功能（如自动下载 LSP server、括号补全），需要用户手动下载和配置。
现实选择：成员实际多混合使用。讨论中透露 C# 语言服务器（roslyn-ls、csharp-language-server）体验不佳，最终转向 Rider IDE 或找到 --autoLoadProjects 参数解决。

3. Tree-sitter 配置难题（Doom Emacs 场景）

症状：用户配置 (javascript +lsp +tree-sitter) 后，虽然切换到 js-ts-mode，但完全没有高亮（如同纯文本）。在其他语言的 .so 文件手动下载后，错误消失但高亮不出现。在 macOS 上正常，公司 Linux 环境失效。
排错过程与关键建议：
- 检查 major-mode 是否为 js-ts-mode。
- 检查 (treesit-language-available-p 'javascript) 是否返回 t。
- 建议使用 (doom/sandbox) 排除 private config 冲突。
- 指出 typescript-ts-mode 已不推荐，推荐手动维护 treesit-install-language-grammar。
- 最后发现是特定机器环境的兼容性问题，而非配置错误。

4. AI 在 Emacs 中的集成与使用体验

AI 工具链分化：群内成员对 AI 的使用分为“全盘 AI 化”（如重度使用 Codex/Claude）和“实用主义”（仅在特定功能如生成 commit message 时使用）。
gptel 与 codex：形成三足鼎立趋势。部分成员将 gptel 替换为基于 llm 的自制方案，只用于 git commit msg 生成，Chat 功能交给 codex。roife 维护了一个 gptel-magit 的分支，合入了 5 个 PR 并修复了 bug。
AI 写代码的局限性：普遍认为 AI 适合基础的代码逻辑和单元测试，但在 UX/UI 一致性 和 用户路径测试 上表现糟糕，返工频繁。
Token 焦虑与模型选择：讨论了 API 额度的使用（如公司赠送的 2000 刀/月）、购买 Pro 账号（5x/20x 倍率）的策略，以及用 DeepSeek v4 代替昂贵模型进行简单请求。

5. 持久化 Undo 的困境

痛点：怀念 nvim 高效的持久化 undo，Emacs 生态下的 undo-tree, undo-fu-session, undohist 等包体验不佳（卡顿、Git 追踪持久化文件、配置繁琐）。
折衷方案：建议将持久化文件写入专用目录（如 ~/.emacs.d/cache/）并配置 .gitignore。

🛠️ Emacs UI 新范式：基于 Text Properties 的盒模型布局

核心人物：一位成员分享了其正在开发的新型 Emacs UI 布局方案，思想来源于 CSS 的 Flexbox/Grid。
技术亮点：
- 完全基于 Text Properties：彻底告别 header-line 等不可搜索的 hack，保证 buffer 内所有 UI 元素都可被 isearch 等标准操作访问。
- 增量更新：改变盒子大小或位置时，只需局部重排，无需渲染整个 buffer，性能大幅提升。
- 底层能力：不仅支持弹性布局，还支持单个盒模型属性的增量更新，为复杂动态交互（如 clutch UI）铺平道路。
群内反馈：高度认同该方向，认为其解决了长久以来 Emacs UI 开发的痛点，且与之前 org-supertag 和 grid-table 等局部刷新实践一致。

💰 A股/虚拟币投资讨论

状况：群内有成员玩 A 股和虚拟币，整体处于“被套”或“踏空”状态。讨论涉及慢牛行情、科技/医药/金融板块的轮动，以及个别成员（如持有腾讯）认为稳赚不亏的观点。

🔑 关键概念与技术解析

diff-hl：Emacs 的一个扩展，用于在文件编辑器行号区域（fringe）显示 Git 版本控制的差异（增加、删除、修改）标记，替代了 diff 命令在单独窗口的显示方式。
eglot vs. lsp-mode：两者都是 Emacs 实现 LSP（Language Server Protocol，语言服务器协议）的客户端。eglot 以最小依赖和简洁设计著称，倾向于依赖 Emacs 内建机制；lsp-mode 功能更丰富但包依赖重，提供了更多自动化功能。
treesit-auto / treesit-install-language-grammar：在 Emacs 29+ 中集成基于 tree-sitter 的解析器支持。treesit-auto 插件会自动下载并安装语言对应的 .so 动态库；treesit-install-language-grammar 是手动安装的命令。
meow-shim：在 meow 编辑模式下，为解决与其他包（如 diff-hl）键位冲突或行为异常而设计的“垫片”（shim）机制，通过 advice 函数在调用目标函数前后自动进行状态转换。
Text Properties：Emacs buffer 中附加在字符串上的元数据（属性、标记等）。通过操作这些属性而非修改字符串本身，可以实现极其高效、可搜索的富文本 UI，是高级 Emacs 开发的常用技术。

💎 碎片知识与金句拾遗

关于给女朋友做工具：“其实不建议给女票做一些东西，她不会觉得这个是需要成本和精力的事情，只会不断的提需求。” —— 来自一位成员的现实主义劝诫。
关于 AI Token 的通货膨胀：“token 已经通货膨胀了” —— 感慨 AI 额度消耗太快。
关于代码质量与 AI：“AI 不擅长从用户使用路径测试，只能停留在对基础代码分支进行测试。” —— 精准点出当前 AI 测试的短板。
关于 Emacs UI 开发的自我和解：“尽管以前觉得在 emacs 调前端很累，但回到其它产品上，即便是 Electron 架构，调前端也同样差不多那么累... 在调整交互和 UI 上，通过这种对比，奇妙地在内心达成了和解。” —— 对于在不同平台上进行 UI 开发的顿悟式感悟。
关于配置简洁与大佬的刻板印象：“Emacs 这边形成的配置越简单越是大佬的刻板印象，在 Nvim 那边不是这样的。” —— 指出了两个社区文化差异的观察。
关于使用 AI 写代码的依赖：“我已经是 GPT 大人的形状了” 与 “已经没有Codex无法写代码了” —— 对当前技术依赖的幽默自嘲。
项目推荐：成员发布了一个 A 股的 MCP 服务器（Model Context Protocol）：https://github.com/Kinneyzhang/a-share-mcp，用于接入 AI 代理。

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

roife/roife.gptel-magit：基于 gptel-magit 的改进分支，合并了多个社区 PR，修正了 bug，可作为 Emacs 中 AI 辅助 Git 提交的升级方案。
基于 Text Properties 的盒模型布局（Flexbox/Grid in Emacs）：该项进展虽未开源，但代表了 Emacs 自身 UI 开发的一个极具潜力的范式转变。关注点在于其“增量更新”与“可搜索性”的实现细节，未来可能彻底改变 Emacs 的 UI 架构。
Codex 与 Emacs 的深度集成：讨论中体现出将 codex（或其他 SaaS AI）作为主要编程助手，而非通过 gptel 插件进行的尝试，包括调用 Emacs 截屏、直接与编辑器 Buffer 交互等。这是一种更底层的 AI 集成模式。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题：Vibe Coding 的困境与出路 —— 从“失控”到“可控”

这是本群讨论最激烈、持续时间最长的核心话题。成员们围绕 AI 辅助编程（尤其是“Vibe Coding”模式）带来的质量、维护性和可审计性问题展开深入探讨，并提出了几种应对思路。

痛点与困境：

逻辑膨胀与“防御性编程”：多位成员提到，AI 模型（特别是 GPT）生成的代码倾向于不断增加新功能、新测试，而不愿删除已无用的逻辑。成员 [22:42] 指出 GPT 会“防御性编程”和“防御性测试”，导致代码库臃肿。成员 [22:51] 抱怨“很多时候 gpt 不愿意删除已经没有用了的代码和测试”。
Review 困难与信任危机：当 AI 生成的代码超出开发者自身的“古法编程”能力时，Review 变得形同虚设。成员 [23:15] 认为“人的 review 不能解决這個問題的”，成员 [23:17] 描述了一种“根本review不动”的无力感。成员 [23:18] 反映测试人员对“ai写完直接提测”的模式疯狂吐槽。
维护性灾难：成员 [23:03] 给出了悲观的预测：“大量 vibe coding 的代碼，是沒有救的，一旦 llm 基本也改不動了，就到頭了”。

解决方案探讨（从“减法”到“元Vibe”）：

手工做减法：成员 [22:50] 承认“去梳理，做减法，很痛苦，花费的精力很多”，并描述了自己的“力大砖飞”式工作流：开 3 个 AI 窗口（一个用于写代码，两个用于 Review 和计划），分别使用 Pi、DeepSeek 和 Codex。
“元Vibe” / 中间工具策略：这是讨论中最具洞察力的方向。成员 [23:22] 提出“在vibe的基础上再建立一层抽象，来控制vibe的过程”。成员 [23:24] 分享实践：“最近我要分析按键日志，我就让ai写分析工具，而不是ai直接去分析日志”。成员 [23:25] 进一步升华了这个思路：“先写解决(子)问题需要用到的通用/专用技能，把技能测试稳定后，再用这些技能来实施”，并认为这样“技能是可以不断累积的资产”。
人写签名，AI 写实现：成员 [23:20] 提出一种理想的分工模式，认为这样“可控的多”。

小型热点：AI 工作流编排与工具链吐槽

Chatbot 客户端的选择：成员间在寻找 Cherry Studio 的跨平台替代品，有人提到了 aichat（一个 Rust 编写的 CLI 项目）和 webui chat，但讨论未深入。
Pi（可能指某个 Agent 框架）的使用障碍：成员 [16:30] 遇到 Pi 工具调用过于频繁导致的 429 限流和 502 网关错误，暴露出 agent 工具调用不节制的痛点。
Nix 包管理的摩擦：成员 [18:07] 和 [22:13] 吐槽 Nix 的复杂性，特别是处理 pkgs.corepack wrapper 和 read-only store 的摩擦，并表示对自己的定制需求而言“摩擦有点大”，转而考虑 mise 和 asdf。

🔑 关键概念与技术解析

Vibe Coding：一种流行的 AI 辅助编程方式，强调让 AI 主导代码生成，开发者仅通过自然语言描述需求，但往往牺牲了对代码细节和结构的控制，导致质量不可控。
防御性编程 / 防御性测试：在 AI 代码生成语境下，指 LLM 倾向于无根据地为各种边界情况添加逻辑和测试用例，导致代码过度复杂，缺乏“减法”思维，是逻辑膨胀的主要来源。
元Vibe (Meta-Vibe)：群友提出的一个前瞻性概念，指在 Vibe Coding 之上构建一层控制、约束和编排工具，来引导和固化 AI 的编码过程，使其结果更稳定、可复用。
Pi：一个对话中提到的 AI Agent 框架，以工具调用频繁著称，可能会因此导致 API 调用过载和速率限制问题。

💎 碎片知识与金句拾遗

AI 工作流程：[22:51] “现在很原始粗暴，开一个 Pi，挂 ds。然后再开一个 codex。然后 codex 说了啥，就贴过去。” 一个过于复杂的3窗口工作流，反映了当前对 AI 输出质量不信任下的无奈之举。
对 Vibe Coding 的反思：[23:16] “vibe拓展了人编程能力的上限...所以review并不能掌握”。精准点出了Vibe Coding的核心悖论。
对未来的悲观预测：[23:03] “大量 vibe coding 的代碼，是沒有救的，一旦 llm 基本也改不動了，就到頭了。” 一句冷酷的技术“判词”。
AI 工具对比：[22:45] “gpt5.5做代码分析非常强，但是写代码缺大局观...这一点claude要好很多。”
实用手机编程技巧：[23:37] 分享了一个 Trime (Android 输入法) 的键盘配置，通过上滑、下滑等手势映射 Alt/ Ctrl + 字母，在手机上实现接近 PC 的 Emacs 操作体验。
内网穿透服务推荐：[23:57] “内网穿透比tailscale 好用” 和 [23:58] “懒猫微服可以打洞直连...很丝滑，这个再吹都不过分”。群友对“懒猫微服”的内网穿透体验评价极高。

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

Hermes Agent：成员 [22:52] 提到正在“努力让 hermes agent”自动化管理多个 AI 代码窗口的工作流。这个 Agent 项目值得关注，可能是实现“元Vibe”控制的一个潜在工具。
“中间工具”策略：群友提出的“先写AI分析工具，再用工具分析数据”的思路，是一种将 AI 能力固化为可复用技能包的有效实践。值得探索相关的微调或函数调用模式。
aihappy.org：[22:08] 提到的 boslife 的新中转站，走美国家宽。可作为访问 OpenAI 等服务的备用/特惠API方案调研。
Trime V3.2.19 版本：[23:43] 群友强烈推荐的古老版本，因其有语音输入和便捷的中英切换UI，对于有在手机上码字需求的极客来说，是一个值得捡起的配置。