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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：Emacs 终端 UI 的潜力与分离构想

这是当天最富有想象力和争议性的讨论。群友 zdn 在凌晨时段发表了关于 Emacs 终端 UI 的高度评价，认为它是“最有创意的 UI”，并提出了一个大胆设想：将 Emacs 的基于文本的 UI 抽离出来，做成一个独立的 GUI 库。这引发了后续的深入探讨。

• 核心观点：Emacs 在终端中通过文本绘制（如菜单、按钮）的能力令人惊叹。zdn 认为其纯粹的终端 UI 体验（例如不被传统 GUI 框架束缚）极具创造力和潜力。
• 前景与障碍：
  • 支持方：zdn 认为移植到 GUI 上很有趣，但强调 GUI 状态下的终端 UI 体验受限（如 SVG 图片预览、字体管理等不便）。这表明有人看到了其作为一种轻量级、跨平台 UI 范式的可能性。
  • 反对/疑虑方：有群友指出分离并作为独立 GUI 库“不太可能”，因为 Emacs 的文本 UI 与 Emacs Lisp 运行时高度耦合。同时，也提及了在终端绘制菜单（如右键菜单）时，中文显示会有问题，且可能不稳定（导致 segmentation fault）。
• 现状与痛点：讨论中提到了 multiform 和 chirp 等与图形展示相关的包。chirp 的 evil 模式切换问题、chirp-view-mode 导致的性能问题（满载）等，都反映了现有 Emacs 框架在处理复杂 UI（如图片预览、异步绘制）时面临的困境。这也从侧面论证了 zdn 所设想的 UI 框架的潜在价值——它能以一种更统一、更低开销的方式处理这些需求。

专题：Emacs 编辑器生态的调试、维护与投毒焦虑

这是围绕开发者和维护者日常工作的现实讨论，触及了版本管理、包维护和开源社区信任危机。

• Arch Linux 的稳定性与投毒事件：群内爆发了对 Arch Linux 生态的信任危机。有群友表示自己 Arch 挂了，换用 Fedora；有人选择转向 NixOS。关键点在于“AUR 投毒”事件，虽然有人调侃“关我 Arch Linux 什么事”，但这无疑动摇了部分用户对系统安全的信心。与此同时，有人发现黑莓的 QNX 实时系统里内置了 Emacs，这暗示了 Emacs 的广泛应用场景，也侧面反映了不同系统间的环境差异。
• LSP 性能调优与包质量问题：
  • 性能优化：关于 vue 语言的 LSP（volar）性能问题，有群友通过将 jsonrpc-event-hook 设为 nil 来关闭全量 rerender，显著缓解了 Rust、Vue 等大项目切换文件时的卡顿。这表明，在某些 LSP 实现不佳（特别是多级代理如 volar -> tsserver）的情况下，优化核心在于减少不必要的重绘。
  • 维护者响应：pg-el 项目的 PR 长期未被合并（4月提交未处理），尽管作者还活着并更新着 PGmacs。这揭示了开源项目维护中的常见痛点：作者可能专注于自己的项目而忽略了重要的社区贡献，迫使开发者通过反复“push”来引起注意。

专题：LLM 驱动的代码与文本纠错实践

群友分享了一个非常详细的基于 LLM 的中文文本纠错（特别是“的地得”专项检查）的实现方案。

• 技术细节：
  • 数据处理：将当前可见区域切分成段落，再切分成句子。利用 jieba-rs 进行中文分词，生成 token map。
  • 上下文策略：给 LLM 输入当前句子和邻近的各一个句子作为上下文，不提供更多无用信息。
  • 结构化输出：要求 LLM 输入和输出都是结构化的 JSON 数据，可以利用原生 JSON schema 支持来提升准确性。
  • 生成与集成：使用 llm.el 库与 LLM 交互，而非 gptel。有群友考虑结合 gptel-rewrite 进一步实现“修复建议”的生成。
