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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：ETAF 与 lsp-bridge 的偶发卡死 Bug

群内最硬核的讨论围绕一个由 ETAF（一个 Emacs 文本编辑增强框架）与 lsp-bridge 相互作用引发的严重性能问题。起因是 ETAF 的按键命令是匿名闭包，执行后不会更新 this-command，而 lsp-bridge 的 post-command-hook 会无条件调用 (format "%s" this-command) 来获取命令名。当 ETAF 执行完闭包命令并切换 buffer 后，若返回的 buffer 启用了 lsp-bridge，该 hook 会将闭包内部引用的整个界面对象树（包括 runtime）强制字符串化，导致 CPU 占用满核、内存持续上涨，最终卡死。修复方案已在 ETAF 侧提交 commit 63d6c752，同时向 lsp-bridge 提 issue 建议其增加类型判断，而非无条件格式化 this-command。此问题展示了 Emacs 生态中不同包之间隐含的契约断裂，以及匿名闭包与全局变量交互时的副作用。

补全界面选择：默认 vs. childframe

群友从 company 切换到 corfu，原因是 corfu 支持 childframe，且在 Emacs 31 下 childframe 关闭不再卡顿。但 company 的 childframe 与 tng（company-tng，即“下一个”补全模式）不能直接配合。最终多数人认为默认的补全界面（如 completion-ui 或内置的）已经足够，如果需求不高，默认即可，最多加一个 cape（一个补全后端框架）来增强。

Rust-analyzer 在 lsp-mode 中的异常

有群友遇到 lsp-mode 中 rust-analyzer 显示“LSP 运行正常”，但所有功能（跳转定义、补全等）无法使用，而 pyright 等其他 LSP 则一切正常。讨论中未给出明确结论，但暗示可能是 rust-analyzer 配置或 lsp-mode 与 rust-analyzer 的特定兼容性问题，群友调侃“直接扔给 deepseek 工作模式帮你分析”。

🔑 关键概念与技术解析

• ETAF：Emacs 文本编辑增强框架，提供自定义按键绑定和编辑操作，但会将命令包装为匿名闭包，闭包引用 runtime 和界面对象树。
• lsp-bridge：Emacs 的 LSP 客户端，通过 post-command-hook 在命令结束后执行格式化 this-command，用于获取命令名。
• 匿名闭包与全局状态：ETAF 的按键命令是匿名闭包，执行后不会更新全局 this-command，导致下游包无法正确获取命令名，进而触发错误路径。
• childframe：Emacs 的补全界面以 child frame（子帧）方式弹出，比传统 *Completions* buffer 更轻量，但在某些版本下有性能问题。
• cape：一个补全后端框架，用于为 Emacs 的默认补全提供多种后端（如 cape-dabbrev、cape-emoji 等）。

💎 碎片知识与金句拾遗

• “我开始感觉默认的补全界面好像也能用了”——群友对 Emacs 31 默认补全的积极评价。
• “不是很依赖补全的话，默认的就够用，可能需要个 cape”——简洁实用的配置建议。
• “直接扔给 deepseek 工作模式帮你分析”——群友面对 Rust-analyzer 问题时的戏谑态度，也反映了 AI 辅助调试在社群中的普及。
• “为了规避可能的侵权控诉，决定只发布一个指导 LLM agent 操作的 README.md 和 AGENT.md”——一位群友将 B 站收藏夹转 RSS 的代码转化为“AI 操作指南”，既分享了方法又规避了版权风险，堪称“新时代编码”的实践。
• “因为自己在维护的包越来越多了，需求就会变得越来越小众”——群友自写 modeline 的动机，透露了高级用户的定制化倾向。
• “英国要给非常被买卖的黑人道歉了”——群友分享时事新闻，但与本群技术主题无关，记录以体现社群闲聊氛围。
• “emacs 的这个内置 rss 订阅非常不错”——对 Emacs 内置 RSS 功能的认可，可能是 elfeed 或内置的 newsticker？

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

• ETAF 与 lsp-bridge 的 bug 修复方案：ETAF 的 commit 63d6c752 以及 lsp-bridge 侧的类型判断改进，值得研究如何从框架层面防止闭包泄漏，以及如何为 this-command 设置安全默认值。
• Rust-analyzer 在 lsp-mode 中的异常：虽然未解决，但这是一个典型的 LSP 客户端与 server 交互问题，可作为研究 lsp-mode 诊断机制的案例。
• B 站收藏夹转 RSS 的 AI 操作指南：群友发布 README 和 AGENT.md，指导 LLM agent 实现抓取和转换，这反映了“LLM 驱动的代码生成”在真实场景的应用，可以追踪其思路和实现细节。
• 自写 modeline：群友因为需求小众而自写 modeline，可关注其配置代码，了解如何实现高度定制的状态栏。

