Geekinney

外观

Emacs 社区日报 2026-07-04

约 6000 字大约 20 分钟

2026-07-04

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

Emacs 中文讨论组

好的，群聊记录分析完毕。以下是本次的结构化知识提炼。

🎯 核心热点与专题探讨

专题一：Emacs 中文输入法的“三国演义”——Rime、系统输入法与混输体验

今日讨论最激烈、参与人数最多的主题围绕着 Emacs 下的中文输入方案展开，核心矛盾在于 “极致内联编辑(Inline Editing)” vs “系统级流畅与易用性”。

1. 阵营与分歧

  • Rime 拥趸 (主流意见)：认为 rime-frost (白霜拼音) + 万象模型 (Wanxiang) 的组合准确率极高，吊打 macOS 自带输入法。核心痛点在于：依赖 Lua 导致性能问题、GUIX 上打包的旧版 librime 无法正常选词、Android 端数据同步困难、以及 emacs-rime 配置繁琐且偶尔会卡死 Emacs。
  • 系统输入法派 (少数派)：以 zdn 为代表，认为在 Windows 上，系统输入法的细枝末节（如微软拼音）更完美，emacs-rime 等方案存在启动慢、丢缓存等痛点，最终选择优化系统输入法以适配 Emacs。
  • 混输/体验派：关注中文输入中插入英文的体验（如 macOS 的混输模式），认为 Rime 方案（即使是万象）在混输上仍不如 macOS 原生流畅，且难以做到真正的即混即输，需要预先固定词组。

2. 终极解决方案探讨

  • 方案 A (向系统投降)：放弃 fcitx5，直接集成 librime，绕过系统框架，但会失去内联编辑支持。
  • 方案 B (Emacs 内集成)：使用 emacs-rime、rimel 等包，通过 Overlay 实现内联编辑。但存在性能问题、启动慢（需加载字典）、以及与不同系统输入法框架（IM, XIM, pgtk）的冲突。
  • 方案 C (折中)：在 Emacs 内禁用系统输入法（如 (setopt pgtk-use-im-context-on-new-connection nil)），完全依赖 Emacs 自身的输入法管理，但这在非 pgtk 环境（如 macOS、Windows）上难以实现。

结论：社区不存在“最佳”方案，只有基于个人工作流（桌面环境、Emacs 构建方式、对性能/内联编辑的优先级）的权衡。rime-frost + 万象模型 组合已获得压倒性的质量认可，但如何将其优雅地集成进 Emacs 仍是待解决的工程挑战。

专题二：Emacs 触屏化与移动端改造——系统工程而非单一插件

讨论从 DnD (拖拽) 在 Evil 模式下的交互缺陷，扩展到了整个 Emacs 触屏化的大命题，反映了社区对非传统使用场景（如手机、游戏机）的探索野心。

1. 现状与痛点

  • DnD 抽象缺失：群友指出 Emacs 不仅缺 DnD 包，更缺一个能跨平台（GTK4 模型被提及）的 “数据搬运抽象”，导致实现困难。
  • TUI 触屏支持：在手机通过 ssh 或 sunshine/moonlight 串流到 arch wayland 环境时，触屏体验严重依赖终端。foot 因将触屏翻译为鼠标滚轮事件而表现正常，kitty 则不行。
  • 虚拟键盘设计：普遍认为“触摸屏写代码”太痛苦，转而思考如何设计 “不遮挡内容的半透明虚拟键盘”、“模态编辑”、以及利用物理按键（如音量键）作为修饰键来提升手感。一个创意是使用 SVG 描述全屏可滑动的按键布局。

2. 前沿探索

  • 3DS 上的 Emacs：群友展示了在 3DS LL 上通过改造 sshc 应用运行 Emacs 的演示，并利用主机自带按键 (ABXY) 进行操作。这被视为极端但有趣的 Moblie Emacs 实现案例。
  • 终极目标：从 DnD 增强包、到 foot/niri/emacs 的全面触屏适配，再到 WM 集成的 on-screen keyboard。社区成员不是在寻找一个小补丁，而是在构建一个从显示、输入到交互的全栈桌面化触屏方案。

