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

Emacs 中文讨论组

🎯 核心热点与专题探讨

📐 中英等宽字体：实现路径与 gostel 缩放争议

聊天中关于“中英文 2:1 等宽”的讨论持续了多个时段，核心矛盾集中在 gostel（一个 Emacs 字体配置工具）对非等宽中文字符强制施加 0.7 倍宽高缩放的实现是否合理。

• 现有问题：gostel 检测到中文宽度与英文不匹配时，会直接对中文 glyph 进行 0.7 倍缩放，导致高度随之变化，视觉效果偏矮。群友指出所有主流终端和编辑器均使用“在字符间插入空白”或“压缩英文字体宽度”来实现 2:1，直接乘系数属于错误实现。
• 技术路线：该缩放逻辑写在 gostel 的 C 模块中，非 Emacs Lisp 层面。作者初衷是让非等宽中文字体也能对齐，但行为意外。
• 官方备选方案：Emacs 29 之后 display 文本属性新增 min-width，可将字符显示宽度调整为任意像素值而不改变实际文本宽度，配合 string-pixel-width 可精确测量。群友认为这比 gostel 的 C 模块方案更稳健，并能避免高度变化。
• 字体实践：
  • 优质原生 2:1 组合推荐 霞骛文楷 + Iosevka（无缝配合），或 Sarasa 家族；
  • Maple 通过插入空白实现等宽，但字间距显松，不如霞骛+Iosevka 协调；
  • Monolisa 虽美观，但因空白比例较大，初期观感不习惯；
  • Unifont 覆盖面广、像素风格，但中英“视觉等高”而非几何等高，部分用户偏好。

💬 Telega 增强：Emoji 自动补全 Stickers

Telega（Telegram 的 Emacs 客户端）用户 zevlg 实现了输入 emoji 后按 Tab 即可弹出最近使用的 sticker 补全，类似官方客户端的交互。此前只能通过 C-u C-c C-a sticker 手动选择，改善后的补全方式（不区分 favourite 和 recent）大幅提升 UX。讨论中还提到可以考虑用 child-frame 展示匹配结果，但当前 TAB 补全已足够方便。

🔑 关键概念与技术解析

• gostel Emacs 字体管理工具，能按语言/脚本分配不同字体，并尝试自动对齐中英文宽度（通过在 C 层面缩放 glyph）。
• display 文本属性的 min-width Emacs 29 新增，允许指定一个字符在屏幕上占据的最小像素宽度，用于对齐多语言文本而不改动原始字符。可结合 string-pixel-width 精确测量并调整。
• mu4e-headers-marks mu4e 邮件客户端中定义邮件标记的 alist（如已读、星标、附件等），支持自定义符号，通过设置 mu4e-headers-visible-flags 还能隐藏冗余标记。
• Triplicate & Berkeley Mono Triplicate 是 Matthew Butterick 的等宽衬线字体；Berkeley Mono 窄版需额外购买且缺乏 Nerd Font 图标覆盖及部分符号，被群友评价为“无诚意”。

💎 碎片知识与金句拾遗

• “gostel 对于不是等宽中文会用 0.7 缩放……头一次见直接 *0.7 的” —— 群友震惊于高度被连带缩放的实现。
• “霞骛 + Iosevka 比 maple 好，maple 的中英等宽加空白看起来很不舒服” —— 字体组合审美经验。
• “Unifont 用的应该是 wqy 的点阵宋体……覆盖面真全” —— 怀旧且实用的点阵字体认识。
• “在使用了 display 文本属性之后，实际宽度就变成了 window 中字符显示的距离了，所以只要能准确的测量出来，就可以认为它是实际的宽度。” —— 强调 Emacs 29 新特性的适用场景。
• “TG 的 spam 甚至入群都用上 AI 了……黑产那些都在搞电诈” —— 解释 Telegram 加强注册验证的背景。
• “输入 emoji 后 tab，wow amazing” —— 对 telega sticker 补全的赞叹。
• “邮件左边的这些符号是啥意思……如果某个 flag 总是出现，可以不显示，是冗余信息” —— 分享 mu4e 符号集并给出隐藏建议。
• “Berkeley Mono 的 narrow 版需要买 dlc……无丝毫诚意” —— 对商业字体的吐槽。
• “直接回复 /sban” 与 nmBot 交互 —— 群管机器人使用细节。

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

