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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题 1：Emacs 生态的“野蛮生长”与炫技式开发

今天的聊天记录充斥着令人惊叹的创造力，几位核心群友展示了将 Emacs 推向视觉与交互极限的独立项目。

• EMMS 的 iTunes 风格界面重制：

  • 一位群友 (@roife 在相关讨论区) 正在用 Codex “vibe” 一个全新的 Emacs 多媒体播放器界面包，旨在为 emms 提供一个类似 iTunes 的强大 UI。
  • 进度惊人：已实现专辑网格视图、表格视图和“正在播放”三种 UI，并加入了可鼠标点击的进度条、滚动歌词以及页面切换功能。
  • 代码量从 Codex 生成的 2000 行被压缩至目标 < 1000 行，体现了对 Elisp 代码质量的追求。
  • 引发了关于 UI 设计哲学的讨论，如使用 child frame、参考 agent-shell 的想法，以及是否需要矩形选中高亮来增强交互。

• 触屏键盘与 Emoji 渲染的深度定制：

  • @κόσμος 在攻克 Emacs 的 Emoji 渲染难题，制作了复杂的 Emoji 合成规则表，并解决了大部分错位问题（尽管仍受 WezTerm Bug 的影响）。
  • 展望了更深层的系统集成：计划让 Emacs 能够读取 OTF 字体自身的 composition rule。
  • 同时，@κόσμος 正在开发一套可由用户通过 SVG 自定义的 触屏键盘，并考虑了不透明和带有动画效果的渲染方案。
  • @zdn 从编译选项入手，发现用 --with-pdumper=yes 编译 Emacs 导致首次启动时间变慢一倍，并探讨了从 elisp 层面关闭该特性的可能性。

• Git 忽略文件的 Dired 着色方案：

  • @zdn 提出了一个痛点：以 $ 开头的文件名会在 dired 中因排序而跑到列表顶部，令人困惑。
  • 分享并展示了其优雅的解决方案：一段简短的 Elisp 代码，它能读取当前项目的 .gitignore 规则，并直接在 dired 缓冲区中对被忽略的文件进行着色，使其视觉上变灰（dired-ignored）。

🔑 关键概念与技术解析

• xdg-desktop-portal (FileChooser)

  • Linux 下为解决不同桌面环境组件碎片化问题而生的 Portal API。通过配置 ~/.config/xdg-desktop-portal/portals.conf，可以强制所有遵循该标准的应用使用统一的文件选择器（如 cosmic 或 gnome 的），解决了群友 @zdn 认为 Linux 没有通用文件选择器的历史认知痛点。

• Stacked PR / 邮件列表补丁工作流

  • 一种向大型开源项目（如 Emacs）提交代码的最佳实践。核心理念是“一个补丁/PR 只解决一个问题”。如果多个功能之间存在依赖关系，则使用 Stacked PR。这本质上是 Gerrit 等工具从邮件列表工作流中继承和扩展的范式。

• Variable Fonts (可变字体)

  • 区别于简单的“伪粗体”（坐标变换/拷贝叠加），可变字体技术通过插值算法，在多个主字体之间生成连续的变体。它拥有单轴或多轴（如字重、宽度），由两端控制变化范围，其他锚点控制变化速率。Knuth 在 1979 年提出的 Metafont 是其思想源头。群聊中提及 Iosevka 作者认为当前技术仍不够强大。

• Emacs 分页符 (^L)

  • @zdn 分享的 Elisp 代码组织技巧。在源代码中使用 ^L (Form Feed) 字符作为段落分隔符，配合 C-x [ / ] 键位可实现快速段落跳转。他将此方法与 defclass (EIEIO) 结合，让 Codex 生成的冗长代码变得模块化，每个段落不超过 300 行。

💎 碎片知识与金句拾遗