专题三：Agent 集成 Emacs 的现实困境——从“嵌入”走向“调用”

讨论围绕着 gptel 等 AI Agent 插件在 Emacs 内的表现展开，最终指向一个较为悲观的结论。

  • 核心问题：Agent (如 agent-shell, claude code) 运行时极其吃资源，内存占用可达 4GB，并在文本流式输出时导致 Emacs 主进程卡顿，属于“使用体验上的不可接受”。
  • 原因分析：本质上是“浏览器套壳”应用，缺少 Native 开发。大量写入操作会拖慢 Emacs 的单线程架构。
  • 社区共识与转向：成员 zdn 的总结极具代表性：“老实用 CLI 了”。与其在 Emacs 里嵌入臃肿的 Agent，不如退回到终端中使用 CLI 工具，或者通过 M-x shell 调用 MCP 服务、opencode 等，将 Emacs 视为一个高效、稳定的“远程控制中心”，而非 Agent 本身。这反映了实用主义倾向：Emacs 的强项是文本编辑与交互，而非承担一个运行时臃肿的 Agent Hub 角色。

🔑 关键概念与技术解析

  • 白霜拼音 (rime-frost): 一种基于 Rime 引擎的中文输入方案，以精准的词库和 n-gram 模型著称。近期加入了词频模型，声称可以替代对万象模型的依赖，减少 Lua 性能开销。
  • 万象模型 (rime-wanxiang): 基于统计语言模型 (NLP) 的 Rime 输入法增强方案。通过词频和上下文预测，大幅提升长句整句输入的准确率。争议点在于其严重依赖 Lua 脚本，在部分平台（如 GUIX 打包的旧版 librime）上无法运行。
  • emacs-rime / rimel: 在 Emacs 内直接嵌入 librime 引擎的 Elisp 包，能实现内联编辑（在 Emacs buffer 内显示拼音候选条），从而绕过系统输入法的限制。rimel 被认为是减配/轻量化版本。
  • 内联编辑 (Inline Editing): 指在编辑光标处直接显示输入法候选词列表，而非在屏幕底部的系统输入法窗格中。在 Emacs 的 TUI (终端) 环境下，这一特性极其重要，保证了打字时的视觉焦点和流畅性。
  • MyELPA: 由 Emacs 核心开发者 tarsius 创建的新项目，旨在提供一个比 MELPA 更精简、更易维护的个人/项目级 ELPA 发布解决方案。它能通过 Forgejo/GitHub Actions 工作流自动构建并发布包，降低了创建定制化软件源的门槛。
  • completion-list-mode: Emacs 中一个相对“冷门”的模式，用于展示补全候选列表。有人刚发现它的存在，暗示该模式的绑定或激活机制较隐蔽。