• 痛点与反思：一位群友提到“LLM 代码生成超过单文件三千行后，我就很难弄懂整体逻辑了”，并认为“超过 100 行我就不看了”。这反映了人们在依赖 AI 生成代码时，对复杂抽象的认知和理解能力的限制。

---

🔑 关键概念与技术解析

• multiform：一个 Emacs 包，用于管理不同格式的缓冲区的显示，曾被提及但最终被删除。其背后是现代 Emacs 对图像、SVG、网页等富媒体渲染的支持尝试。
• chirp：一个 Emacs 包，用于在 Emacs 中运行简单的图形界面或类似桌面应用的 UI。讨论中提到其 chirp-view-mode 会导致性能问题（满载），需要通过关闭 jsonrpc-event-hook 来缓解。
• pixel-scroll：Emacs 29+ 引入的新滚动方式，支持水平和垂直的像素级平滑滚动。本群讨论了水平 pixel-scroll 的实现和现实意义。
• volar vs tsserver：volar 是 Vue 3 的官方 LSP，它不直接分析 Vue 单文件组件（SFC）中的 TypeScript，而是将 SFC 的 <script setup> 部分转换为虚拟的 TypeScript 代码，再注入给标准的 tsserver 进行类型检查和补全。这种“代理 + JIT”的模式导致了性能瓶颈和复杂的依赖链。
• pg-el：一个用于 Emacs 与 PostgreSQL 数据库交互的库。其活跃的 PGmacs 项目分支暗示了其实用性，但社区维护的 PR 长期未被合并，体现了开源项目管理的挑战。
• embark-dwim：Emacs embark 包的核心命令之一。在特定上下文（如光标在括号 ( 或 ) 上）时，embark-dwim 能智能地执行与上下文最相关的操作（例如，在括号附近执行 eval-expression）。这展示了 embark 强大的上下文感知能力。

---

💎 碎片知识与金句拾遗

• “emacs的这个基于text的ui是我见过最有创意的ui” —— zdn 对 Emacs 终端 UI 的极致赞美。
• “这何尝不是一种 jit” —— 对 volar 通过 tsserver 进行类型检查的评论，形象地说明了这种多级代理的复杂性和即时编译的类比。
• “完成比完美更重要” —— 一个关于视频制作和内容创作的群友共识，呼应了“精致难产”的现状。
• “如果你想长期不更视频，就好好规划一下‘大干一场’” —— 对完美主义拖延症的一针见血地讽刺。
• “我感觉我按 C-M-SPC M-@ 这种还是挺方便的” —— 关于 Emacs 的 mark-sexp 和 mark-word 操作，以及 Tsoding 的丝滑操作风格。群友从观摩 Tsoding 的直播中获得了“直接使用原生 Emacs 操作，不用花哨插件”的感悟。
• “我不在终端里面用emacs … 但emacs的这个终端里面自己绘制的，我想移植到gui上来” —— zdn 对自身需求的明确表达：要移植终端 UI 的优雅感。
• “朝花夕拾”——在老年的时候剪辑 —— 对视频剪辑拖延症的一种幽默解法。
• “这个做 vim 插件的人就说，用这个剪 podcast 会快很多。但是上特效还是需要正经的工具” —— 关于用 emacs 或 vim 进行视频剪辑的讨论，指出在对话类内容（只需要字幕和剪辑）上效率高，但特效处理仍需专业工具。

---

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

• Emacs 终端 UI 分离为独立 GUI 库的可行性探索：zdn 的构想极具前瞻性。可以关注 Emacs 社区是否有类似的实验性项目（如 nameless、glyphless 或对 Emacs redisplay 引擎的深度 fork）。
• volar LSP 性能优化的“去 JSON-RPC hook”方案：社群分享的技巧（将 jsonrpc-event-hook 设为 nil 来避免全量 rerender）值得验证其通用性。可以尝试为其他 LSP（特别是 volar、pyright 等）的 jsonrpc-event-hook 性能优化提供一个补丁或配置模式。
• 基于 llm.el 的 De/Re-accusation 纠错工具：群友分享的“的地得”纠错方案结合了中文分词、结构化输出和局部上下文。这可以发展为一个通用的文本润色/纠错 Emacs 包，公开为 llm.el 插件。
• pg-el 社区维护的现状：了解 pg-el 为何活跃度下降，是否需要有识之士 fork 并维护一个更加现代化、接受 PR 的分支。