• Emacs 29 min-width + string-pixel-width 在字体对齐中的应用 可进一步探索在终端 Emulation、多语言排版 scenarios 下，用它取代 gostel 的 C 层缩放，构建可配置、健壮的等宽对齐方案。
• Telega sticker 补全的实现与扩展 当前通过 Tab 触发选择，未来可结合 child-frame 实现浮动预览，或支持自定义排序算法（如按使用频率）。
• mu4e 视觉优化配置参考 分享的 brsvh/emacs-bs 和 brsvh/fleet 中，包含大量 mu4e 标记符号化、邮件列表 UI 优化等配置，适合作为打造高颜值邮件客户端的起点。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“哪款字体更好看”，而是一个更硬的工程判断：排版对齐不是视觉魔法，而是约束建模。gostel 把中文 glyph 直接乘以 0.7，看似解决了 2:1，实际是把“宽度问题”误伤成“字形缩放问题”。这类错误在 Emacs 生态里很典型：为了补一个显示层缺口，绕过抽象边界，最后把文本、glyph、window display width、交互移动全搅在一起。

1. 好的 Emacs hack 应该改“显示占位”，不是改“字形本体”

群里反复指出，主流终端和编辑器通常通过插空白、压缩英文字体宽度、或右侧补宽来达成 2:1，而不是压扁中文。原因很简单：中英对齐的真实需求是“这个字符在网格里占多宽”，不是“这个字应该长什么样”。

Emacs 29 的 display 文本属性 min-width 之所以更像正路，是因为它把问题放回 display layer：文本值不变，glyph 不变，只调整窗口中的显示距离。这个边界很重要。否则你会得到一个表面能对齐、但复制文本、移动光标、计算宽度、视觉高度都可能互相打架的系统。

2. “实际宽度”不是天然事实，而是你选择哪个层面的事实

讨论里有个关键转折：有人担心 display 后“实际宽度不变”会导致后续计算抓瞎；随后又有人指出，若 string-pixel-width 能测量 display width / min-width，那么 window 中字符显示距离就可以被当作实际宽度。

这句话比字体配置本身更有价值。工程上很多争论不是“哪个值是真实的”，而是“哪个层的真实值服务于当前操作”。做表格渲染、buffer 交互、result table 展示时，你需要的是屏幕占位宽度；做文本处理时，你需要的是原始字符串宽度。把这两个值混在一起，才是 bug 的温床。

3. Telega sticker 补全说明：Emacs UX 的上限不低，短板是默认路径

emoji 后 Tab 补全 sticker 这个改动很小，但它击中了 Emacs 客户端常见问题：功能不是没有，而是入口不在用户动作流上。C-u C-c C-a sticker 是“命令存在”；输入 emoji 后 Tab 是“意图被接住”。两者工程量可能相差不大，体验差距却是数量级的。

这也解释了为什么 Emacs 的现代化不一定靠重写 UI。很多时候，只要把已有能力挂到正确的 completion、preview、child-frame、display property 上，就能让老系统长出新交互。

可继续实践

可以做一个小实验：用 Emacs 29 min-width + string-pixel-width 实现一个中英混排表格 renderer，对比 gostel 缩放、字体原生 2:1、Maple 插空白三种方案。验收标准不要只看“肉眼是否对齐”，还要测：行高是否稳定、光标移动是否自然、复制文本是否干净、表格列宽计算是否可复现。工程判断最终要落到这些可验证指标上。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题一】Emacs display 属性新发现与无污染排版革命

群友在深夜挖掘 Emacs 29 的 min-width display 属性，引发了对“无污染排版引擎”的深度讨论。