💎 碎片知识与金句拾遗

  • AI 写配置的痛点：“我不想再看着 ai 帮我写的一大堆 elisp 然后搞不懂在干什么了… 直接让它把最核心的配置写到 org 里面吧，后面我直接接手修改了，就不让它碰对应的组件了。” (这句非常传神，点明了 AI 生成代码的“黑盒”问题与 Emacs 用户的“工匠精神”之间的冲突。)
  • AI 堆代码的现象：“ai堆史是这样的… 不约束，代码马上堆起来。” (简短有力，对 AI 生成质量风险的精炼总结。)
  • 文档与习惯：“我是写了快 4 年还是 5 年的 markdown 了… 这个真是习惯问题了。” (在 Emacs 社区里，承认不用 Org-mode 是件需要勇气的事情。)
  • 终端颜色修复：“TERM=xterm-direct COLORTERM=truecolor emacs -nw 就正常了。” (一个关于 SSH 下 Emacs 颜色渲染错误的精准修复，来自与 Moshi 终端的真实调试过程。)
  • 关于 Emacs 作为 Agent 容器：“吃过 4gb… emacs 特别特别卡… 现在我回到终端里面，老实用 cli 了。” (生动的比喻和直接的结论，确认了当前 AI Agent 在 Emacs 集成中的性能瓶颈。)
  • MyELPA 的设计哲学：“它更加简洁，任何人都能轻松发布自己的 ELPA。与 MELPA 一样使用 Package-Build，但复杂度大幅降低。” (点明了该项目的核心价值——去中心化、降低门槛。)
  • 选择放弃 fcitx5 的理由：“直接集成 librime 一点问题都没有。” (一句话点出了系统输入法框架与 Emacs 之间可能存在的摩擦，以及“回归库本身”的解决思路。)
  • 触屏键盘的创意：“覆盖全屏的、半透明的，可配置按键位置，上下左右滑动。” (零星的几个词勾勒出了理想化、手势驱动的触屏键盘轮廓，与现有任何输入法都不同。)
  • 3DS 上的 Emacs：“我也是 LL🌚… 很猛啊… 这个太变态了吧我去。” (群友对这种极度硬核、极客的实践表达了共同的惊叹。)
  • macOS 混输体验：“macOS 不需要预先指定固定词组… 有的方案效果还是没有 macOS 的好。” (点明了 macOS 原生输入法在混输体验上的一个核心优势——无需用户主动维护切换列表。)
  • Emacs 与 TeX 的捆绑：“大模型只会用 TeX… 电脑上还是不得不安装 TeX 那一堆东西啊。” (一个略带讽刺的观察：AI 正在强化 Emacs 社区与 TeX 的传统绑定。)
  • Windows Emacs 内联输入：“Windows上，这个东西在系统输入法的框里面，大小只有 11px 左右。” (一个令人心疼的细节描述，解释了为什么某些用户追求 Emacs 内的内联编辑方案。)

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

  • rime-frost 的独立 n-gram 模型：这一特性似乎正在尝试替代过度依赖 Lua 的万象模型。其实现原理和实际性能提升值得关注，可能是 Linux 下 Emacs 输入法性能瓶颈的破局关键。 https://github.com/gaboolic/rime-frost
  • MyELPA 项目：核心开发者 tarsius 出品，必然会吸引大量关注。研究其如何实现与 Forgejo/GitHub Pages 的集成，有潜力成为下一代 Emacs 社区分享自定义配置和轻量级插件的事实标准。 https://codeberg.org/tarsius/myelpa/wiki
  • Emacs 内嵌 WebKit 浏览器：有人正在尝试做这一极具野心的项目。虽然当前“卡住了”，但这代表了 Emacs 生态向着全能应用平台发展的一种极致方向。研究其是如何在 Emacs 中利用 WebKit 的，即使仅仅是增加对 web 标准的兼容性。
  • moshi 终端及圆滑滚轮/触屏支持：它是推动 TUI Emacs 触屏化和滚轮体验向前发展的关键。研究 foot 如何将触屏事件翻译为滚轮事件，以及 moshi 作者在适配 moshi 终端和 Emacs 方面的具体工作，可为任何想改造自家终端的人提供蓝图。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“哪个输入法最好”或“哪个 Agent 插件能用”，而是一个更硬的判断：Emacs 适合做控制面，不适合无边界地吞掉所有运行时。

1. 把复杂系统塞进 Emacs，收益常常输给耦合成本

输入法讨论里，rime-frost、万象、emacs-rime、rimel、fcitx5、系统输入法各有优劣，但核心矛盾很清楚：大家想要 Emacs 内联编辑、可控配置、跨平台一致体验；代价是 Lua 性能、字典加载、平台 IM 框架、缓存、卡死、TUI/GUI 差异一起涌进来。

