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

Emacs 中文讨论组

🎯 核心热点与专题探讨

本次群内讨论聚焦于 Emacs 邮件客户端（Gnus / Wanderlust）的配置、使用体验与现代邮件客户端的对比，并延伸出 Emacs 中字体混排（proportional font 与 monospace font）导致的对齐问题与解决方案 等衍生话题。

【专题】邮件客户端的现代化探索：从 Gnus 到自建邮件 daemon

这是群内讨论最持久、最热烈的主线话题。核心痛点集中在：

• 配置繁琐： 成员 κόσμος 抱怨 Emacs 内置的 Gnus 在配置 SMTP、IMAP、indexer 时体验不佳，尤其是 对 multi-account 的支持很差，且 indexer 对中文支持不友好。
• UI 与交互： 部分成员认为 Gnus 打开时加载较慢（“卡几秒”），但 κόσμος 反驳这很正常，并将 读邮件列表/新闻组比作“上论坛”，强调其强大的 thread 层次结构对于长期讨论的价值，这一点优于 Thunderbird 和 Apple Mail。
• 异步 vs 同步： κόσμος 指出“电子邮件是异步通信，IM是同步通信”，发邮件不会期待对方立刻回复，这是邮件与 IM 的本质区别。有成员反驳说 IM 也未必立刻回复，但 κόσμος 认为技术上可做，功能与习惯上截然不同。
• 现代化尝试： κόσμος 表达了想要构建一个 更现代化的邮件客户端 / email daemon 的意愿，认为现有的 UI 虽好，但配置和扩展性不足。他提到可以复用自己之前的 disco.el、emacs-qq 和 chirp 等项目组件。
• 跨平台开发： 有成员分享开发 iOS 邮件 app 的经验，指出“iOS app 我精心打磨了一周，安卓照着抄就行了，全抽象出来了”，认为代码复用对 AI 编程来说能“加快一点点开发速度”，但也有成员认为“对 AI 来说只是加快一点点”。

结论与方案：

• Gnus 配置： κόσμος 分享了自己的配置方案，如通过 (nntp "nntp.lore.kernel.org") 阅读 Linux 内核邮件列表，并使用 S W 进行 wide-reply（回复全部人）。他将自己的配置归功于“抄快佬的”（ksqsf），并引用了相关配置仓库。
• 替代方案： 有成员推荐 MailMate 作为 macOS 上的原生客户端，也有成员尝试 Fastmail，甚至想“自建”邮件服务。
• 优化技巧： 针对 Gnus 的显示问题，成员分享了禁用笑脸图片、启用 emoji 替换等技巧，并推荐使用 mixed-pitch-mode 来统一管理字体对齐。

【专题】Emacs 字体混排的对齐问题与解决

这是一个具体的技术难点，源于在 Gnus 等模式中启用 variable-pitch-mode 后，行号区域因使用了比例字体而错位。

• 问题描述： 行号与正文无法对齐，如截图所示“31行明显向右偏了”。
• 解决方案：
  1. 手动设置行号字体为等宽字体：通过 set-face-attribute 将 line-number 和 line-number-current-line 的 :inherit 属性设为 'fixed-pitch。
  2. 使用 mixed-pitch-mode 更方便地实现类似效果，该模式会自动处理比例字体和等宽字体的混排。
  3. 讨论中还提及了 vui.el 项目（一个基于 textui 的 Emacs UI 库），群友正在推动其使用 textui 中的自动布局部分作为共用库，以彻底解决对齐问题。

🔑 关键概念与技术解析