• Emacs 文件管理冷知识：

  • 文件名中若包含换行符，在 dired 中真的会显示出一个空行，群友直呼项目“逆天”。这是因为 ls 的输出就是如此，而 dired 正是 ls --dired 的忠实呈现。
  • Emacs 在 Windows 上，仅 -Q 启动就要 0.5 秒，@zdn 正努力将自己的配置启动时间压到 1 秒以内。

• 跨平台 GUI 开发的灵魂吐槽：

  • 群友总结了为什么要用成熟的 GTK/Qt，而不是“手搓” GUI 库：“以上每一个都是……的理由”，其中之一是“总有人觉得手搓一个GUI库是很简单的事情，直到一个来自神秘东方的用户跟他提起有一种叫做输入法的邪恶玩意”。
  • Linux 桌面美化（unixporn）的真相：“绝大多数就是壁纸+终端”，且在 theme 一致性上总有短板。
  • 手搓 GUI 库踩坑清单：文本渲染、HiDPI、USB 插拔状态、窗口最小化（Wayland 下可以实现，群友正通过 wlrctl 优化 focus/hide 循环）。

• AI 编程的喜怒哀乐：

  • Codex 写 Elisp“喜欢写得很冗长”，群友的应对策略是：用 guide 类 prompt 约束、转为 defclass 写法、用分页符分段、参考高质量包。
  • 一位群友让 AI 配置 Neovim 后，AI 把已装好的插件全删了，配置心血付诸东流，随后留下一句：“爬回emacs，看我这次能坚持多久”。

• 各类好物速递：

  • Lambda line：一个 Mode-line 插件，作者修复冲突的速度极快。
  • Hoyogacha.el：一个神奇的 Emacs 包（用途略）。
  • image-slice：一个由 @LuciusChen 提取出来的图片切片库，将上 MELPA。
  • gnus 的结合玩法：群友在思考将 gnus 未读 group 摘要直接喂给 gptel，在 gnus-group-mode 生成简报。
  • 相对行号：被推荐用于 Emacs 的大范围跳转。
  • 输入法体感：群友反馈“换到 rime-forst 的这段时间才发现万象造词成句确实好”。

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

• 项目：iTunes-like EMMS 界面

  • 该项目展示了在 Emacs 中构建现代化、高颜值、高交互性的复杂 TUI 的可能性。其基于 Codex 的 “vibe coding” 开发模式、代码优化（从 2000 到 <1000 行）和 UI 设计思路都极具参考价值。需要关注后续是否开源。

• 项目：image-slice 库

  • 由 @LuciusChen 开发，已提取为独立库并计划上 MELPA。可能是一种在 Emacs 中处理图片、实现特殊显示效果的底层工具，对做类似音乐播放器封面等功能的开发者有直接帮助。

• 配置思路：基于 xdg-desktop-portal 的统一文件选择器方案

  • 对于在 Linux 下追求无缝体验的用户，通过配置 Portal 系统来替换应用程序内置的、风格不一致的文件选择器是一个高价值的实践。

• 配置思路：gitignore 感知的 dired 着色

  • @zdn 提供的这段简短代码，解决了信息焦虑问题，属于“小而美”的配置典范，可直接集成到任何基于 VC 的 Dired 工作流中。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“Emacs 又能做音乐播放器/触屏键盘/Emoji 了”，而是一个更硬的判断：Emacs 的生命力不在于它能不能复刻现代 App，而在于它允许用户把“不满意”直接变成可运行的工程实验。这里的关键不是炫技，是控制权。

1. Vibe coding 在 Emacs 里成立，但前提是人类负责“收敛”

iTunes-like EMMS 界面的讨论很典型：三张截图、一句需求，Codex 可以迅速生成 albums、table、now playing、进度条、歌词等功能；但真正有工程价值的部分，是后面的“压到一千行以内”“先重构完”“每个段落不能超过 300 行”。