---

注意：本日有效讨论集中在技术话题，但部分对话（如英国道歉、默认补全的随意吐槽）包含非技术内容，已按规范保留碎片但忽略闲聊。

观点延伸

中心判断：今天最值得记住的，是两件事同时发生。Emacs 的隐式契约正在被“更自由的写法”持续侵蚀，而它的默认值正在变得足够好。前者制造偶发事故，后者则悄悄改变定制的性价比。

一、(format "%s" ...) 不是取个名字，而是在遍历对象图。 在 Lisp 里把未知值转成字符串，等于要求打印器展开它的整个对象图。lsp-bridge 的 post-command-hook 无条件格式化 this-command，本质上是把“未知输入”当成了“廉价数据”。这类代码在绝大多数情况下毫无成本，直到有人把一棵界面对象树放进了那个位置。判断方法很简单：hook 里对非符号值做字符串化，无异于在热路径上插了一次无法控制的序列化。

二、this-command 是一条没人写下来的类型约定。 命令循环假定它是符号，但语言层面没有任何约束。ETAF 用匿名闭包做按键命令，功能上完全成立，却在契约上违约了：闭包还活着、还引用着 runtime，而下游拿它当名字用。所以修复必须在两边同时做。ETAF 侧已经用 63d6c752 补上了自己那一半；lsp-bridge 侧还该加类型判断。只修一边只是把概率调低，并没有把问题消掉。

三、偶发，才是这类 bug 的真正成本。 触发条件挂在“命令结束后回到的 buffer 是否启用了 lsp-bridge”上，所以它表现为随机卡死。杀伤力不在严重程度，在归因难度：第一反应永远是“Emacs 又卡了”，而不是“某个 hook 在做深度遍历”。经验法则：跨包交互出问题，先查 hook 和全局变量，再查渲染。

四、另一条线：默认值变好，定制的账要重算。 “31 下 childframe 关闭不慢了”“默认补全界面好像也能用了”“因为维护的包越来越多，需求就越来越小众”——三句话指向同一个拐点：定制的门槛已经从“会不会写配置”变成“愿不愿意长期维护”。自写 modeline 不是审美选择，是维护者对自己工作流做的成本核算。

可继续做的一件事： 给自己配置里所有 pre-command-hook / post-command-hook 做一次输入审计，找出会对任意值做字符串化或深度遍历的地方，补 symbolp 守卫；再做一个可量化的小实验：用带长度上限和 print-circle 的打印函数替换掉直接调用的 format，测量格式化一个大型对象图真实消耗多少时间。这个数字会比任何“要注意性能”的告诫都有说服力。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题一】输入法变革：从传统码表到 AI 辅助的整句输入

群内围绕 WIME（Emacs 下的神经网络输入法）展开了长达一整天的深度探讨，并自然延伸到音形码、顶功、并击等输入方案的对比。核心讨论脉络如下：

1. WIME 的体验与痛点

• 群友尝试将默认输入法切换为 WIME 进行日常使用，整体准确率较高，但存在多个待改进点：
  • 整句输入后的延迟：神经模型解码时，首次预测需要等待数百毫秒到半秒以上。群友指出"100ms 你就能感知到"，即使降低 beam size（wime-neural-beam 到 16）也只能有限缓解。
  • 候选词列表问题：当用户输入完整双拼编码后（如 qqvi），不会显示新的候选词，导致"求职"和"求值"这类同码词无法切换。解决方案是使用辅助码（如 qqviR）来消歧。
  • 首次预测正确率：有人发现加入神经模型解码后，首次预测的正确率反而不如纯词组解码，推测是因为词库解码路径更成熟，而神经模型可能需要加入 ngram 数据才能改善。
  • 候选项数量不可调：默认一口气显示 10 个候选，后来发现可用 wime-candidates-max 调整。
  • 中英混输处理：群友坦言"中英混输的处理还是不对，要更正确处理得进一步训练"。
  • 右文（下文）支持：有人问能否利用聊天记录的下文来改善预测，作者回应"广义上的右文我都没加入上下文"。