• 核心发现：Emacs 29 之后，display 文本属性新增了 min-width 支持。这允许将任意字符的显示宽度调整到精确的像素值，而不改变缓冲区中字符的实际值。
• 痛点与突破：过去实现对齐排版（如 kp-mode）需要在原始文本中插入大量用作占位符的空格字符。这种做法会“污染”文本本身，干扰后续的 Elisp 代码和 Buffer 操作。
• 新方案优势：使用新特性后，完全可以保持原始文本不变，仅在渲染层实现视觉对齐。这为构建更纯净、对文本编辑更友好的复杂排版引擎打开了大门。
• 应用场景：群友迅速联想到此特性是 org-table 等需要对齐的场景的完美解决方案，认为它解决了长久以来的布局难题。

【专题二】终端新秀 Herdr 与 Moshi 的体验碰撞

围绕新一代终端工具 herdr 和移动端 SSH 应用 moshi，群内展开了对工具链迁移的复杂心理与技术细节的讨论。

• Moshi 的发现与“Vibe Coding”：
  • moshi 被发现已推出安卓版，其名字源于经典的移动端 Shell 协议 mosh。
  • 群内对其“Vibe Coding”的开发模式（作者借助 AI 快速构建应用）展开了讨论，既羡慕其效率，又对其代码质量提出了质疑，后续发现的 Debug 后门和隐藏按钮恰好印证了这一点。
• Herdr 的体验：
  • 优点：整体使用感受流畅。
  • 痛点：对无 AI Agent 环境的支持不完善，会在无 Agent 时显示空 Tab，对于习惯单纯使用 SSH 的老用户很不友好。
• 守旧者的反思：引发了关于“技术守旧”的共鸣。许多群友表示对新工具缺乏尝试动力，遇到不合意点便快速放弃，依然固守在 tmux 等“跟不上时代”但稳定可控的传统工具上。

【专题三】Codex 的“Reset”闹剧与 API 限额博弈

OpenAI Codex 的临时限额策略在群内引发了高潮迭起的讨论，从惊喜、困惑到最终回归现实。

• 事件经过：
  1. 惊喜发现：群友发现 Codex 连续多日重置使用量，导致“使劲蹬”成为热门行动代号。
  2. 官方解释：OpenAI 发文解释，此举是为调查并解决因 GPT-5.6 Sol 模型更长的工作流程、并行工具调用等特性导致的资源消耗超预期问题。
  3. 尘埃落定：官方宣布问题定位后将恢复 5 小时限额，临时重置政策成为历史。戏剧性的是，官方原话“the rest is history”被群友误读或调侃为“the reset is history”，成为此次事件的幽默注脚。
• 用户心态：本次事件暴露了高级用户在订阅制和按量付费间的矛盾。为“蹬完”限额，用户感到焦虑，甚至认为买 API 更省心，因为订阅花的不是钱而是“心情”。

【专题四】远程控制方案的现状、痛点与改造梦想

从 Windows 远程桌面的统治力到 Linux 图形栈的割裂，群内对远程控制方案进行了全面“批判”。

• 方案对比：
  • Windows RDP：公认体验最佳，技术壁垒高，其他 OS 难以望其项背。
  • Linux (Wayland)：碎片化严重，缺少统一好用的方案。Sunshine + Moonlight 在局域网或能 P2P 打洞的环境下体验优秀，但对公网支持差。rustdesk 等方案对 Wayland 支持不佳。
• 开发者“改善世界”的冲动：
  • 魔改 Sunshine：有群友计划魔改 Sunshine 的串流协议，使用 QUIC 将多个端口合并，并支持 0-RTT，以改善公网下的串流体验。
  • 自研串流软件：另有群友计划自研串流软件并加入 SSH 功能，显示出对现有方案的不满和强大的动手欲望。
• 哲学思考：Linux 图形体验不佳的深层原因被归结为“Linux 高手不关心图形，因为他们有 SSH”。这也解释了为何 CLI 软件丰富生态与 GUI 体验的落后形成鲜明对比。