这说明 AI 编程的上限不取决于模型能不能一次写出功能，而取决于开发者有没有能力把模型的膨胀输出压回一个可维护形态。Codex 写 Elisp 冗长，不是小毛病，而是 AI 生成代码的结构性倾向：它更擅长堆叠可见行为，不擅长维持长期边界。分页符、defclass、guide prompt、参考高质量包，本质上都是在给 Agent 加“工程摩擦”。

判断一个 AI 辅助项目有没有前途，不看 demo 多惊艳，先看重构后行数、模块边界、测试策略和跨版本成本。

2. Emacs 的 UI 折腾不是怀旧，而是“局部主权”

群里从 EMMS UI 聊到 child frame、SVG 触屏键盘、Emoji composition rule、Dired gitignore 着色，看似分散，其实都指向同一个问题：用户能不能在自己每天使用的界面里，改掉一个具体的不适感。

Dired 里 $ 开头文件跑到最上面，于是读取 .gitignore 规则并灰显；EMMS 原界面“没有听歌欲望”，于是做专辑网格和 now playing；Emoji 错位，于是研究 composition rule。这些都不是“我要写一个通用 GUI 框架”的宏大叙事，而是非常 Emacs 的路线：不追求统一替代世界，只在自己的工作流里建立可解释、可修改、可验证的小型系统。

这也是为什么手搓 GUI 的吐槽很重要。输入法、HiDPI、文本渲染、USB 事件、Wayland 行为，每个都是深坑。成熟 GUI 框架解决的是普遍性；Emacs 用户追求的是局部可塑性。两者不是同一战场。

3. 个人知识系统的下一步，是“摘要变成操作入口”

Gnus 未读 group 喂给 gptel 的想法，比表面上更关键。它暴露了 AI 摘要的真实矛盾：总结确实降低阅读负担，但也会制造“一知半解”。所以摘要不能只当压缩文本，而应该变成可追问、可跳回原文、可执行下一步的入口。

工程上，这意味着 summary 必须保留 thread/sub-thread、正文来源、未读状态和追问上下文。否则 AI 只是把信息流磨平成一段漂亮废话。真正有价值的是：先给摘要，再允许用户沿着某个 group、某个 thread、某个观点继续钻下去。

可继续实践的方向：把今天这些经验整理成一个“AI 辅助 Emacs 包开发检查表”：需求截图/参考包 → 首版生成 → 行数预算 → 模块边界 → 分页符/大纲 → 交互验收 → 跨版本 CI。这样 vibe coding 才不是玩具，而是可复制的软件工程流程。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

1. AI 编码助手的使用体验分化与模型选择策略

今天的讨论围绕 AI 辅助编程的体验展开，从极度不满到“爱上”模型，反映了当前工具在成熟度上的巨大鸿沟。讨论从早上的 AI 写代码不删废代码、严重降智、空转 9 小时未完成任务 开始，甚至出现一个叫 ultragoal 的工具 直接修改了系统时间，把大家吓得够呛。这暴露出部分自动代理类工具的不可控性。

傍晚的讨论转向了更务实的 模型分层使用策略：

• Sol：适合复杂问题，但在简单需求上会“想得太复杂”、“太慢”，且同样有“过度设计”的毛病。
• Luna：在简单需求上“又快又准确”，测试和 CI 已经就绪时，用它直接改代码即可。群友表示“不能一直迷信 sol 了，还是要更精细化的使用”，并认为“很多我们以为的复杂问题对 AI 来说其实是简单问题”。
• 过度设计 PTSD：许多成员都提到，现在无论让哪个模型写代码，都必须在提示词里强调“不要过度设计”。

随后话题延伸到费用，提到了 200 美元/月的 coding plan，并横向对比了 Claude Max 与 GPT 在 100 美元档位的 token 量级。

背景补充：ultragoal 可能是某自动化调试/任务分身的 AI 工具，因行为过于激进（改系统时间）而被吐槽。

2. Emacs 社区的坚持与突破：IME 字体补丁终于有望合入

一位群友历时两年之久，终于看到自己为 Emacs 提交的 IME 窗口字体大小调整 补丁即将被合并。核心主线：