2. 输入方案设计的哲学之争

这场讨论逐渐上升到理论层面：到底什么样的输入方案才是"版本答案"？

• 顶功派：认为顶功（编码式选重，每个字对应唯一编码）体验最好，上手成本最低，精度 100%，容易形成肌肉记忆，字均码长仅 2.4。但反对者指出：肌肉记忆会流失，顶功解决不了自造词和长词问题。
• 音形整句派：强调"音形顶功"是版本答案，因为常用字走简快码没有心智负担，整句挂接解决长词问题，句中辅助码解决造词问题。核心观点是"输入节奏要和思考逻辑单元匹配"。
• 关键洞察：一位群友总结道："击键不快的时候，击键重要；击键快了才码长重要。" 另一位群友分享了自己设计并击输入法的经历，速度可过 70 字/分，但承认"并击优势不大，击键只能到 3"。

3. 布局绑定问题

有群友提到顶功没有专门为 Dvorak 布局设计的版本，作者回应布局与输入方案的关系："每一套输入方案其实都不需要和特定的键盘布局绑定，只是设计阶段可能受英文键盘布局影响。" 另有人指出 Dvorak 左手的 aoeui 五个元音全在左排，对音形码的排布有潜在影响。

【专题二】包管理器之争：Nix 的困境与 Guix 的"更优设计"

晚间讨论转向 NixOS 与 Guix 的对比，氛围逐渐升温：

• Nix 的痛点：

  • Nix 语言被批为"太垃圾"，"nix 就是 json with lambda then you could write bash"。
  • 打包涉及大量 bash 脚本，"各种 bash 脚本组合起来就是意大利面"。
  • nixpkgs 中每个 package 的打包定义都很长，且可能没有暴露所有选项。
  • 当某软件不在 nixpkgs 中时，"大概率就是不好打包，然后会很折磨"。
  • 有群友表示两台 NixOS 电脑都准备换掉。

• Guix 的辩护：

  • 支持者认为 Guix 用 Scheme（Guile），"是正经的语言"，"lambda 是一眼能看到的"，"报错也正常一些"，对 Emacs 用户尤其友好。
  • 一个犀利观点："AI 时代，更重要的不是生态，而是设计。要先有好的架构设计，然后生态用 AI 来补齐，就比较容易。"
  • 有群友分享了一个 macOS 上折腾 Guix 的 gist 链接。
  • 折中方案："你可以装个 nix 用来跑别人的项目，如果一定要 nix，但是别学他"。

• 反思的声音："很多 nix 要解决的问题，不用 nix 就不是问题。linux 里面开个新用户效果一样好。" 这句话也被认为同样适用于 Guix，最终有人指出"应该用 debian"。

【专题三】离线 AI 代码补全与 Tabnine 的现状

凌晨时分有人询问 Tabnine 被收购后的本地离线方案，午后确认"离线 tabnine 补全跑通了"，用的是最老的 4.31.0 版本。核心讨论：

• 旧版 Tabnine 本地二进制（Linux）在新版中已不再开放个人使用，收购后转向企业付费模式。
• 有群友认为现代场景下"性能好的可能还得是云端模型"，而尝试本地补全的动机是"重新体验下本地 AI 补全的感觉，和 codex 不冲突"。
• 早期痛点：老电脑跑 company-tabnine 资源占用太高，当时内存 24G 不够玩。
• 有人问是否有其他更现代的 Emacs 本地方案，但未得到明确答复。

【专题四】Mac 硬件、游戏与 Linux 的跨界体验

讨论硬件价格时发现 Mac Mini 有性价比（拼多多国补 4~5k 可入 16+256），但内存"金子一样"，32G 不够用、64G 太贵。有人考虑入 M4/M6，被建议"M6 更好，因为苹果系统更新大概 5 年"。

游戏方面，群友分享 Linux 上的游戏体验：

• 用 Proton 跑通了《巫师 3》《天国拯救 2》《黑神话：悟空》《沉星之序》等正版 Steam 游戏。
• 只要没有反作弊检查，Proton 基本都能跑，效果就看运气。
• 但 Linux 上打 LOL 仍不行，Windows 虚拟机可行。
• 有 NixOS 用户发现 5090 的机器在 NixOS 下 DLSS 打不开，打算换成 Debian。

🔑 关键概念与技术解析

