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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：Doom Emacs 的现状、困境与未来

群内多位活跃用户围绕 Doom Emacs 展开了深度讨论，涵盖了其维护状态、模块质量、社区活力以及未来走向。

• 维护者动态与社区氛围： 多位成员表达了对 Doom Emacs 现状的担忧，认为其社区“死气沉沉”，部分模块“年久失修”。有成员指出，核心维护者 Henrik 仍在活跃，并正在重构 Doom 的核心结构——将原有的“module”拆分成可从 GitHub 独立下载的“community config”，让用户能够自由组合 Doom 的 lib 和 hack 来搭建自己的配置。此举被视为重蹈 Spacemacs 覆辙的应对策略。
• Bug 与体验痛点：
  • Theme 系统存在严重 bug： 有成员反映 doom themes 存在循环依赖的 face 问题，导致用户体验糟糕，甚至萌生弃用念头。
  • Module 功能损坏： 具体实例是 doom 的 rust 模块中集成的 rustic 效果不佳，且 Doom 自己写的与 LSP (eglot/lsp-mode) 交互的 range formatting 功能的逻辑存在缺陷。讨论深入分析了其技术原理：Doom 使用 apeliphia 库，针对 range format 时，会创建一个只包含 range 区域的临时 buffer，但 client 需要在原始 buffer 应用更改，导致逻辑错乱。该问题目前似乎只有部分用户（如发言者）在尝试修复，并通过提交 PR 混代码来实现。
  • 总体态度： 核心观点是“一用一个不吱声，包有东西坏的”。用户倾向于将 Doom 当作自己的私配来“住”在里面，遇到问题就自己修。
• 使用策略与替代方案： 有成员提到可以主动让 AI（如 Codex）扫描并帮助修复问题。也有人推荐了 ef theme 和 modus operandi 作为稳定的主题替代方案。

专题二：Wayland 的桌面生态现状与痛点

讨论围绕 Wayland 在桌面环境（尤其是 Linux 和 SteamOS）中的实用性与兼容性问题展开。

• 主流支持趋势： SteamOS 已正式默认使用 Wayland 桌面。大部分新兴 Linux 用户（如2025年刚入坑的成员）从一开始就使用 Wayland，并声称“真没遇过问题”。
• 现存痛点：
  • 国产软件兼容性差： 这是 Wayland 在中文环境中最大的障碍，包括 wine 运行国产软件经常出现各种问题。
  • Steam 及其游戏生态： 虽然 SteamOS 使用了 Wayland，但 Steam 客户端本身（依赖 CEF）尚未完全支持 Wayland（尽管有消息称 CEF 已合入支持）。Steam 的游戏模式和 Wine 环境仍主要基于 Xwayland。有成员反映以前 SteamOS 内置的菜单栏会花屏，但今年（2026）已有改善。
• 技术细节： 讨论引出了 cef（Chromium Embedded Framework） 对 Wayland 的支持问题，以及 gamescope 作为 compositor 套上 Xwayland 来运行 Wine 游戏的典型架构。

专题三：Emacs Modeline 的定制与探讨

本次讨论涌现了多个关于 Emacs mode-line 定制的技术分享和疑惑。

• 主流方案： 大多数成员使用或推荐 doom-modeline。此外，punch-line 和基于 moody 的配置也被提及，punch-line 被评价为“像 lualine”（Neovim 的流行状态栏风格）。
• 技术细节：
  • 数据流与性能： 指出了 mode-line 的刷新机制：modeline 会定时调用 format 函数。如果 format 的逻辑过于繁重（例如大量 I/O 或计算），会直接导致 Emacs 变卡。解决方案是“把数据做成查询函数”，仅在数据变更时刷新，而非定时全量刷新。
  • Bug 分析： Emacs 31 的 TUI 模式下，modeline 颜色变更后不会刷新颜，而 GUI 模式正常，有成员怀疑这是终端的 bug。其他成员建议通过多更换几个终端来排除是否是配置或终端问题。
  • 个人配置： 有成员分享了自己折腾的“改了一下 modeline”的截图。也有新手遇到了 punch-line 配置后显示异常的问题（例如 echo-area 消息被错误地显示在 mode-line 上）。
• 推荐与避坑： Protesilaos 的简约风 mode-line 风格被提及，但被谨慎评价为“他的代码可能不太健壮”，与其欢迎仪表盘类似。

🔑 关键概念与技术解析