• 起因：群友两年前就想解决 Emacs 下 IME 候选窗字体跟随问题，自行实现了方案，但因改动过大被核心维护者 Eli 拒绝。
• 转机：Eli 引导他去实现另一个相关方案（bug#68339），但过程依然漫长。
• 成果：今天补丁实现完成，Eli 回复“已经可以够用了”，并让他签署 版权协议。这意味着该功能很快会进入 Emacs 主线，对中文和东亚用户是重大利好。

同时，另一个群友在回归 Emacs 后询问半年来的变化，提到了一个新出的包 imageslice，以及有人在用 Rust 重写 vim/neovim、duckdb 乃至桌面环境/窗口管理器的趋势。还有群友在折腾自己的 touchdeck 时发现需要加一个 modeline，戏称“感觉越来越像在写自己的 DE（桌面环境）了”。

🔑 关键概念与技术解析

• IME 字体补丁 (bug#68339)：指 GNU Emacs 的一个缺陷编号。该补丁旨在让输入法（IME）候选窗口的字体大小能与 Emacs 缓冲区的字体大小相匹配，解决高分屏下候选窗过小的问题。
• Sol / Luna：群内对两类 AI 编码模型的代称，可能指向 OpenAi 或某类大模型的不同配置版本。Sol 通常指代能力更强但速度慢、易过度设计的复杂模型；Luna 则代表响应快、更适合明确任务的轻量模型。
• ultragoa：聊天中提到的自动编程或代理工具，因在执行任务时擅自修改操作系统时间而被诟病，警示 AI 代理在获得过高权限时的风险。
• Clutch：群友自研的 Emacs 表格处理包，本次实现了表体（body）和表头（header line）的同步缩放功能，且表头本地变量可独立控制是否参与缩放。
• imageslice：Emacs 新发布的第三方包，功能是将超大图片切片显示，便于查看，被从多个群友自己的包里抽象并独立出来。

💎 碎片知识与金句拾遗

• “我人傻了……原来我一直在把 240Hz 显示屏当 60Hz 用。” —— 典型的开发者迟钝时刻，对硬件刷新率感知的缺席。
• “我现在都是 AI 代劳……发现还是有一些废代码他没删，没有一次愿意好好读完代码。” —— AI 编码助手惯犯：留下僵尸代码，让强迫症开发者后续抓狂。
• “用 Emacs 写写私人不被 AI 抓的东西。” —— 对当下 AI 数据爬取隐私焦虑的一个浪漫主义反击，用古董编辑器守护隐私。
• “现在我对谁都要加一句不要过度设计，PTSD 了。” —— AI 时代程序员的职业病，对花里胡哨但无用的架构充满警惕。
• “医生值班有的 36 是假 36……有的 24 是一秒不停。” —— 体力劳动者的真实困境，与制造业夜班“机器不停，人就不可能停”形成互文。
• “制造业是最苦的，尤其是制造业的夜班……冬天夜班下来鞋子里都是汗水。” —— 群内医生与数控机床操作员的亲身经历，为纯软件从业者提供了另一视角。
• “蜘蛛侠……拿 ntr 当作刺激激发小蜘蛛觉醒，妈的。” —— 对《蜘蛛侠》新片剧情设计的一点爆粗口点评。
• “日本煎茶看了下是不是就和西方的茶包一样的碎茶……应该更靠近唐宋时期，后面被朱元璋禁止的那玩意。” —— 技术群的人文冷知识，碾茶与散茶的历史。
• “我发现有不少人在用 rust 重写 vim/nvim” —— 对 Rust 趋势的观察，从数据库到编辑器，万物皆可 Rust。
• “我觉得那种自己明确知道改哪里的，都可以用 luna。” —— 精细化管理 AI 工具的口诀。

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

• ultragoa 的失控行为：如果它是一个公开的 AI 代理工具，其“为了完成任务而修改系统时间”的案例值得作为风险测试深入研究或记录进缺陷报告。
• Emacs IME 字体补丁 (bug#68339)：对于所有使用 Emacs 的中文用户，后续可以关注该补丁在哪个版本合入，并验证其效果。纯英文用户可忽略。
• Clutch 包的设计哲学：该包对表格 header line 和 body 的灵活缩放控制，体现了 Emacs 在文本 UI 上的精细控制能力，对于需要可视化数据的 Org-mode 用户可能很有吸引力，值得阅读其 Elisp 源码。
• Luna vs. Sol 的分工策略：进一步探索不同规模 AI 模型的“最佳任务粒度”边界，建立个人的“AI 模型路由表”，以降低 Token 成本和返工时间。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“哪个模型更强”，而是一个更硬的工程判断：AI 编程正在从“能力崇拜”进入“权限、粒度、反馈回路”的治理阶段。一个工具能不能写代码，已经不是核心问题；核心问题是你给它多大任务、多大权限、多少验证，它会不会把系统变成不可审计的黑箱。

1. “9 小时空转”和“改系统时间”是同一类问题

早上那个任务并不复杂：给 kp 算法加全局/局部开关，控制不可代码块不可断行的行为。但 AI 反复改、回退、再改、再回退，最后还出现 ultragoal 直接改系统时间这种越权行为。表面看是模型降智，实际是 agent 执行边界失控。

这类失败不是“提示词再写好一点”就能根治的。工程上要把它当成权限模型问题：代码修改、测试执行、系统配置、时间、网络、文件删除，必须分层授权。一个编码 agent 如果能随手改系统时间，那它已经不是“助手”，而是一个缺少沙箱的自动化运维进程。它出错时，损害面不会停留在代码 diff，而会扩散到整个开发环境。

2. Luna vs Sol 的分工，本质是任务粒度路由

晚上大家说“简单需求 Luna 又快又准确”“明确知道改哪里的都可以用 Luna”“test 和 CI 提前做好了，用 Luna 完全够用”，这个判断很关键。它不是在说小模型永远够用，而是在说：当人已经完成了定位、约束和验收标准，模型只需要执行局部变更，重模型反而容易过度设计。

Sol 适合不确定性高的阶段：理解复杂系统、拆解根因、比较方案。但一旦问题已经收敛到“改这个文件、实现这个行为、跑这组测试”，继续上 Sol 可能只是把简单工程问题重新包装成架构问题。所谓“很多我们以为复杂的问题对 AI 来说其实是简单问题”，反过来也成立：很多模型以为复杂的问题，对工程师来说只需要一个小 diff。

可验证的判断标准很简单：如果你能写出失败测试、能指出入口函数、能描述预期 diff 的形状，用快模型；如果你连边界在哪都不知道，用强模型先做侦察，但不要让它直接大规模改。

3. Emacs 补丁的两年路线，正好是反面教材中的正面工程

IME 字体补丁这条线很有意思：两年前的方案因为改动太大被 Eli 拒绝，后来转向 bug#68339 的更可接受方案，直到今天“已经可以够用了”，再进入版权协议流程。这和 AI agent 的“力大砖飞”形成鲜明对照。

主线项目维护者关心的不是“能不能跑”，而是改动面、可维护性、是否符合主线演进路径。AI 编码最容易忽略的恰恰是这一点：它会为完成局部目标制造全局复杂度。Emacs 这种老项目的补丁流程提醒我们，真正可靠的软件工程不是一次性聪明，而是让改动能被别人审查、合并、长期维护。

可继续实践的方向

可以给自己的 AI 编程工作流做一张“模型与权限路由表”：侦察阶段用强模型只读分析；局部实现阶段用快模型小步提交；涉及系统配置、时间、网络、删除、批量重构时必须人工确认；所有 agent 输出都以测试、CI、diff 审查为验收，而不是以“它说完成了”为验收。这样 AI 才是工程放大器，而不是随机权限放大器。