• Tabnine 4.31.0：Tabnine 被收购前最后的本地离线可用 Linux 二进制版本，群友确认该版本可离线跑通代码补全，新版本已转向企业付费。
• WIME：Emacs 下的神经网络输入法（作者在群内），支持整句预测、辅助码、神经模型解码，配置项包括 wime-candidates-max（候选数）和 wime-neural-beam（beam size，影响延迟）。
• 顶功：一种输入法编码策略，每个汉字有唯一编码，通过编码本身完成选重（消除重码），无需额外确认。特点是编码短、精度高，但需高强度训练维持肌肉记忆。
• 并击（chorded input）：一种键盘输入技巧，多个按键同时按下表示一个字的编码，类似弹钢琴。群友自述用两笔三码方案（左手形、右手形），速度可过 70 字/分。
• WIME-neural-beam：WIME 神经解码的 beam search 宽度，降低此值可减少延迟，但可能影响准确率。
• Proton：Valve 推出的 Windows 游戏兼容层（基于 Wine），使 Linux 可直接运行大量 Steam 游戏。
• Guix / GNU Guile：函数式包管理器及操作系统发行版，用 Scheme 语言定义配置，被视为比 Nix 更"干净"的架构设计。
• jj (Jujutsu)：现代版本控制工具，解决多 Agent 并发修改仓库时"爆金币"的问题，可在不开 worktree 的情况下高效管理多个变更。

💎 碎片知识与金句拾遗

• 有人讨论 C 语言里 #define JSON(...) #__VA_ARGS__ 宏直接写字面量是否有问题，群友认为"LLM 说有问题，但我感觉没有"。
• 关于远程 Agent："我再也不诋毁远程 agent 了，今天拿着笔记本在外面跑了一天就发现问题了，这个时候根本没办法跑 agent。" 远程环境还能提供更好的测试隔离。
• "把上文从 64 字符扩展到 1024 字符，准确率还能有明显提升"——语境信息对预测模型增益显著。
• 有人评价 B 站评论区是"不错的长文本来源"，适合训练中文模型。
• 关于 WIME 的独特体验："打完之后，等它自己把不对的地方纠正"，只要纠正速度够快就不影响使用。
• "顶功就是编码式选重"，"顶功本质上是超大字根"。
• "肌肉记忆是存储到大脑的神经通路，但是这个玩意是有上限的，一段时间没有高强度使用就要重新复训。"
• 关于中文模型训练："这中文也太逆天了，这些模型真的不用中文做训练嘛"（指模型输出的中文质量差）。
• 有人提到 hackertube 网站（视频源来自 HN 推荐或评论），首页就看到 Emacs 和 Chez Scheme 的内容。
• Telega 的 decline all 有上限 100 个，需操作两次才能处理完 123 个。
• "AI 用来逆向很好，写代码一坨"——群友的直白评价。

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

1. 离线 Tabnine 本地补全方案：Tabnine 4.31.0 二进制已确认可离线运行，可作为 Emacs 本地补全的参考路径。值得跟踪是否有 fork 或社区维护的新版本。
2. WIME 的神经模型解码优化：当前瓶颈在延迟和首次预测准确率，作者计划开放 benchmark，值得关注后续版本如何改进 beam search、ngram 集成与右文支持。
3. Guix 在 macOS 上的部署方案：gist 分享了一个折腾路径（Juke34/76d6427...），对于想尝试 Guix 的 macOS 用户有参考价值。
4. 并击输入法的跨平台设计：群友自研的"任意一键抬起即进入下一轮"方案，突破了传统并击"所有按键松开才继续"的限制，具备进一步开发的潜力。
5. jj (Jujutsu) 在多 Agent 协作场景下的价值被多次提及，Emacs 已出现社区方案 Majutsu，值得跟进其在 AI 编程工作流中的应用。

观点延伸

<｜｜DSML｜｜ calls> <｜｜DSML｜｜ invoke name="write_file"> <｜｜DSML｜｜ parameter name="content" string="true">import re t = open('/tmp/reflect_draft.md', encoding='utf-8').read() cjk = re.findall(r'[\u4e00-\u9fff]', t) print('cjk', len(cjk)) print('total', len(t)) print('angle', [x for x in ['<', '>'] if x in t]) </｜｜DSML｜｜ parameter> <｜｜DSML｜｜ parameter name="path" string="true">/tmp/check_len.py</｜｜DSML｜｜ parameter> </｜｜DSML｜｜ invoke> </｜｜DSML｜｜ calls>