• Gnus / nntp： Gnus 是 Emacs 内置的新闻与邮件阅读器，通过 nntp 协议可以订阅新闻组（如 news.gmane.io）或 Linux 内核邮件列表（nntp.lore.kernel.org），无需订阅即可阅读和回复。
• gmane / gwene / yhetil.org： 这些是邮件列表的网关/存档服务，将邮件列表转换为 nntp 新闻组。群友提到 yhetil.org 比 gmane 更稳定，但 gmane 和 GNOME 项目无关。
• wide-reply (S W)： Gnus 中回复邮件的一种方式，默认 r 仅回复当前消息的发送者，而 S W 会回复当前消息的所有收件人（即“回复全部人”）。
• treesit-auto： Emacs 的 tree-sitter 集成自动化包。群友 zdn 指出 Emacs 31 的内置行为（打开文件询问安装）与 treesit-auto 类似，但他通过手动判断实现了“已安装则启用 ts-mode，否则回退普通 mode”的静默切换，不需要 treesit-auto。
• child frame： Emacs 中的一种 GUI 技术，可以将 minibuffer、echo area 或 message 显示到独立的子窗口中。群友 zdn 开发了 minibuffer-frame 包，将整个 minibuffer 移到 child frame 上，但存在焦点切换问题。
• mixed-pitch-mode： 一个简单的 Emacs 模式，用于同时启用 proportional font 和 monospace font，并自动处理对齐，常用于 Org-mode 等场景。
• emacs-macport： 一个第三方 Emacs macOS 移植版，群友讨论其是否已不再依赖 Carbon API，但指出每次 Emacs 更新后仍需适配。

💎 碎片知识与金句拾遗

• “xref 居然没有 fallback 机制”： 有成员对 xref（Emacs 的交叉引用框架）缺乏 fallback 机制表示惊讶，而 doom 已经实现了相关功能。
• “保存后是没了，但又会拉一个后缀为～的备份文件。😄”： 吐槽 Emacs 的备份文件机制。
• “用 Emacs 后就不习惯经常检查邮箱了，害我错过好几个重要邮件😇”： 真实体验分享，解释为何会错过邮件。
• “我现在看 bug 编号，gnus 跳转不到对应的编号”： 指出 Gnus 在阅读 bug 编号时的局限性。
• “average 邮件客户端发出来的邮件都是 html 混合 plain text 或者纯 html 格式，没找到选项如何发 plain text 邮件”： 对现代邮件客户端默认发送 HTML 邮件的不满。
• “群里 59% 的人用的原生键位，29% evil，19% 用的 meow”： 群内使用不同 Emacs 键位体系的用户比例统计。
• “sort-regexp-fields 的 docstring 怎么这么抽象”： 对 Emacs 内置函数文档的吐槽。
• “这中文是什么字体😳”： 有人询问截图中使用的字体，答曰“方正柳公权楷书 简繁”，个人免费使用，商用需授权。
• “先发一个‘在吗’建立会话”： 戏谑 IM 的交互习惯，类比 TCP 握手。
• “在的，你在吗”： 回应上述调侃。
• “你发出来的话，我想一会你的仓库会多出一个光芒万丈的 star”： 群友调侃分享配置会获得 star。
• “我这个对 fido 的支持只是顺带的，我是把 minibuffer 一整个弄到 child-frame 上了”： zdn 解释其 minibuffer-frame 的设计思路。
• “buffer 的名字前面加一个空格就会被隐藏起来”： 分享了一个隐藏 buffer 的小技巧。
• “为粗糙的安卓应用带来了审美的提升”： 自嘲开发安卓应用的 UI 设计。

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

• zdn 的 minibuffer-frame 项目： 将 minibuffer 放入 child frame 的尝试，目前支持 C-x o 切换 buffer，但存在焦点问题。其思路可作为 Emacs 单窗口/现代 UI 优化的参考。https://github.com/zHaOdANiuu/minibuffer-frame
• vui.el 项目及其与 textui 的结合： 旨在统一 Emacs UI 布局，解决字体对齐等问题。群友正推动其使用 textui 的自动布局部分作为共用库，这是 Emacs UI 现代化的重要尝试。https://github.com/d12frosted/vui.el
• “更现代化的邮件客户端”： κόσμος 想构建 email daemon，并计划复用 disco.el、chirp 等项目组件，这一方向值得跟踪。
• Emacs 31 的 treesit 自动安装行为： 群友 zdn 通过手动判断实现静默切换，这可能是比 treesit-auto 更优雅的配置思路。相关 issue: https://github.com/renzmann/treesit-auto/issues/135

观点延伸

