Geekinney

外观

Emacs 社区日报 2026-05-24

约 3679 字大约 12 分钟

2026-05-24

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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：Neomacs 生态的活跃发展与跨平台适配挑战

  • Neomacs 项目已经进入“基本稳定运行、不会立即崩溃”的阶段，但 emacs-china 的朋友们持续贡献反馈（build、run、give feedback），证明社区力量是 NeoEmacs 前进的关键。
  • 跨平台渲染问题：NeoEmacs 在 Wayland 下字体清晰，但在 X11 下模糊；缩放问题在 Wayland 环境下存在（字体似乎大一倍）。有开发者考虑用 AI 帮助在 X11 中搭建 Wayland 环境（应用最新 Weston ？）来专门测试缩放问题。这表明 NeoEmacs 团队（及社区）正着力于解决窗口管理器兼容性痛点，尤其是字体渲染和缩放差异。
  • 对外交流与语言风格：一位核心开发者（疑似项目作者）在英文 Lisp 群组中发言，表达“用爱发电”的驱动理念，但群友提醒第二段英文语气略显不够友好（如“I drive the development... purely out of love” 和 “I am indifferent to whether or not it becomes popular” 可能被理解为傲慢）。开发者意识到问题并幽默吐槽中文10个字能表达的意思，英文需30个单词。
  • 自动化构建：使用 kimi 2.6 成功打包 NeoEmacs 的 AppImage（版本 v0.0.3），让跨平台分发更便捷。

专题：Emacs 中 Vibe Coding 潮流的争议与 Org-Roam 的链接管理

  • Vibe Coding 态度：群内明确表示“不是很喜欢 vibe coding”（指完全依赖 AI 生成代码而不深入理解的模式），反映开发者社区对 AI 开发的审慎态度。
  • Org-Roam 链接同步机制的讨论与实践：围绕“是否应该自动更新链接描述”展开。有开发者自己编写了 org-roam-sync-link-descriptions 函数，实现扫描所有 id: 链接的源文件与目标节点 #+title: 对比更新，同时智能跳过描述在目标 #+aliases: 中的情况。这实现了“同步为主，可保留别名例外”的灵活机制。有人表达喜欢这种显式控制（git diff 事后干预），也有人怀念 Logseq 的自动同步哲学。