Agent 也是同一个模式。把 agent-shell、gptel agent、Claude Code 这类重运行时直接嵌进 Emacs，看起来统一，实际把高频流式输出、命令调用日志、GB 级内存占用压到 Emacs 的交互路径上。群里“最高吃过 4GB”“输出时 Emacs 特别卡”“老实用 CLI 了”，不是审美偏好，是架构反馈。

2. 真正的 Emacs 化，不是万物内嵌，而是边界清楚

好的工程边界应该是：Emacs 负责文本、结构、命令编排、结果落盘和可审计历史；Rime、Agent、浏览器、终端、WM、触屏键盘这些复杂运行时，各自在更适合的进程或系统层运行。Emacs 调用它们、约束它们、消费它们的输出，而不是替它们承担全部生命周期。

所以“直接集成 librime”“在 Emacs 里开终端接 opencode/MCP”“WM 集成 on-screen keyboard”这些看似分散的想法，其实都在逼近同一个原则：把能力接进工作流，而不是把世界塞进 buffer。

3. 可验证的判断标准很简单

不要问“这个方案酷不酷”，问四个指标：首次可用延迟、持续输入延迟、峰值内存、故障隔离。输入法方案如果准确率高但每次启动多十几秒、偶发卡死，就还没工程闭环；Agent 方案如果回答好但流式输出拖死编辑器，就应退回 CLI/外部进程；触屏 Emacs 如果依赖终端把触摸翻译成滚轮事件，那兼容性边界就必须写进设计文档。

可继续实践

做一个“Emacs 控制面”实验：Agent、Rime、触屏键盘全部外置进程化，只通过稳定协议与 Emacs 交互；记录延迟、内存、崩溃恢复和跨平台差异。能被测量的架构，才配被长期使用。

Emacs 轻聊讨论组

好的，这是为您整理的本次群聊知识摘要：

🎯 核心热点与专题探讨

【专题】AI 辅助开发的代码管理与 Harness 设计

本日群聊围绕 AI 辅助编程（特别是 Vibe Coding）下的代码管理展开了深度讨论，核心痛点在于当前的 Git 工作流无法完美适配 AI 生成的、频繁迭代的代码。

1. 利用 Git 作为 AI 的“思维痕迹”与 Debug 工具 群友分享了一套精巧的“Vibe Coding 经验”，核心观点是：AI 生成的代码缝缝补补，根源问题难以定位。解决方案是让 AI 每次修改都提交 Git，并写好清晰的 commit message。将功能稳定的版本打上 tag，当后续开发破坏功能时，让 AI 对比当前代码与稳定 tag 的代码，通过分析 commit history 定位引入问题的具体 commit。这将 Git 的审计追踪能力转化为 AI 的 debug 上下文，有效避免了 AI 只写补丁式代码的倾向。该原理被归结为控制论中的“信息传递缩小可能性空间”。

2. jj (Jujutsu) 作为下一代个人代码管理工具 另一位群友提出了一个基于 jj 的 Harness 设计雏形。jj 是一个去中心化的版本控制系统，其核心优势在于：

  • evolog (演化日志): 可以追踪一个 change_id 的修改历史，无论它是否被 rebase 或 amend，这比 Git 的 reflog 更语义化。
  • Workspace 与 Snapshot: 可以精确地捕捉 AI agent 在两次编辑之间，工作区发生的外部修改。
  • Session 即 Workspace: 将 AI 的每一次会话视为一个独立的 workspace，用 jj 的原生 DAG (有向无环图) 和 bookmark 来管理分支。一个模型输入输出（一次交互）就是一个 revision。

这一设计的核心目的是让代码的演进过程（特别是 AI 的介入）以元数据形式被高度结构化管理，而不是像 Git 那样在多次 rebase 后丢失上下文。讨论中，群友们也提到了 git-branchless（jj 贡献者的作品）和 GitButler 作为同类替代品，但普遍认为 gitbutler 侵入性太强且依赖网络。