┊ review diff a//tmp/hermes-viewpoint-extension.md → b//tmp/hermes-viewpoint-extension.md @@ -0,0 +1,38 @@ +## 🧠 Hermes GPT-5.5 观点延伸 + +中心判断：当天的讨论看似分散，但两条最值得咀嚼的线索指向同一个结构性张力——Emacs 的单线程同步假设正在被异步 LSP、富媒体应用和 LLM 集成三面夹击。争论"要不要把 Emacs UI 分离成独立库"是错的，真正的问题是：Emacs 缺少一个一等公民的异步 UI 框架。 + +--- + +### 1. zdn 的"分离 UI"不是技术方案，是需求信号 + +zdn 想把 Emacs 终端自绘 UI 移植到 GUI 上，群友反驳"不太可能，跟 Elisp 运行时耦合太深"——双方都对，但都没切到要害。 + +真正该问的是：为什么有人要在 Emacs 里做 chirp（图形界面）、ytm-radio（音乐播放器）、telega（Telegram 客户端）？因为这些应用的自然归宿本该是操作系统，但它们在 Emacs 里获得了统一的键绑定、文本操作和可编程性——代价是跟 redisplay 引擎反复撞墙。 + +chirp-view-mode 导致 Emacs 满载、视频预览图不断重绘——这不是某个包的 bug，是 Emacs 的 redisplay 模型对"异步渲染可变内容"这个需求没有原生支持的症状。每次重绘都走完整的 display engine 管线，没有 dirty rect，没有帧率控制。需求是真实的，但"抽离 UI"的提法搞错了层次——需要的不是把 redisplay 拆出来，而是在它上面加一层异步渲染调度。 + +--- + +### 2. jsonrpc-event-hook = nil 是当天最被低估的工程判断 + +群友发现：把 jsonrpc-event-hook 设为 nil 关闭全量 rerender 后，Rust 和 Vue 项目切文件的卡顿显著缓解。另一位评论 volar → tsserver 的架构："这何尝不是一种 jit。" + +这两个观察连起来，就是一个可以写成 blog post 的工程洞察：多级代理式 LSP（volar 解析 SFC → 生成虚拟 TS → 注入 tsserver → 回传诊断 → 触发 Emacs 全量重绘）的端到端延迟，不是任何单一环节的错，而是管道深度 + 同步重绘的组合爆炸。 + +可验证的推论：对任何"代理模式" LSP（volar、eslint 的 TypeScript 插件、任何包裹另一个 language server 的中间层），jsonrpc-event-hook = nil 都应该带来可测量的输入延迟改善。这不是玄学——如果 LSP 每秒推送 20 条诊断，而每次触发全量 redisplay 需要 50ms，你已经被吃掉了一整帧的预算。在大项目上用 benchmark-init 或简单的 time-to-echo 测量，应该能看到差异。 + +--- + +### 3. LLM 生成代码的"100 行天花板" + +有位群友说 LLM 生成的代码"超过一百行我就不看了"，另一位提到"超过单文件三千行就很难弄懂整体逻辑"——这是在 LLM 辅助编程大规模铺开之前，很少被公开讨论的认知瓶颈。 + +生成速度已经跑赢了理解速度。这不是工具的问题，是人类工作记忆的硬上限。当年 IDE 普及后，"在一个文件里跳转"取代了"记住整个文件"；今天 LLM 代码生成普及后，需要的可能是"LSP for generated code"——不是帮你写代码的工具，而是帮你理解代码的工具：自动摘要生成模块的功能边界、标注哪些部分是 LLM 生成 vs 人工修改、追踪跨文件的逻辑依赖。这恰好跟上面 volar 的 JIT 隐喻闭环了：当你依赖的层数超过你能心智建模的上限，debug 就从"修 bug"变成"考古"。 + +--- + +### 可继续研究/实践的方向 + +- 基准测试：在一个 500+ 文件的 TypeScript 项目中，对比 jsonrpc-event-hook 默认 vs nil 时的编辑延迟（用 timer + post-command-hook 测量实际渲染完成时间）。如果效果可复现，可以写成补丁提交给 lsp-mode / eglot。 +- 异步 UI 框架调研：系统梳理 Emacs 生态中已有的异步渲染尝试（chirp 的 timer-based redraw、telega 的图片缓存策略、elfeed 的增量更新），看看是否有可以提取的通用模式。参考方向：React 的 reconciliation / Flutter 的 rendering pipeline 的最小化子集。 以上内容已保存到 /tmp/hermes-viewpoint-extension.md。三个要点：