专题：Vertico + org-roam 的中文输入法/多模态输入适配问题

  • 问题描述：用中文输入法状态下，C-c n f 触发 org-roam-node-find 后，n f 会先进入输入法候选框；切回英文再继续时，Vertico 显示 node 数量为 0；但按空格后立刻恢复正常。这暴露出 Vertico 在异步/非阻塞初始化时对输入法状态变化的响应能力不足。
  • 解决方案：社区提出两者皆有效的解决路径：
    1. AI 建议的轮询刷新（0.2s 循环），但被批评太复杂且可能带来性能负担。
    2. 更优雅的一行 Lisp 代码：(define-advice vertico--update (:filter-args (_) uninterruptible) nil) 直接绕过 interruptible 模式。但随后有人指出，原版在 vertico—exhibit 中使用 (vertico--update 'interruptible) 是有性能考量（可能避免长操作阻塞界面），所以这种“粗暴”解法在极端场景可能存在隐患。

🔑 关键概念与技术解析

  • Vibe Coding：一种依靠 AI 自动补全/生成代码，开发者仅凭情绪直觉和 prompt 驱动的编程风格。群内对此持保留态度，认为不利于深度理解。
  • Org-roam / Org-roam DB： Emacs 下的 Zettelkasten 知识管理工具，基于 Org-mode 和 SQLite 数据库；org-roam-db-query 与 org-roam-directory 是核心元素。
  • Weston： Wayland 参考合成器（compositor），可用于测试 Wayland 应用程序（如 Neomacs 的缩放）。
  • INFOPATH 环境变量： Emacs 和其他 Info 文档阅读器寻找 info 文件的路径。当 /usr/share/info/dir 未正确更新（例如 hook 未触发）时，手动设置 INFOPATH 可以解决问题。
  • texinfo-install.hook： Arch Linux 软件包安装后自动执行的后处理脚本，用于更新 /usr/share/info/dir 文件。安装 emacs-wayland 时，这个 hook 可能还未安装，导致目录索引未构建。
  • Neomacs：一个仍在极早期阶段的现代化 Emacs 实现，使用 C++ / Lisp，基于 WebKit（或类似前端）渲染。目前已能在 Wayland 和 X11 运行（虽有缩放/字体问题），社区积极提供构建和反馈。

💎 碎片知识与金句拾遗

  • AI 工具的实用性推荐：deepseek-tui 是专为 DeepSeek 模型的 agent 封装，可以尝试；openclaude 是一个跨平台的 Claude 交互客户端；kimi 2.6 被成功用于打包 NeoEmacs AppImage。
  • Emacs 文档查找小技巧：C-h r (Info 中的 Emacs 手册) 与 C-u C-h i (直接指定 info 文件路径打开) 是解决官方文档不可见的备用方法。群内有人感叹“居然有这个按键，文档没看全”——这正是 Emacs 学习曲线特征。
  • “用爱发电”的英译吐槽： “I drive the development of Neomacs purely out of love —fueled by a burning passion.” 被自己吐槽“10个字表达的意思，英文得30个单词”，并称“不知道说英语的外国人能不能 get 到这个点”。生动反映了跨文化交流中的语言简洁性差异。
  • Mode-line 中的 [=== ] 状态条解释：代表 LSP (Language Server Protocol) 的索引状态（可能正在建立索引），长时间如此通常意味着远程文件或 LSP 连接卡住。通过查看 mode-line-format 变量可自定义。
  • 群组引介：有老外讨论 Lisp 的 Telegram 群组 Monadic Sheep，口号“Emacs is Lisp Operating System”、“Forth, Lisp, monads and Prof. D. Z. Knottes”，但群组似乎已锁闭。
  • 对 Vibe Coding 的态度：“這個群不是很喜歡 vibe coding.”——代表不少硬核开发者对“只看结果不看过程”的 AI 开发模式的拒绝。

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

  • Neomacs 跨平台渲染适配：Neomacs 目前支持 Wayland 和 X11 的基础运行，但字体清晰度、缩放比例、以及窗口管理器差异尚待彻底解耦。项目在 github.com/eval-exec/neomacs 持续开发，AppImage 构建的 CI 链路值得关注。
  • Org-roam 同步链接描述的高级控制：提供的函数 org-roam-sync-link-descriptions 是一个高度定制的链接同步工具（扫描 id:/roam_refs: 链接，读取 target 的 #+title: 和 #+aliases:），若收录入社区包 org-roam-contrib 或作为定制方案，对知识管理深度用户非常有价值。
  • Vertico 中断处理与输入法兼容性：通过 define-advice vertico--update 改变其 interruptible 行为来解决用户输入冲突的方法，虽然当前代码简单有效，但需要关注原作者注释里的性能顾虑。此问题可能会导致 Vertico 在处理高负载过滤时出现卡顿，适合深入研究其状态机设计。

Emacs 轻聊讨论组

好的，各位硬核玩家。让我们把今天群里的碎片信息，淬炼成一份值得归档的知识情报。

🎯 核心热点与专题探讨

专题一：国产大模型在编程实战中的“千模千面”与“水土不服”

今天的讨论核心几乎完全围绕国产大模型（GLM、Kimi、DeepSeek）在实际开发工作流中的表现，尤其是与第三方工具（Codex编辑器、Claude Code、gptel）协作时的兼容性问题。大家普遍反映，模型的表现并非绝对的好坏，而是高度依赖其部署形态（自有API vs 第三方平台）和前端工具。

  • GLM 的“智障审稿”门：一位群友使用 GLM-4.6v 判断垃圾信息，结果模型自带的安全过滤把普通请求也拦截了，引发众嘲。大家认为这是 GLM 在 API 层面加固了内容审查机制，与硅基流动等第三方代理平台提供的 Kimi 等模型形成鲜明对比。这表明国产模型的“安全红线”对开发者而言是一个严重的不确定因素，开发者在使用时需要评估其是否会打断正常的工作流程。

  • 模型在不同工具中的表现反差：这是一个极具价值的观察点。

    • GLM 5.1：在 Claude Code 中 autocompact（自动压缩上下文）功能失效，手动压缩也失败；但在 OpenCode 中却表现正常。
    • Kimi 2.6：被 gptel 用户誉为“写 AppImage 打包脚本和 CI”的神器，一次打包成功；但被指出其 temperature 参数被硬编码为 0.6，无法调节。
    • 结论：模型与工具的适配性差异巨大，甚至大于模型本身的能力差异。一个在A工具上表现糟糕的模型，可能在B工具上就是神队友。开发者在进行方案选型时，不能只看基准测试，必须结合自己的具体工具链进行“交叉测试”。

  • 国产模型的代码能力排序（基于群友主观评价）：

    1. Kimi 2.6 / 2.5：评价最高，被称为“高冷”、“听话”，尤其擅长编写自动化脚本和单元测试。
    2. DeepSeek V4：性价比高，代码质量不错，是可靠的备选。
    3. GLM 5.1：评价分化，有人觉得不错，也有人认为不如Kimi，且存在兼容性问题。
    4. 小米免费 Token 绑定的模型：质量被认为一般，且消耗速度极快（“7亿token一天就写完”），被怀疑内部计费有倍率。

专题二：Neomacs 的现代化“重构之路”——从 AppImage 发布到平台适配

群主 eval-exec 的 Rust 重写 Emacs 项目 Neomacs 进入了关键的发布冲刺阶段。今天群友全程参与了其 CI 发布、跨平台适配和兼容性测试，展现了从“写代码”到“做产品”的阵痛与欢乐。

  • CI/CD 成功：借助 Kimi 2.6 编写的 GitHub Actions 脚本，成功生成了 Linux (AppImage, 81MB) 的首个可执行包。这标志着项目从源代码编译进入了“可分发”阶段。
  • 跨平台策略：开发者明确规划先攻克 Linux、macOS、Windows 三大主流平台，拒绝了早期对鸿蒙/安卓的支持建议，认为应聚焦主流体验，避免分散精力。这与 neovim 早期的策略一脉相承。
  • 新旧系统的兼容性问题：AppImage 包最低要求 GLIBC 2.34，这导致 Debian 11 (GLIBC 2.31) 等较老系统无法直接运行。开发者考虑将 glibc 打包进 AppImage 或使用 nix 打包来解决，但目前尚未定论。这反映了现代 Rust 项目对系统基础库版本要求越来越高的趋势。
  • WSL2 下的困境：群友在 WSL2 下测试时，遇到了 wgpu 图形后端创建失败（CreateSurfaceError）和 X11 扩展加载失败的问题，表明 Neomacs 目前对 WSL2 的桌面环境（无论是 X11 转发还是 Wayland）支持尚不成熟。

🔑 关键概念与技术解析

  • gptel：一个 Emacs 中的 AI 客户端插件，允许用户在 Emacs 内部直接与各种大语言模型（如 GPT, Claude, Kimi）交互。
  • autocompact：Claude Code 中的一项功能，当上下文窗口满载时，自动压缩摘要并丢弃历史记录，从而延续对话。
  • AppImage：一种 Linux 下的通用软件打包格式，目标是“一键式运行”，无需安装。它通过将应用程序及其所有依赖项打包成一个文件来实现，但打包时的 GLIBC 版本会成为宿主机的最低需求。
  • Codex：群内讨论的代码编辑器，应为某个 AI 代码编辑器产品（非 OpenAI Codex）。
  • wgpu：一个跨平台的、基于 Rust 的图形 API (WebGPU 标准的原生实现)，用于高性能图形渲染和计算。canirun.ai 网站用于评估不同 GPU 能否运行特定 AI 模型。

💎 碎片知识与金句拾遗

  • 关于GLM的过滤：“真是服了，让 glm 判断消息是否是垃圾信息，然后它告诉我输入内容包含不安全或敏感内容，让我修改后重新提交。” —— 道出了开发者面对 AI 模型的底层安全审查时的无奈与讽刺。
  • 关于Kimi的风格：“当时主要是欣赏它的高冷🤣我让它简洁点就挺简洁的” —— 一个极客对模型给出“情绪价值”的独特理解。
  • 关于Kimi的缺陷：“但是 kimi2.6 的 temperature 只支持 0.6” —— 一个看似无关紧要的参数，对于需要高创造性的编程任务可能成为致命伤。
  • 关于Codex套餐：“$100高强度用的话，一天之内还是需要等额度重置的，所以我搞了200美元的，但是200又太多了，它没有一个折中的计划，比如150美元左右，可能会刚好。” —— 反映出现阶段 AI 生产力的消费困境：缺乏精细化的套餐设计。
  • 关于Neomacs的发布：“以后我每天打一个 tag，发一个 AppImage。就叫 NEO Emacs nightly-2026-05-24.” —— 一个极客的浪漫与工程化的日常。
  • 关于Neomacs的未来：“你虽然丢掉了一些本来的平台，但同时你也丢掉了大量复古系统的支持，可以集中精力优化好主流平台的体验。” —— 对于复兴一个上古神器的哲学思考：先做减法，再做加法。

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

  1. Neomacs Git 仓库：

    • 关注点：项目进展（GitHub Actions 的 CI/CD 构建状态），跨平台支持（macOS dmg, Windows exe），对不同 Emacs 生态插件（如 gptel, refined-github）的兼容性。
    • 潜在价值：它可能会成为下一代 Emacs 的开源标杆和极客们的“终极编辑器”实验田。
    • 地址：https://github.com/eval-exec/neomacs (基于聊天内容推断)

  2. Kimi/K2.6 模型在 Claude Code 或 OpenCode 中的实际表现对比：

    • 关注点：为何在 OpenCode 中正常工作的 autocompact，在 Claude Code 中失灵？这可能是由于 Claude Code 对本地模型/非官方模型的支持方式不同导致的。
    • 潜在价值：理解底层协议（如 OpenAI API 兼容性）的细微差别如何影响前端工具的行为，对于搭建自己的 AI 辅助编程环境至关重要。

  3. canirun.ai 网站：

    • 关注点：用于评估特定GPU（如 AMD 7900XTX）运行特定大模型（如 Qwen 3.6 27B）的理论可行性。对于考虑本地部署模型的用户，这是一个极佳的决策辅助工具。
    • 潜在价值：避免盲目购买硬件，基于数据进行本地推理硬件的选型。
    • 地址：https://www.canirun.ai/