Geekinney

外观

Emacs 社区日报 2026-10-31

约 4889 字大约 16 分钟

2026-10-31

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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：Corfu 补全的“玄学”问题

群内多位成员反映 corfu-mode 会自动关闭，且无明确报错信息。有成员指出可能是配置 hack 或版本更新导致，建议通过 advice 打印调用信息定位问题。讨论中还提及复杂补全可能触发崩溃（提示 C-h e），并有人推测与 vertico 补全框架存在关联。最终有成员提议尝试 Emacs 31 的 completion-preview-mode 作为替代方案。整体反映出补全前端的稳定性仍是 Emacs 配置中的痛点。

专题二：Emacs 图形后端性能对比

围绕 Wayland 下 pgtk 的卡顿问题展开。有成员反馈在 4K 显示器下 pgtk 明显卡顿，切换到 xwayland 的 x11 版本后流畅度大幅提升；但也有成员表示在 Steam Deck 上 pgtk 比 macOS 更流畅，猜测是硬件差异导致。后续引出 lucid（X11 的 GUI 框架）的讨论——有成员表示编译时指定 x11 会自动使用 lucid，且性能“超级好”。此专题折射出 Emacs 在不同图形后端下的兼容性和性能权衡。

专题三：macOS 上的 Emacs 体验

部分成员分享换到 macOS 后的感受：触控板滑动看文件、看 diff 体验爽，但工具链问题（如配置兼容性）仍令人头疼。也有成员表示 macOS 主用 Emacs 很舒服，形成两种不同观点。

🔑 关键概念与技术解析

  • corfu-mode：Emacs 的补全前端模式，通过 corfu-mode 启用，但群内多人遇到其自动关闭且无报错的问题，建议用 advice 追踪调用时机。
  • pgtk：Emacs 在 Wayland 下使用的图形后端，基于 GTK 的纯 Wayland 实现。群内反馈在部分硬件上存在卡顿，尤其是外接高分辨率显示器时。
  • lucid：Emacs 的 X11 GUI 框架（也称为 Lucid/Xaw），是传统 X11 下的轻量级框架。有成员指出指定 x11 编译方式后会自动启用，性能表现优于 pgtk。
  • completion-preview-mode：Emacs 31 引入的原生补全预览模式，被群内成员提议作为 corfu 的替代方案尝试。
  • capf（completion-at-point-functions）：Emacs 补全的核心钩子机制，群内成员提到默认配置下 elisp 补全需要额外设置 capf，否则会卡顿。

💎 碎片知识与金句拾遗

  • “clang 有一點好，可以找到沒有寫的 ;”——指 Clang 编译器能提示缺失的分号，侧面说明 Emacs 配置中代码检查的价值。
  • “美好的一天从早上起来鼓捣Emacs配置开始”——群内常见的“折腾型”用户自嘲。
  • keycast 项目被推荐：https://github.com/tarsius/keycast/blob/main/keycast.el —— 可展示按键操作，但群内成员觉得“没什么好地方安排他”，有的塞进 tab bar，有的塞进 modeline。
  • “svg上要是能直接修改数据就好了”——引出成员正在开发 etaf-org-preview，可在渲染页面直接修改数据，支持实时编辑渲染大文件。
  • “lucid性能炒鸡好”——对 lucid 框架的简单粗暴好评。
  • “mac上沒有一個東西不是魔改的, 或者特供的, 或者沒有合併上游的”——对 macOS 上软件生态的调侃。
  • “最近 vibe coding 多了，连 emacs 配置改得都没那么频繁了”——AI 辅助编程改变了配置折腾的频率。
  • “我的配置都是高度优化了，和 doom 一样弄了很多 hook”——配置工程化的极致追求。
  • “它真的是在养，电子宠物什么的”——指 AI 会记住用户习惯，手动修改反而会破坏其行为模式，像养电子宠物一样。

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

  • keycast：按键可视化展示工具，适合录制教学或演示 Emacs 操作。群内暂无明确用途，但值得关注。
  • etaf-org-preview：群内成员正在开发的 Emacs 包，支持在渲染页面直接修改数据，强调大文件不卡顿，具备实时编辑能力——这是对 org-mode 预览体验的显著增强。
  • Emacs 31 的 completion-preview-mode：作为 corfu 的潜在替代，值得测试其在复杂补全场景下的稳定性。
  • lucid 框架在 X11 下的性能表现：若能在配置中指定 x11 编译方式自动启用 lucid，可能解决 Wayland 下 pgtk 的卡顿问题，值得深入尝试。

观点延伸