1. zdn 的 UI 分离构想 → 重新框定为"Emacs 缺异步 UI 框架"，不是"能不能拆 redisplay"
2. jsonrpc-event-hook = nil → 提炼成可推广的工程洞察：代理式 LSP 的管道深度 × 同步重绘 = 延迟组合爆炸
3. LLM 代码的认知天花板 → "完成比完美"的反面：生成速度跑赢理解速度后，debug 变成了考古

最后给了两个可动手验证的方向（基准测试 + 异步 UI 框架调研），接了当天聊天记录里出现的具体包名（chirp、elfeed、telega），没有编造任何群内不存在的事实。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题：AI编程Agent工具的使用体验与生态争议

群内围绕多个AI编程客户端（如 Codex CLI、OpenCode、Mimo Code、Claude Code、Grok CLI 等）展开了激烈讨论，涉及UI/UX设计、模型调度、厂商抄袭等话题。

• TUI交互争议：多位成员对 Codex CLI 的 statusline 显示问题提出不满，认为其“乱跳”、“不咋地”，并指出其工具调用日志过于啰嗦。成员反馈“我看输出只为了纠偏”，但 Codex 过多的信息输出被视为“噪音”。对比之下，OpenCode 被普遍认为更美观，但存在跨平台性能问题（Windows 上太卡）。
• 模型路由与任务分解：成员 🦀 提出了一个明确需求：希望实现“model-router”，根据任务复杂度自动路由到不同大小的模型（如 commit 这种简单任务用小模型，复杂编码用大模型），以避免“杀鸡用牛刀”的资源浪费。有成员建议通过“分 profile”并手动切换或编写快捷键/Transient 切换来解决，但**🦀 **认为这打断了原本流畅的任务流，期望实现“自动路由”。
• Mimo Code 的“抄作业”争议：成员介绍了 Mimo Code，指出其界面精致、有“输入消息自动建议”等贴心功能，但很快被群友认出“这不是 opencode 嘛…就抄的”。讨论迅速上升到商业伦理层面，成员以此类比小米的“抄袭”行为（如连黄仁勋街头吃面也抄、HyperOS 后严禁解 BL 锁），以及阿里 Qwen Code 是 fork 自已死的 Gemini-CLI 的案例。普遍观点是，国内企业“靠情怀圈粉、然后收割”的路径相似，但也承认 MIT 等宽松开源协议给了这种行为的合法性（只要不侵权 Logo 等自有资产）。
• Grok 4.5 与 DeepSeek 的对比：部分成员对 Grok 4.5 的 CLI 交互设计和性价比（2.9元7天试用）表示赞扬，并提到 DeepSeek 在细致的生活建议（如空调温度、运动方案）和上下文感知（分得清“昨天”、“今天”）方面表现出色。