• Range Formatting (LSP)：一种 LSP 协议请求，允许编辑器只对代码中选定的“range”区域进行格式化，而非整个文件。Doom Emacs 的实现存在 bug，因为它错误地创建了一个只包含被选中 range 的临时 buffer 来处理格式化，导致 client 无法将正确的更改应用到原始文件的完整 context 中。
• CEF (Chromium Embedded Framework)：允许将 Chromium 浏览器引擎嵌入到其他桌面应用的框架。Steam 客户端的界面（如商店页、库、设置等）就是基于 CEF 构建的。由于 CEF 对 Wayland 的原生支持滞后，导致 Steam 客户端在 Wayland 下表现不佳。
• Ghostel：一个 Emacs 包，用于在终端中优雅地显示和管理密钥（keybinding）的弹出菜单。此包更新后导致成员出现卡死问题，并且由于它不在 Guix 官方仓库中，需要用户自行打包。
• org-defuddle：一位群友在当天发布了一个个人项目 org-defuddle 的“初步版本”，可能是一个用于整理、清理或解决 Org-mode buffer 冲突的工具。
• ACP 协议：提到了与 agent-shell 支持相关的“ACP 协议”，在本次讨论中其具体含义和用途未展开，可能是指某种跨进程通信协议或 AI Agent 与 Shell 交互的协议。

💎 碎片知识与金句拾遗

• 关于 Emacs 维护与社区： “如果我不工作就好了，可以维护这些东西”
• 关于 Doom Emacs 的 Bug 态度： “要不是我尝试给 lsp-proxy 写一个适应 doom 的 format 函数都没人会发现是坏的”
• 关于 Wayland 的用户体验分层： “国产软件的问题”、“wine跑东西也有问题” vs “我没这个需求”，体现了不同用户对 Wayland 接纳程度的差异源于其依赖的生态。
• 关于 LLM 辅助编程： “直接给我用，我来帮你蹬”、“该请出 codex 大王了”，反映了开发者对使用 AI 工具（如 Codex）进行代码扫描和修复的随意与期待。
• 关于 Emacs Code Review: “review GitHub PR 么？没有好用的，不如网页” -> “感觉没必要都在 Emacs 内做，如果没有好工具的话。”
• 关于 Emacs 的 gptel 扩展： “‘自己复制粘贴就是古法chat…’”，gptel-agent 能免去手动复制粘贴文件内容进行 AI 分析的繁琐步骤，更适合处理整个 codebase。
• 关于 Magit 的更新： 一条引用显示 Magit 已经实现了在 Emacs 内处理某个版本控制操作（具体为 issue 2942 相关的功能），但很多用户包括发言者本人都不知道，直到别人提了 PR 才发现。
• 关于 Doom Emacs 的配置代码复用： “我抄了大量代码”、“说起来有时间要再抄一波 doom 代码了” - 表明 Doom Emacs 虽然部分模块年久失修，但其核心库和 hack 方式依然是 Emacsers 学习与复用的重要来源。
• 关于 Agent 维护包：“那不如直接复制到自己的channel里面，然后让agent维护了” - 反映了在 Guix 等非主流发行版上，用户通过自动化工具（如 Agent）来维护个人包更新的做法。

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

• Doom Emacs 模块拆分为社区配置： Henrik 正在进行的重构。关注点：拆分后的 lib 和 hack 如何单独使用？它们能否独立于 Doom 主线而保持更新？项目地址：https://github.com/orgs/doomemacs/discussions/114
• Emacs 31 的 TUI mode-line 颜色刷新 bug： 这是一个在当前版本中暴露出的前端 Bug，对于开发者和高级用户而言，是值得尝试去排查或上报到 emacs-devel 的议题。
• org-defuddle： 作者刚发布的初步版本。项目地址：https://github.com/LuciusChen/org-defuddle。关注其解决的具体冲突场景与算法。
• gptel-agent： gptel 的一个扩展，增强了 AI 与 Emacs 交互的方式，支持 subagent、规划能力和自动上下文提取。值得深入配置和试用。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题】平铺窗口管理器的触屏困境与未来探索

群内围绕平铺窗口管理器（Tiling Window Manager）的触屏支持展开了持续数轮的深度讨论，形成一个跨越白天到夜晚的完整技术探讨。

• 痛点共识：多位成员指出，当前主流 tiling wm（如 Hyprland）的触屏支持普遍不佳，主要停留在触控板层面（如niri的触控板体验获得好评），而对触屏（手指直接操作）支持不足。
• 成因分析：成员认为触屏逻辑与键盘/触控板逻辑差异巨大（“触屏逻辑肯定很不一样”），传统tiling wm设计哲学是“为了不用鼠标”，而触屏本质上是一种新的交互范式。有成员提出，理想触屏场景是手机串流电脑、或像某些Yoga笔记本那样将键盘折过去，而非在标准笔记本屏幕上操作。
• 现状与尝试：有成员尝试基于 Hyprgrass 插件进行修改（“刚才在尝试基于 hyprgrass 改，发现我想象的有点太远了”），并最终决定“确定要给 niri 做触屏功能了”，认为Hyprland因需要考虑多种layout，复杂度更高。这显示社区正在从“适配”转向“原生设计”。
• 商业信号：有成员提及“果子今年的macbook可能就有触屏了”，暗示苹果的入局可能会倒逼Linux生态跟进。