当天最值得咀嚼的，不是“Gnus 好不好用”，而是一个更具体的判断：邮件客户端真正难做的地方，不在于把邮件显示出来，而在于同时处理通信语义、讨论结构和注意力节奏。把“读邮件列表/新闻组”看成“上论坛”，以及“电子邮件是异步通信，IM 是同步通信”，其实已经指出了两套不同的数据模型。前者需要稳定的 thread、引用关系、跨列表浏览和公开回复；后者更在意即时状态、会话连续性和低延迟反馈。

1. 现代邮件客户端首先应该是一个可靠的中间层

群里提出的“email daemon”方向是对的，但重点不应是再做一个更漂亮的 Gnus UI。Gnus 的优势已经说明：只要 thread 结构和邮件列表入口足够好，老 UI 也能支撑长期讨论；它的痛点则集中在 SMTP、IMAP、indexer、多账号和中文支持这些基础设施上。

因此，合理的拆分应该是：daemon 负责同步、索引、账户隔离、协议适配和 thread 重建；Emacs、手机或其他客户端只负责不同的阅读界面。disco.el、emacs-qq、chirp 之类已有组件的价值，也不只是“让 AI 少写一点代码”，而是已经沉淀了事件、消息、会话和 UI 交互的边界。真正值得复用的是这些边界，而不是复制某几个界面组件。否则项目会很快变成“多个客户端共享一堆半抽象代码”，协议故障和状态同步仍然各自处理。

2. Emacs UI 的难点，其实是隐藏的不变量

比例字体导致行号错位，看起来只是给 line-number 设成 fixed-pitch 的小修复；child frame 的焦点丢失、other-window 返回错误 buffer，则暴露出同一个问题：Emacs UI 不是一组可以随意拼接的视觉效果，它依赖字体宽度、窗口几何、frame 生命周期、焦点和 buffer 切换之间的隐含契约。

所以 mixed-pitch-mode 的价值不只是方便，vui.el 推动复用 textui 的自动布局也不只是“做得更好看”。它们是在把这些隐含契约显式化。相反，直接 hack other-window 或在 minibuffer-frame 里补一层特殊行为，短期能证明想法，长期却容易破坏其他包默认依赖的语义。能否在 GUI、TUI、失焦、dead frame、递归 minibuffer 和 C-x o 下保持同样行为，比截图是否漂亮更能说明方案是否成熟。

3. 可继续研究/实践

可以做一个极小但完整的验证原型：接入一个普通邮箱和一个邮件列表，先不追求完整 UI，只验证四件事：多账户同步是否隔离、thread 是否稳定、纯文本回复和 wide-reply 是否可靠、索引对中文是否可用。UI 侧则建立一组回归场景，覆盖 mixed-pitch、行号对齐、child frame 失焦、message 显示和 other-window。如果这些边界先被测试固定下来，后面的 Emacs、手机和 Android 客户端才是在共享模型上演化，而不是继续堆新的配置和 hack。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题：窗口管理器的哲学之争 — hyprland 与 niri 的深度对比

群内展开了一场围绕当下最热门的两款 Wayland 合成器（hyprland 与 niri）的激烈讨论。这不仅是技术选型之争，更是对窗口管理“哲学”的探讨：hyprland 强调复杂且强大的功能拓展，而 niri 则追求极简模型与纯粹的人机交互。

• 赞助与生态：hyprland 获得 Omarchy 的赞助，有群友感叹“有钱真好啊”，并提到其核心开发者 Vaxry 年仅 23 岁。相比之下，niri 的作者 YAlTeR 更显“技术极客”气质，同时是著名 Minecraft 模组 MouseTweaks 的作者。
• 配置与拓展性：hyprland 已全面转向 Lua（0.55 版本），其配置和 IPC 调用均支持 Lua，拥有一套复杂的拓展系统。而 niri 则坚持更简单的模型，被群友认为“更容易维护”。
• 核心功能对比：
  • 特殊工作区：hyprland 支持通过 Win + S 呼出特殊工作区，并可通过配置将特定窗口固定（pin）在该工作区，且该工作区可叠加在当前工作区之上。niri 不支持 pin 窗口，导致切换工作区时，诸如 waylyrics 等悬浮窗口无法跟随。
  • 多显示器模型：hyprland 不支持将每个显示器识别为独立工作区，而是将其作为当前工作区的扩展。niri 则采用了不同（群友更偏好）的模型。
  • 展望：群友指出 niri 目前欠缺色彩管理（需上游支持）和特殊工作区功能（作者兴趣不大）。