---

🔑 关键概念与技术解析

• min-width display Property (Emacs)：Emacs 29 引入的文本显示属性，可设定文本显示区域的最小像素宽度，用于在不修改文本内容的前提下实现视觉对齐。
• Neomacs：一个用 Rust 编写的、旨在替代 Emacs C 核心的项目。本次讨论中涉及其对 SVG 的渲染能力（使用 resvg）。
• librsvg & Cairo：Emacs 在 macOS/Linux 上渲染 SVG 图片时所依赖的关键外部图形库。librsvg 负责解析 SVG，Cairo 负责底层绘制。
• <foreignObject> (SVG)：在 SVG 中嵌入其他 XML 命名空间（如 HTML）的元素。这导致了渲染问题，因为纯 SVG 渲染器（如 librsvg）无法解析内部的 HTML 和 CSS。
• Herdr：一个新兴的终端多路复用器，被视作 tmux 的潜在替代品，集成了 AI 功能，但对非 AI 场景的体验仍有打磨空间。
• Moshi：一个现代、开源的移动端 SSH 客户端和终端，其名称源于移动 Shell（Mosh）协议，并采用了 React Native 技术栈。
• Vibe Coding：一种新兴的软件开发形态，开发者通过自然语言与大型语言模型（AI）交互来生成代码，整个开发过程更像一种“心流”体验。
• Sing-box / Nekoray：两款流行的网络代理工具。sing-box 为通用代理核心，nekoray 则是基于此核心的桌面/安卓图形客户端。
• 0-RTT (QUIC)：网络传输协议 QUIC 的一个特性，允许客户端在首次连接或重连时，在第一个数据包中就携带应用数据，从而将连接建立的往返次数降至零。
• 补帧（Preedit）：输入法在用户完成输入、正式上屏前预览的文本。在 Emacs for Windows 的实现中是一个长期缺失的体验“短板”。

---

💎 碎片知识与金句拾遗

• “本来面向局域网串流的”：对 Sunshine/Moonlight 组合的精准吐槽，指出了其设计初衷与用户期望的广域网可用性之间的鸿沟。
• “tmux明显跟不上时代了，但是还是死守”：一句充满矛盾的独白，刻画了技术人为“沉没成本”和“肌肉记忆”所困的普遍心理。
• “沉没在claude的harness里了”：一种生动的比喻，形容已深度绑定某工具/平台生态，即使有困扰也难以脱身的感觉。
• “远离 Windows 延长人生寿命”：一句充满极客偏见的调侃，体现了对 macOS/Linux 开发环境纯净性的拥护。
• “我感觉我也成了守旧的人，那么多新东西出来我不想尝试，或者尝试了有不合意的就放弃”：真诚的自我剖析，引发了社群关于技术好奇心减退的广泛共鸣。
• “氮化镓不是我国的长处么”：关于降低 AI 算力成本的技术讨论，引申到了硬件供应链和地缘优势，知识广度令人惊叹。
• “A\封号是多因素的，之前还偷偷给prompt塞时区信息啥的”：揭示了某些 AI 服务在风控方面的复杂（甚至带有窥探性）策略。
• “有了 ai 之后 fork 仓库修改再也不怕合并上游了”：点明了 AI 辅助编程的核心优势之一，即大幅降低了维护个人定制化分支的心智负担。
• “moshi 的 debug 没删干净，moshi://debugg 能打开 debugscreen”：一个生动的“Vibe Coding”后果的实例，展现出快速开发模式在代码规范和安全意识上的潜在缺失。
• “浏览patch默认是stacked，可以切换到split”：关于代码审查中小细节的探讨，比如 stacked 视图的左侧色带放到行号上会更好，体现了对工具交互体验的极致追求。
• “我还在搞我的串流软件，我之后想把ssh功能也加上”：展示了硬核开发者“不满意就自己造”的强大行动力。

---

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