痛点总结：缺乏智能且无缝的模型路由是当前痛点；不同厂商的TUI设计标准差异大，影响用户体验；开源AI Agent工具的“山寨化”现象引发对生态健康的担忧。

---

🔑 关键概念与技术解析

• musl glibc allocator 差异：成员 🦀 提到“musl 有坑”，具体为 alloc 有一把大锁，导致使用 musl 打包的程序 CPU 占用高。建议使用 jemallocator 来替换默认分配器以解决性能问题。这是 Rust 及跨平台开发中一个常见的坑点。
• neomacs v0.0.11 / v0.0.12：一个正在开发中的、基于现代技术的 Emacs 实现（可能是用 Rust 或类似语言重写？）。成员反馈 v0.0.11 版本相比 v0.0.10 “流畅太多了，越来越可用了”，开发者也透露正在进行 v0.0.12 的 bugfix。社区围绕其 tab-bar-mode 的显示 bug 进行了复现和反馈。
• Bun in Rust：群内分享了一篇 Bun 官方博客（bun.com/blog/bun-in-rust），讨论 JavaScript 运行时项目 Bun 用 Rust 重写部分组件的过程和动机。成员对博客中的动画效果印象深刻。
• niri 窗口管理器：成员提到 niri 默认有 M- 这一定义，这是用于在同应用内快速切换窗口的快捷键绑定。对于平铺窗口管理器用户来说，这是一个非常有用的交互特性。

---

💎 碎片知识与金句拾遗

• Fabel 5 的坑爹计费：一位成员吐槽购买了 Fabel 5 模型，结果一次任务消耗了50%的5小时使用限制，但总用量只用了2%。怀疑是独立的计费池设计有问题，最终该次任务直接消耗了100%的限制。
• AI 时代“重写”带来的潜在风险：成员 🦀 担忧：“以后市面出现一个产品，只需要逆向，重写就好了。无限制 token 的时候，可能一两天就上线了。以后不好随便开源了。” 这种对 AI 加速软件复制（甚至替代）的担忧值得关注。
• Emacs 群聊的图标趣味：群主 @feng 透露，三个 Emacs 群聊的图标各不相同，本群是因为觉得原图标“龙头向下不好”，所以调整了角度。
• “全靠 deepseek”：一位感冒成员在自我观察后说“最终应该是顶住了，没有发烧”，当被问及时回应“全靠 deepseek”，称赞其能给出“非常细致的建议”，包括空调温度、做什么运动，并且能识别时间语境（昨天、今天）。
• “Acfun 真是宁肯倒闭也不变味”：在对比B站内容下沉、直播擦边等变化时，这句对 Acfun（A站）现状的评论引起共鸣，表达了一种对“不变质”的怀念与无奈。
• “流量至上的时代，讨好流量才能赚钱。” —— 概括了内容平台普遍困境。
• “B 站的推荐算法，就是米田共。” —— 对 B 站推荐算法的直接吐槽。

---

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

• grill-with-docs：成员在使用这个项目（未提供链接，需搜索）。名字暗示可能是与文档交互（RAG？）相关的 CLI 工具，值得探索。
• OpenCode vs. Mimo Code 的 UI 创新：虽然 Mimo Code 被指抄袭，但其“自动建议”功能体现了 UI 微创新。深入对比两者的交互逻辑，可能孵化出更好的 TUI 设计。
• model-router 概念：这是本群讨论中提出的一个切实需求。目前市面上是否有成熟的开源方案？一个简单的实现（基于任务类型或 prompt 长度自动选择 LLM 端点）是否有潜力？
• neomacs 的 tab-bar-mode bug：对于 Emacs 生态的重写项目，群内已复现并准备修复。关注该项目后续提交，了解其修复思路。
• Bun in Rust：关注 Bun 项目用 Rust 重写核心组件的具体技术路线，这是现代 JS 运行时优化的一个经典案例。