• 痛点与解决方案：讨论中一位群友分享了他对 hyprland 特殊工作区的改良脚本，可以实现浮动窗口在屏幕中央弹出（类似下拉终端），比默认的“分屏式”呼出更灵活。他还指出 hyprland 特殊工作区依靠 tag 而非 classid 识别，若其中有多个窗口，聚焦目标不确定，需手动切换。

专题：Nix 生态的混乱与 Guix 的“洁癖” — 发行版意识形态与现实成本

群友对 NixOS 社区的现状表达了悲观情绪，并探讨了迁移至 Guix 的可能性与现实阻碍。

• NixOS 社区危机：群友指出 NixOS 社区“一片混乱，天天打嘴炮”，nixpkgs 的 reviewer 个人标准过多且主观，导致贡献者不愿提交 PR。社区前领导辞职后仍留任并持续遭受攻击。
• Guix 的乌托邦与现实：部分群友转向 Guix，赞赏其社区“很有共识”，并认为比 NixOS 更有前途。但 Guix 的官方仓库限制严苛（如拒绝非自由固件），导致 npm 生态几乎空白，必须通过配置第三方 Channel（如 nonguix）和自维护来解决。这被群友形容为“洁癖”，迁移成本极高。
• 观点：群友普遍认为 Arch 的“小且可定制”是其优势，而 Guix 的自由软件意识形态则是一把双刃剑。

🔑 关键概念与技术解析

• 特殊工作区（Special Workspace）：Hyprland 等合成器提供的一种临时工作区，可随时通过快捷键（如 Win+S）呼出，通常用于放置聊天软件等需要快速访问的窗口，不干扰当前的主工作区。
• Omarchy：一个赞助 Hyprland 项目的商业公司或组织，此次赞助引发了关于开源项目商业化与独立开发者生存模式的讨论。
• multiseat：一种允许多个用户（键盘/鼠标/显示器）独立操作同一台主机的配置方式。niri 作者对实现此功能不感兴趣，但群友表示非常关注。
• Telega-bridge-bot：用于在 Telegram 与 Matrix 等平台之间桥接消息的机器人。群友通过修改 elisp 配置中的 defcustom 过期时间（3600秒）来解决重启后反复提示输入密码的问题。
• JMAP：一种现代、开放的邮件传输协议。群友在尝试自建邮件服务器（stalwart）时，萌生了开发一个基于 JMAP 的 native 邮件客户端的想法。

💎 碎片知识与金句拾遗