• Emacs 无污染排版探索：基于 min-width display 属性，开发不改变文本内容的 org-table 对齐插件或其他复杂排版模式。
• Herdr：对于寻求 tmux 现代化替代方案的开发者，值得继续关注其成熟度和生态发展。
• Moshi：可以作为移动端运维工具的候选项，但其代码质量（尤其是安全性）需要持续评估。
• 自建远程串流方案：基于 QUIC/0-RTT 协议，改造 Sunshine 或自研远程控制软件，以追求在公网上接近局域网体验的流畅度，这是一个极富挑战性的方向。
• Emacs 对 Mermaid 的内联渲染：可关注 Mermaid 社区对 htmlLabels: false 下 <foreignObject> 标签消除的进展，届时或可让 Emacs 直接、高效地渲染 Mermaid SVG 而无需导出为 PNG。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是某个新工具“好不好用”，而是两个相反方向同时成立：一边是 Emacs display 的 min-width 把“文本”和“显示”切开，给老系统补上了干净的抽象层；另一边是 Herdr、Moshi、Codex 这些新工具把 AI、订阅、Agent、移动端体验揉在一起，让工具链的边界变得越来越粘。真正的工程判断是：未来可长期使用的个人工具，不是功能最多的，而是边界最清楚、失败时最可退回的。

1. min-width 的价值不在排版，而在“无污染状态”

群里说 kp 排版过去要插入许多任意像素宽度的空格，这句话很关键。它暴露的是一个经典坏味道：为了显示效果修改数据本体。短期看只是多了空格，长期看会污染 Elisp、buffer 操作、diff、搜索、结构化解析。

display 的 min-width 之所以重要，是因为它把“视觉对齐”下沉到渲染层，文本仍然保持语义干净。这类改动看似小，实则是老软件生命力的来源：不是重写一个编辑器，而是在正确层次补一个抽象。工程上可验证的判断是：如果一个 org-table、markdown table、对齐排版插件用了这个机制，它应该满足三个性质：buffer 原文不变；复制/保存/版本控制不引入占位符；关闭 minor mode 后文本仍可被普通工具处理。达不到这三点，就还是伪“排版引擎”。

2. 新终端和 AI Agent 的问题，不是守旧用户不够开放

Herdr 空 Agent tab、Moshi debug screen 没删干净、Termux 软键盘入口别扭，这些不是小毛病的堆叠，而是新工具常见的优先级偏差：先服务 demo 场景，再补普通工作流。可老用户死守 tmux，并不只是沉没成本；tmux 的价值恰恰在于无 Agent、弱网络、坏终端、远程机器、脚本自动化这些低光场景都能工作。

所以“tmux 跟不上时代但还是死守”不是保守，而是一种可靠性偏好。AI 原生工具如果想替代它，不能只证明“有 Agent 时更爽”，还要证明“没有 Agent 时不打扰”“出问题时可降级”“配置和会话可迁移”。否则它只是 AI 功能的容器，不是基础设施。

3. Codex reset 焦虑说明：订阅制正在改变开发者的注意力分配

“买 API 更省心，因为订阅花的不是钱而是心情”这句话很准。限额 reset 让高级用户开始围绕额度安排工作，而不是围绕问题安排工作。GPT-5.6 Sol 更长工作流、更多工具调用、并行子代理导致资源消耗超预期，也说明 Agent 时代的成本单位不再是“问一次多少钱”，而是“一条任务链会展开多少不可见动作”。

可验证的实践方向：个人 AI 工具链应该记录每次任务的 wall time、工具调用数、上下文大小、重试次数和实际产出，而不是只看模型名和主观聪明程度。否则你无法判断是模型强，还是它只是更愿意烧资源。

可继续实践

可以把今天的线索收束成一个小实验：做一个 Emacs/org 表格的无污染对齐原型，用 display min-width 实现视觉对齐；同时给它设计“可降级原则”——关闭插件后原文完全可用。这比追逐下一个终端或 Agent 更有价值，因为它检验的是长期工具最核心的品质：增强体验，但不绑架数据。