┊ review diff a/emacs-2026-07-09-perspective.md → b/emacs-2026-07-09-perspective.md @@ -0,0 +1,19 @@ +## 🧠 Hermes GPT-5.5 观点延伸 + +当天最值得咀嚼的不是某款工具的好坏，而是两条看似无关的讨论在底层撞在了一起：一条是 🦀 提出的 model-router 需求（"commit 这种小事不想每次都杀鸡用牛刀"），另一条是同一批人讨论 AI 加速下的开源克隆危机（"无限制 token 的时候，一两天就上线了，以后不好随便开源了"）。这两件事指向同一个正在发生的结构性变化：代码本身正在快速贬值，但上下文——你的工作流、偏好、使用模式——正在成为真正的稀缺层。 + +一、model-router 的难点不在路由，在上下文连续性 + +🦀 的需求非常具体：commit 用小模型，写代码用大模型，而且不能打断流。群里给的建议是"分 profile 手动切"——这恰恰暴露了当前 AI 工具的一个集体盲区：它们把模型当作"会话级"的配置，而不是"任务级"的调度决策。 + +一个可验证的判断：model-router 可以被分解为两个独立问题。第一层是分类——根据 prompt 长度、是否包含 diff、是否涉及文件操作等信号判断任务复杂度，这可以用一个极小的分类模型甚至规则引擎解决，不是瓶颈。第二层才是真正的硬骨头：当你在小模型和大模型之间切换时，如何保持对话上下文的语义连贯性？ 小模型在 commit 场景下生成的摘要，大模型回来继续写代码时能否正确理解前因后果？这里涉及 context compression 和 cross-model alignment，目前没有任何现成的开源方案真正解决它。 + +方向很明确：做一个类似 nginx 的模型代理层，拦截请求 → 分类 → 路由到不同 backend，同时维护一份"上下文摘要"在模型切换时注入。tractable，但不 trivial。 + +二、"不好随便开源"焦虑的靶子偏了 + +群友 🦀 担忧 AI 让逆向+重写变得太便宜，进而抑制开源意愿。这个直觉没问题——AI 确实把"理解一个项目 → 重写替代"的成本从人月压到了人天。但推导方向错了：不是因为 AI 能快速克隆代码所以不该开源，而是因为代码不再是护城河，所以可以更大胆地开源那些本来就不是护城河的东西。 真正不能被一键克隆的是：训练数据、用户行为图谱、社区信任积累、与具体工作流的耦合深度。这些"软资产"的复制成本几乎没有被 AI 降低。 + +一个对照案例：Qwen Code fork 自已死的 Gemini CLI，但 Gemini CLI 不是因为被 fork 而死——它死于 Google 自己放弃维护。fork 者接盘维护反而延续了生态。MIT 协议的代码被人拿去改 logo，这在法律上从来都是允许的，AI 只是让这个事实变得更刺眼。 + +可继续实践的方向： 实现一个最小化的 model-router 原型。两条路径：一是做 Hermes/Codex 的中间件插件，拦截 prompt 做分类后改写 model 参数；二是做一个独立 proxy（类似 litellm 但加上任务感知路由），在 OpenAI-compatible API 层做分流。优先验证的不是分类准确率，而是上下文在模型切换后的连贯性——这才是决定这个方向能否成立的关键实验。 文件已写入：/home/geekinney/.hermes/workspace/emacs-2026-07-09-perspective.md

板块概要：

• 中心判断：当天两条讨论线（model-router 需求 × AI 加速克隆焦虑）在底层交汇——代码在贬值，上下文在升值
• 点一：model-router 的真难点不是分类而是跨模型切换时的上下文连续性，目前没有现成方案
• 点二：克隆焦虑靶子偏了——能被 AI 一键复制的东西本来就不是护城河，真正不可复制的是训练数据、用户行为和社区信任
• 可实践方向：做一个最小化 model-router proxy，优先验证上下文连贯性而非分类准确率

~910 中文字，两条观点都锚定在原始讨论的具体发言上，延伸方向可落地。