中心判断：当天真正值得注意的线索不是“哪个图形后端更快”，而是“我的配置已经完美了”和“corfu 自己关了，没有任何 message”出现在同一段对话里。前者是折腾的终点叙事，后者是它的反证。

1. 静默失败是配置架构的结构性代价。 一个 global minor mode 被谁、在什么时候关掉，在 elisp 里本质上是不可枚举的：hook、advice、包加载顺序、版本更新，任何一环都能改状态而不留痕迹。没有 message 不代表没发生，只代表这次变更没经过可观测的入口。群友建议给 corfu-mode 加 advice，打印调用信息，方向是对的——先让系统能说话，再谈修 bug。任何没有日志的状态机，出问题就只能靠猜。

2. 体感不是测量。 同一天，有人说 pgtk 接 4K 卡到叫，也有人说 Steam Deck 上 pgtk 比 macOS 还流畅。两个结论都可以为真，因为它们测的根本不是同一个东西：分辨率、合成器路径、是否走 XWayland、编译时选的图形后端，全是变量。所以“lucid 性能炒鸡好”是一句有效的个人经验，但不是可迁移的结论。想验证，先把变量钉死，否则只是在交换彼此的硬件运气。

3. AI 代管把“折腾”从表达变成维护。 有人说 vibe coding 多了，改配置的频率明显下降；也有人说 AI 需要记录，手改反而会破坏它的行为，像养电子宠物。这里的代价是真实的：省心换来的是不可解释。当工具顺手 git add -A 把你的手改一起提交，丢掉的不只是干净的 diff，还有“这行是谁、为什么加的”这条信息链。

4. 所以“配置已经完美”更可能是停止观察的决定，而不是技术结论。 像 doom 那样铺 first-file-hook、first-input-hook，前提是你知道自己要优化什么。一旦这个前提消失，“完美”就只是“暂时还没出问题”。

可继续做的一件事： 给配置加一层最小的可观测性——用 advice 记录关键 minor mode 的开关及其调用者，把启动后的 mode 列表和加载耗时存成快照，能 diff 才算“配置变了”。同时在 AI 参与的仓库里，把手改和 AI 提交分开，让“记录”回到 git 历史，而不是留在模型的上下文里。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：LLM 驱动输入法的技术路线之争

群内多位成员围绕“LLM 输入法”展开了深入讨论，核心分歧点在于技术路线与实用性。

  • 模型规模与硬件权衡：有成员指出“0.8B 的确太小了一点，虽然速度更快”，但实际速度差异“是个位数毫秒”，主要优势在于显存占用更小；而“用 CPU 跑就慢非常多了”。这反映了当前 LLM 输入法在端侧部署时对硬件资源的敏感依赖。
  • 双拼 vs 全拼的编码冲突：早期有人设想用 LLM 做适合 Dvorak 布局的两笔输入法，但随后发现“双拼方案是得在模型训练层面固定的”。核心难题在于“如果输入模型接受的是全拼就会有一对多的问题”——全拼编码到双拼的映射存在歧义，难以在推理阶段动态转换。
  • 方案演进：讨论后期，有成员更新了方案，“加了声调标记的支持，不带声调的时候也更准了”，“去掉了对特定双拼的绑定”。这表明他们选择了更通用的全拼输入方案，而非训练特定双拼模型。
  • 词库 vs 模型直出：有成员提出“词库方案对于生僻词比较擅长”，认为“词库还是得以某种方式参与”，但另有人坚持“我的方案就不依赖词库/词典的词频了”，并解释为“模型直出”。这体现了两种截然不同的设计哲学。
  • 硬件兼容性：有成员质疑“必须用 NVIDIA 的 GPU 才可以？”对方回应“肯定不是”，“主要是其他 gpu 我也测不了”。后续提及“可以把模型直接转到 MLX 格式”（苹果芯片生态），显示出对跨平台支持的探索意向。

专题二：Emacs 包管理器的配置权衡

围绕 package-vc、straight.el 和 elpaca 的取舍，群内展开了技术讨论。

  • 痛点：有成员想放弃 straight 和 elpaca，直接用内置的 package-vc，但被指出“自带的没有依赖处理吧”，只“适合小包”。
  • 版本锁定问题：核心痛点在于无法 pin 版本，“没有一个 versions 文件来 pin，除非从下到上都显式指定”。有人提议“自己用变量控制，然后把提交号写到文件里”，但原讨论者认为“就是为了不用手动才用的 straight”。
  • 解决方案：有人分享经验：“只要装好所有直接需要的包，测试没有问题，提交 versions 文件就好。如果每个间接需要的包都要处理版本问题，那是可以可以用 package-vc。”
  • 局限性：有人引用了 Emacs China 论坛的讨论，指出 package-vc 不支持 vc 和本地包的混合管理。