3. 对 git forge 的反思与探索 话题由 Cursor 发布的 Origin（一个为 Agent 时代打造的 git forge）引发。群友分享了关于 Origin 的片段分析，但其核心观点是机器开始大规模写代码后，真正稀缺的能力不是“写”，而是“判断写得对不对”，这一观点与上述利用 Git 日志进行根源分析的理念高度契合。此外，有人提出了一个看似基础但实际的需求：能否有一个本地使用、可部署到远端的 Git 替代品。经过讨论，大家发现通过 SSH 在远程服务器上建立一个 bare repo (裸仓库)，并在本地进行操作，即可满足单人维护项目时，以远程仓库为“本体”的需求。工具方面，Gitea 和 Forgejo 被提及为可自建的全功能托管方案。

【专题】东南亚华人处境与润学讨论

群内围绕公司搬迁新加坡的计划，引发了一场关于东南亚（尤其是印尼、马来西亚）华人政治处境、社会地位及移民选择的长篇讨论。

  • 核心观点: 在印尼、马来西亚等有伊斯兰政治背景的国家，华人群体被边缘化，难以获取政治权力，历史上被排挤和牺牲（如万隆会议后的出卖）。
  • 具体案例: 提到印尼身份证上不能写中文名，以及马来西亚纳吉布政府利用罗兴亚难民问题转移贪污丑闻。
  • 移民选择: 讨论的终极结论是，养老“最后还得是中国”，因为国内的医疗水平性价比极高。当前世界安稳的选择不多，瑞士、澳大利亚、新西兰被提及，但澳大利亚印度移民数量庞大，可能带来新的社会矛盾。爱沙尼亚作为一个冷门选项被提及，但有群友表示东南亚菜文化无法长期忍受。
  • 观点反差: 有人问能否“润大陆”，被反问者以“华语不好”巧妙化解，凸显了身份认同的复杂性。

🔑 关键概念与技术解析

  • Vibe Coding: 一种重度依赖 AI 辅助（如 Cursor Codex）的编程模式，开发者更关注“构想”与“判断”，而非逐行手写代码。
  • jj (Jujutsu): 一个新兴的、去中心化的版本控制系统，旨在解决 Git 的 UX 问题，支持 auto-squash、灵活的 rebase、更强大的 evolog（演化日志），非常适合管理频繁修改的代码，尤其适用于 AI agent 场景。
  • Harness: 在此语境下，指开发者自定义的一套开发环境和工作流框架，用于更高效地管理 AI agent 的代码产出和迭代过程。
  • bare repo: Git 中一种没有工作目录的仓库，只包含 .git 目录下的核心数据，常用于远程服务器作为中央代码库进行推送和拉取。
  • evolog (演化日志): jj 的核心概念，记录了某个 change_id 下所有修改的演化历史（如 squash、rebase、amend 等），提供了比 Git reflog 更清晰的追踪能力，能还原每一次操作的上下文。