• 硬件选购经验：群友购买二手 ThinkPad T480 (i5-8250U) 花费 2000 元，认为其“最适合 Linux”，而 i7 版本存在散热问题。也有群友吐槽自己的华为轻薄本无法扩展内存。
• 终端模拟器推荐：在讨论 ghostty 处理 SSH 内容有 bug 后，群友推荐了 foot，强调其“速度快、资源管理强”的特性，并提醒“你不在意不能用连字的话，foot 很不错”。
• AI 模型使用吐槽：“最近 gpt 的 goal 好像开始偷工减料，plan 做一半直接摆烂。”、“luna 不开 max 很傻很傻”、“codex + luna 他甚至不看目录内容”。群友普遍反映了 AI 编程工具的不稳定体验。
• AI Token 焦虑：“没有稳定好用的便宜 token 用了额，以后我就是 token 流量汉，哪里有 token 捡去哪里捡一点🫠” — 生动描述了当前 AI 模型 API 价格和可用性波动带来的困扰。
• 镜像站与网络：群友分享 Cernet 镜像站（https://mirrors.cernet.edu.cn/about），被认为是通过 CDN 方式整合高校资源，哪个镜像站近就把流量分配过去。
• 配置安全性：“我一般来说放在 .authinfo.gpg，要开隐私的东西需要在另外一个屏幕的 emacs 打开了”—— 分享通过 Emacs 的 .authinfo.gpg 加密存储敏感信息的实践。
• 开发效率工具：群友分享了一个 Emacs 扩展 minibuffer-frame (https://github.com/zHaOdANiuu/minibuffer-frame)，用于将 minibuffer 弹出为独立 frame，并进行了更新。
• 邮件服务器自建：群友编译 stalwart 邮件服务器时遇到了“第一次遇到 lto 几分钟”的编译耗时问题。

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

• niri 的多显示器模型与特殊工作区实现：niri 采用了与 hyprland 不同的工作区模型，且其作者对某些功能不感兴趣。深入探索 niri 的配置模型，或许能发现其“简单”哲学下隐藏的潜力。
• hyprland 的 Lua 配置生态：hyprland 全面转向 Lua 后，其配置能力和灵活性大幅提升。关注其生态发展，尤其是那些基于 Lua 的插件和脚本，可能是定制窗口管理器的下一个方向。
• Omarchy 对 hyprland 的赞助模式：商业公司赞助开源窗口管理器，这种合作模式对社区发展、功能优先级的长期影响值得观察。
• 基于 JMAP 的 native 邮件客户端：群友因自建邮件服务器而产生此想法。JMAP 协议相比 IMAP 更现代，若能做成一个优秀的客户端，潜力巨大。
• Guix 的第三方 Channel 生态：群友提到有网站可以搜索到很多第三方 channel 的包。这个“生态”若能发展起来，或许能弥补 Guix 官方仓库的不足，成为其超越 NixOS 的关键。

观点延伸

中心判断：当天关于窗口管理器和发行版的争论，实际都在追问同一个工程问题：复杂度应该由系统承担，还是转移给用户和生态？ niri 与 Hyprland 的差别，不只是功能多少；Guix 与 NixOS 的差别，也不只是包数量。长期体验取决于系统能否把高频动作、例外情况和维护责任表达清楚，并稳定地执行。

1. “简单”必须经得起状态转移测试

群里对特殊工作区、pin 窗口和多显示器模型的讨论说明，用户真正需要的不是一个概念漂亮的窗口管理器，而是可预测的动作链：按一次键，聊天、歌词或 Agent 窗口出现；再按一次键，原来的工作状态不被打乱。讨论中提到，Hyprland 的特殊工作区依靠 tag，而非按 classid 精确识别；当其中有多个窗口时，切换后的焦点可能不符合预期。

这暴露的不是一个小瑕疵，而是状态语义的边界：系统知道“这是一组临时窗口”，却未必知道“用户现在要哪一个”。因此，窗口管理器不应只按功能清单比较，而应测试切换后的焦点稳定性、固定窗口能否跨工作区保持可见、多屏布局是否符合心智模型，以及异常后能否用一次动作恢复。简单模型的价值，不是选项少，而是不可解释的状态少。

2. “共识”也会变成维护税

Guix 被认为社区共识更强，NixOS 则被批评评审标准主观、贡献者不愿提交 PR。但两者只是把成本放在了不同位置：Guix 通过严格边界换取原则一致，却让非自由固件、npm 生态和第三方 Channel 成为迁移门槛；NixOS 生态更宽，代价可能是不确定的治理和评审成本。

所以，发行版选择不能只比较理念或包数量，还应记录维护税落在哪里：硬件是否开箱可用、关键包更新速度、是否依赖第三方 Channel、需要自己维护多少包，以及升级失败后的恢复时间。“工作所迫暂时用 Debian”并非缺乏理想，而是对总成本的理性核算。

可继续研究／实践

做一份个人高频路径的对照实验：测试聊天、歌词和 Agent 窗口的跨工作区行为，再用同一套 Emacs、Wayland 和开发工具链比较安装、更新与恢复耗时。把理念转成可复现的动作和维护小时数，才能看清自己选择的究竟是系统，还是一笔将来持续支付的复杂度利息。