专题三：桌面环境与窗口合成器的“新潮”体验

多位群成员分享了他们对新式合成器（Noctalia、Umbriel、LabWC 等）的尝试体验，并对比了传统 KDE。

  • 新组合：有成员采用“greeter + noctalia + labwc + 自己开发的 keydock”方案，另有成员“也是 noctalia+umbriel 了”。
  • 体验反馈：一位成员详细描述了 KDE 的卡顿痛点（如全屏截图卡 2 秒、开机登录卡 2~3 秒、编辑 panel widget 卡 2~3 秒），并分享了自己切换到新组合后“响应真的很快”。Noctalia 被评价为“包办很多功能”，Umbriel 则“负责透明，模糊，还有排版而已”。
  • NixOS 兼容性问题：有成员反馈此前试用时“大多是跟 NixOS 不兼容的问题，找不到依赖之类的”，但近期观察发现“现在应该好些了，NixOS 群里也有很多人在用了”。
  • 新工具推荐：有人分享了 https://noctalia.dev/ 网站，另一成员表示“看起来不错呀。有空我也要把玩一下”。

🔑 关键概念与技术解析

  • MPTCP (Multipath TCP)：多路径 TCP 扩展，允许单一 TCP 连接使用多个 IP 地址/路径。群内提到的安全漏洞涉及“Linux 内核刚被爆出监听 IPv4 MPTCP 极易被远程拿 root”，且“Go 1.24+ 默认开了 MPTCP”，因此 Xray-core 紧急更新默认关闭了该功能，以减小攻击面。
  • package-vc：Emacs 内置的 VC 包管理器，直接从版本控制仓库（如 Git）安装包。相比 straight.el 或 elpaca，它缺少自动依赖处理，不适合复杂包，且无法精确 pin 间接依赖版本。
  • Noctalia / Umbriel：新一代 Linux 合成器/面板工具。从讨论看，Noctalia 负责系统级功能整合（“包办很多功能”），Umbriel 负责视觉效果（透明、模糊、排版）。属于较新且小众的工具，与 NixOS 有潜在兼容问题。
  • LLM 输入法的一对多问题：若模型接受全拼输入，但用户使用双拼方案，则同一双拼编码可能对应多个全拼序列，导致候选排序困难。解决方向是在训练时固定输入编码类型。
  • wime (github.com/0WD0/wime)：群成员新发布的模型项目，疑似用于输入法领域，已上传至 GitHub。有成员提醒与已有项目 hadsn/WIME 撞名。

💎 碎片知识与金句拾遗

  • 公益细节：有人分享了一次具体善举：遛狗时看到被丢弃的厚褥子和枕头，想起关帝庙的拾荒者（五十来岁，身份证被抵押贷款，无补贴，每天义务打扫小公园），便带老人去取回。“高兴的合不拢嘴”，并感慨“做好事的感觉果然是极爽的”。
  • 模型部署实战：“今天 Racket 是有什么彩蛋吗”“万圣节”——推测 Racket 语言在万圣节有特殊活动或彩蛋。
  • Rust 稳定性评价：“老實講 Rust 寫的程序是挺穩定的”——一语带过，但代表了社区对 Rust 稳定性的普遍认可。
  • GitHub 彩蛋：“github 今天的瓷砖变成金黄色了”，成员互动确认“去年也有这个环节”，暗示这是 GitHub 的年度主题（大概率是 Halloween 或周年庆）。
  • 音乐推荐合集：成员们积极贡献歌单，包括：millsage - odd dice、Tool 乐队（“随便听，就没有难听的”）、Aimer 的《Brave Shine》《Last Stardust》《Kataomoi》、Vaundy 的《Kaijuu no hana uta》、Tokyo Flash、Zutomayo 的《花一匁》。有人推荐“我写代码专用乐队👇”并附上 song.link 链接。
  • 个人工具分享：“我自己维护了一个配置列表”，有人维护个人音乐播放器（基于 mpv 后端）。
  • 壁纸分享：有人分享新壁纸 https://www.pixiv.net/artworks/124691157，群友表示“我喜欢这个壁纸”。
  • 屏幕缩放经验：某成员为测试 neomacs 的非整数缩放，将 4K 27 寸屏幕缩放调至 170%，后来觉得挺好就没改回来。另有成员在 1080p 24 寸屏上感慨“你用4k屏都不缩放的吗，视力这么好的吗”。
  • Reddit 动态：有帖子在 r/emacs 讨论 neoemacs（“为什么没人谈论 neoemacs”），群里提到“有个 defcustom 能关闭所有动画”，“文档我要更新一下”，体现开源维护者对社区反馈的及时响应。
  • 电影推荐：分享了一部 1966 年西部片《姜戈》（Django），附阿里云盘链接。

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

  1. wime 项目：群成员发布的 https://github.com/0WD0/wime 模型（后续可能用于输入法），值得关注其技术细节（训练数据、模型架构、部署方式）。已有撞名项目 hadsn/WIME，可对比异同。
  2. LLM 输入法的“模型直出”路线：不依赖词库词频，完全由模型直接生成候选。该路线的准确率、推理延迟、部署成本值得跟踪。
  3. Noctalia + Umbriel 组合：新一代合成器组合，尤其在 NixOS 生态下的兼容性已改善。可作为 KDE 的替代方案进行深度体验。
  4. MPTCP 安全漏洞：Linux 内核 MPTCP 监听漏洞，以及 Go 1.24 默认开启 MPTCP 的安全影响，值得扩展到相关系统的安全配置研究。
  5. Emacs 包管理器的 pin 策略：对于不使用 straight.el 的团队，如何通过“直接依赖显式指定 + 间接依赖快照提交”实现可重复构建，值得整理成最佳实践。