结论：平铺窗口管理器的触屏支持是当前一个明确的技术缺口，社区开发者正在从插件修改转向自底向上的原生实现，niri可能成为第一个吃螃蟹的轻量级方案。

---

【专题】AI Agent 工具链的“轻”与“重”之争

围绕 opencode 及 claude code 等AI辅助编码工具的讨论，揭示了开发者对Agent工具链“重量”的敏感。

• 轻量的标杆：opencode 的 TUI 实现受到好评（“居然可以直接用鼠标点击选项”），其原作者的新作 crush（Go语言）被认为“4小时还在更新”，活跃度惊人，被定位为“go搞agent无法绕过的靠山”。
• 对“重”的批评：有成员重点批评 claude code：“我觉得其实很多harness框架都过于重了，重点批评claude code”。并提出需要“类似于pi这种更加轻量的”。
• 配置哲学：成员认为“装那么多插件和优化，可能还不如官方预设”，因为“agent更新太快了”，强调在快速迭代的领域应保持工具链的简洁，专注于核心功能。
• 成本策略：讨论中提及“主要是节约经费，同时达到顶级大模型的效果”，并推荐使用 opencode + oh-my-openagent 搭配不同模型。

结论：在AI Agent工具链领域，社区正从“堆功能”转向“做减法”，追求轻量、专注、低耦合的架构。crush 和 opencode 代表了这种趋势。

---

🔑 关键概念与技术解析

• Hyprgrass：Hyprland 的一个插件，用于增强触控板/触屏手势支持。本次讨论中，它是成员试图为Hyprland添加触屏功能的起点，但发现“想象太远了”。
• OPencode / Crush：OPencode 是一个基于终端的AI辅助编码客户端，其TUI支持鼠标交互。Crush 是其原作者用Go语言重写的类似项目，定位为构建Go Agent的底层框架，被视为“无法绕过的靠山”。
• Oh-My-OpenAgent (omo)：一个用于配置和组合不同AI模型的工具，与 opencode 配合使用，以实现“不同模型搭配”的效果，以节约成本。
• ACP协议：Agent Communication Protocol（代理通信协议）的缩写，一种用于不同AI Agent之间标准化通信的协议。成员指出“直接用ACP协议调厂商自己的harness就好”，强调Agents之间的互操作性。

---

💎 碎片知识与金句拾遗

1. 终端看图的双协议之争：foot 终端模拟器使用另一种图片协议（非Kitty协议），导致颜色表现不如Kitty，但“可以看图”。这提醒我们：终端协议的选择（如Kitty vs Sixel/others）直接影响图片渲染质量。

2. 轻量级文件管理器：有人问“你们用过 lf 么？”，lf 是一个用Go语言编写的终端文件管理器，以轻量和vim风格操作著称，是 ranger 的现代替代品。

3. 关于移民的清醒认知：“在祖国是什么阶层，我理解去外国更大概率是降级或保持原状。”—— 虽然是闲聊，但这句对海外迁移的阶级流动分析相当冷静。

4. 苹果的“折叠”图景：有人开玩笑“出个三折叠的 iPad，再出个对折的 iPad 加 Macbook”，讽刺中透露对苹果未来可能整合触屏与笔记本形态的期待。

5. 豆瓣的奇葩登录错误：“就看个韩剧的介绍就要登录，报错还是这个”—— 反映国内部分平台极差的用户体验，甚至无法加载静态内容。

6. AI大会员成本痛觉：“gpt 离谱吧，10 分干我 5h 额度”—— 一个小时的对话烧掉5小时的会员额度，足见高密度使用Agent的惊人成本。

---

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

1. niri wm 的触屏开发进展：成员明确表态要为niri增加触屏功能，这是平铺WM原生支持触屏的开创性尝试，值得跟踪其PR和实现思路。

2. crush (charmbracelet/crush)：这个Go语言编写的TUI框架活跃度极高（4小时前还在更新），它如何支持鼠标点击、如何与AI Agent深度集成，值得所有Go开发者研究。是构建轻量Agent客户端的潜在基础设施。

3. ACP协议在轻量Agent中的应用：成员提到的“直接用ACP协议调厂商自己的harness”，暗示一种无需厚重框架、直接基于标准协议调用厂商能力的思路。可以调研 acp 相关实现，看其是否能解决 claude code 等工具过重的问题。

4. 终端图片协议对比：foot 与 kitty 使用的不同图片协议在颜色准确度和功能上的差异，是终端美化与实用性的一个重要技术细节，可以深入研究。