💎 碎片知识与金句拾遗

  • 关于代码规模: “这个是真变态啊，4600万行代码……感觉手写的不超5%。” 评论区用 rustc（本身是单一静态二进制文件）和 clutch (3万行)、majutsu (4.5万行) 进行了对比，凸显了代码臃肿的现实。
  • 关于 Emacs 和 Claude: 群友分享了“软件界的 Emacs 化”博客链接，并讨论了公司禁用 AI 工具（Claude）的现状，有人吐槽“哪个公司会让木马病毒投放公司进来啊”。
  • 关于 TUI Telegram 客户端: “原来tui版本的telega才不能显示头像么……对。” 一个关于 telega.el（Emacs 的 Telegram 客户端）的冷门细节。
  • 关于 ytm-radio 的 PR: 群友优雅地提出一个 Emacs 包（ytm-radio）的功能请求，希望增加一个开关（defcustom）来控制“切歌时是否自动弹出 now-playing buffer”，展现了详细的交互逻辑。
  • 关于 sudo turbostat: 一条用于监测 CPU 功耗、温度、频率和 C-state 的 turbostat 命令被分享：“sudo turbostat --Summary --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,CorWatt,GFXWatt,Pkg%pc2,Pkg%pc3,Pkg%pc6,Pkg%pc8,Pk%pc10,SysWatt”，是硬件级性能分析的利器。
  • 关于 Rime 输入法: 群友提问如何在 Android 端的 trime (同文) 中添加 luna_pinyin 方案，配置与 PC 版相同但无法工作。有人建议找一个跨平台配置（如 ksqsf 的方案）作为参考。

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

  • Fossil: 作为 SQLite 团队使用的版本控制系统，其设计理念（单文件、内置 wiki/bugs）与 Git 截然不同，值得研究其与 Agent 工作流的兼容性。
  • sapling: 另一个由 Meta 开发的开源版本控制系统，关注点与 jj 类似，旨在解决大型代码仓库的痛点，可作为 jj 的备选研究。
  • Gitea / Forgejo: 轻量级、可自托管的 Git 服务，适合构建私有 AI 项目协作的中央代码库。
  • ytm-radio: 一个 Emacs 中的 Youtube Music 客户端，其与 AI agent 代码管理相关的交互设计（如自动展示信息）值得探究。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是 jj 比 Git 好不好，而是一个更硬的判断：AI 编程把“写代码”降价以后，版本控制系统正在从“协作提交工具”变成“判断系统”。谁能更好地记录代码为何变成现在这样，谁才是 Agent 时代真正的基础设施。

1. Git log 不再只是历史，而是给 AI 的约束面

群里那套“每次小修改都 commit，稳定版本打 tag，坏了就和 tag 对比”的经验很关键。它不是流程洁癖，而是在给模型补外部记忆。

AI 写补丁式 helper 函数，本质上是因为它看到的是当前症状，不是演化过程。commit message、tag、diff、bisect-like 分析，把“代码为什么坏”从自然语言抱怨变成可检索证据。这里的工程判断很明确：如果一个 AI coding workflow 没有强制留下演化轨迹，它迟早会退化成堆补丁。

所以“找到根源问题”不是一句 prompt，而是一套证据管线。没有证据，模型只是在表演根因分析。

2. jj 的吸引力在于它把“修改过程”升格为一等对象

群里提到 evolog、workspace、snapshot、change_id，这些点的价值不只是 UX 更好，而是更适合描述 Agent 的行为边界：哪次修改属于哪个 session？两次编辑之间有没有外部变更？一个 change 被 amend/rebase 之后，它的语义身份是否还在？

Git 的模型偏向“最终提交”；jj 的模型更接近“变化如何演化”。而 Agent 工程最缺的，恰好不是最终 diff，而是中间过程的可追责性。因为模型会改、会覆盖、会误读上下文；人真正需要审计的是“它怎么走到这里”。

这也是为什么把 session 视为 workspace 很有张力：它把一次模型交互从聊天记录，变成版本图上的可审计节点。

3. “本地 bare repo 就够了”提醒我们：别把基础设施幻想过度产品化

后面关于远程裸仓库、Gitea、Forgejo、GitButler 的讨论也很有意思。很多 Agent 时代的 forge 叙事听起来很宏大，但单人项目最先需要的可能只是：远端有一个可靠本体，本地可以 push，历史能回溯，断网不死。

工程上要警惕“为了 Agent 时代而 Agent 时代”。如果一个工具引入网络依赖、DBus、强绑定 GitHub，却没有明显提升审计能力和恢复能力，它就是把复杂度换了个包装。

可继续实践的方向

可以做一个最小 Harness 实验：同一项目分别用“Git commit/tag 纪律”和“jj workspace/change_id/evolog”跑一周 AI coding，记录三类指标：定位回归所需时间、误改恢复成本、模型基于历史做根因分析的成功率。别先争论工具信仰，用故障恢复能力说话。