观点延伸

中心判断：这天两条看似无关的讨论，问的是同一件事——把不确定性固定在哪一层。输入法是“编码在哪一层固定”，包管理是“版本在哪一层固定”。这一层如果选错，后面的工程努力都只是在补漏。

一、输入法的分水岭不是模型大小，是编码层归谁管

“双拼方案是得在模型训练层面固定的”这句话比表面更重：如果把拼音当作模型的输入字母表，双拼就不再是事后能贴上的东西，而是全拼的一对多映射。而“给每种双拼单独训练也就几分钟，难的是处理语料”，把成本结构说清楚了——算力已经便宜到可以按输入方案复制模型，真正的开销在语料管线。所以通用与专用在这里不是先进性的差别，而是谁愿意重复付出语料的成本。后来“加了声调标记，不带声调时也更准”“去掉了对特定双拼的绑定”，是用更丰富的编码换更少的绑定，同样是取舍，不是白拿的胜利。

二、“模型直出”和“候选修正”是两种产品

有人问“为什么不用候选修正，这样不限制输入法”，答案是“路线不一样”。这几个字很准：候选修正把泛用性放到解码后处理，模型只当打分器；而“模型直出”这条路把语言模型直接摆在把编码映射到文本的端到端流程上。候选修正可以组合，也可以退回到传统输入法；模型直出的上限更高，但会与用户的输入习惯紧密结合。当事人说“追求极致的准确，一开始就没想考虑泛用性”，这是诚实的产品定位，不是技术短板；代价也说清楚了——不是兼容得不好，是没打算兼容。

三、延迟预算决定它还算不算“输入法”

“0.8B 和更大的模型差距是个位数毫秒，主要差异是显存占用”，但“CPU 跑就慢非常多”“得十几秒”。两句放在一起，结论不是选多大模型，而是这东西必须常驻 GPU。击键到候选的预算是几十毫秒量级，十几秒已经不属于同一个产品了，所以“能不能用 CPU 跑”不是优化题，是定义题：它更接近本机的输入服务，而不是能随包分发的输入法。

四、package-vc 缺的不是依赖处理，是 lockfile

“不能 pin 版本”“没有一个 versions 文件来 pin，除非从下到上都显式指定”“就是为了不用手动才用的 straight”——三句连起来指向同一层缺失：它能用 :rev 钉住单个包，但没有“整棵依赖图的一次性快照”，于是每个间接依赖都得手工钉住，自动化又退回了手工操作。“只要装好所有直接需要的包，测试没问题，提交 versions 文件就好”其实已经给出了务实的解法：钉住直接依赖、快照间接依赖。这已经是 lockfile 的思路，只是还没有工具替你生成和校验它。

可继续的方向：输入法那条，可以把编码层和生成层拆开做对照——同一份语料分别用固定全拼、固定单一双拼、不绑定双拼的声调增强编码训练，测生僻词准确率和首候选命中率，看泛用性到底折价多少。包管理那条更小：给 package-vc 写个生成并校验依赖快照的小工具，验证“直接依赖显式 + 间接依赖快照”能不能撑住可重复构建。

（草稿已落盘于 /tmp/opinion.md，可直接拼接进日报；全文约 1100 字，无裸 HTML 或尖括号占位符。）