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

Emacs 中文讨论组

🎯 核心热点与专题探讨

本次群聊围绕几个彼此独立的硬核技术话题展开，其中 AI 编程助手体验 和 Emacs 万能化（将一切服务搬进编辑器） 是最炙热的焦点，另有关于 Web 前端技术演进的短暂讨论。

专题一：AI 编程助手体验（dsh vs 豆包，代码全自动生成）

群里成员们正在积极尝试用 AI 自动编写代码，并对比不同工具的表现。关键词是 dsh（推测为某个 AI 编程 agent 或代码生成工具），它被多人称赞“真好用”，而“豆包”则被嫌弃“辣鸡”。有人表示“已经能发消息了”（可能指用 AI 自动写代码实现某个功能），甚至“电脑自己在写代码”、“今晚是不是就可以端上来了”，气氛充满兴奋。同时也有理性声音：有人问“dsh 有什么需求其他 agent 实现不了的吗”，还有人提到“喜欢 Web 图形界面的话就用 dsh”，说明 dsh 可能在 Web UI 方面有优势。关于前端代码，有人直言“前端代码 ai 写的比人好”，而“前端除了框架都是面条代码”则表达了传统前端代码的杂乱现状。

专题二：Emacs 万能化——把一切 App 搬进编辑器

这个话题从早上持续到晚上，是群内最持久的“执念”。起因是有人提到“discord bilibili x slack discourse zulip qq github misskey”等平台，似乎在讨论如何将它们接入 Emacs（可能通过 telega.el 或类似方案）。随后直接爆发：有人问“美团能搬进 emacs 吗”，并解释自己每天用手机美团点外卖。群友给出脑洞解决方案：用 ADB 连接手机操作美团 App，通过截图 + AI 图像识别在 Emacs 里展示信息，并用免密支付完成订单。还有人问“能用 emacs 订披萨了吗”，并附上 YouTube 链接（可能演示类似操作）。随后话题转向微信，有人抱怨电脑版微信鼠标点点点不方便，希望有类似 telega.el 的微信插件。一位群友声称“这问题不大，我可以很快搞一个出来”，并提到打算用 matrix-rust-sdk 实现，引发强烈期待。整个讨论体现了 Emacs 作为“操作系统”的终极愿景。

专题三：Web 前端技术演进（AJAX、虚拟 DOM 与后端渲染）

有成员突然问“现在还有人提 ajax 技术吗”，引发短暂讨论。大家认为现代网页服务不再直接返回整个 HTML，而是逐步按需加载，首次访问体验偏慢；同时现代网页多用 JS 和虚拟 DOM 进行组件化。有人提到 fetch 不能监控进度，说明传统 AJAX 仍有价值。随后有人介绍 elixir liveview 这类后端渲染方案——通过 WebSocket 直接发送需更新的 HTML，前端只需修改 DOM。整体观点是 Web 技术本身仍是好技术，画 UI 做交互非常方便，但实现方式在演化。

🔑 关键概念与技术解析

• dsh：群内多次提及的 AI 编程工具/agent，被评价为“真好用”，并强调喜欢 Web 图形界面的人适合使用。疑似支持通过 Web 界面进行交互，能自动编写代码。
• LiveView（Elixir）：一种后端渲染方案，通过 WebSocket 实时推送 HTML 增量更新，前端无需复杂 JS 框架，仅需修改 DOM，解决了传统 AJAX/虚拟 DOM 的首次加载缓慢问题。
• ADB + AI 图像识别：讨论中提出的用 Emacs 控制手机美团 App 的方案——通过 ADB 截屏、在 Emacs 中识别截图文字（OCR），配合免密支付完成操作。这体现了将外部设备接入编辑器的混合思路。
• matrix-rust-sdk：用于构建聊天客户端的 Rust SDK，被提及用来实现类似 telega.el 的微信/Matrix 插件，可能成为 Emacs 万能化的重要基础设施。
• ghostel：一个 Emacs 终端插件，被问及“现在那个终端插件好用”时回答为 ghostel，推测为 Emacs 内的终端模拟器或终端管理工具。

💎 碎片知识与金句拾遗

• “kmonad和kanata这种算吗？” → 讨论键盘映射工具能否录制宏，得出结论“这得怪操作系统不行”，暗示底层键盘映射工具难以实现随时录制/播放宏的功能。
• “何不抛弃補全。” → 可能是对 AI 补全工具的调侃，表达“完全依赖 AI 写代码”的态度。
• “dsh真好用，豆包辣鸡（换了dsh,玩了一整天,通了宵” → 生动对比，显示 dsh 的吸引力。
• “前端代码都是ai写”、“前端代码 ai 写的比人好” → 对 AI 生成前端代码的强烈信心。
• “Web 技术是好技术。画 UI 做交互太方便了。” → 认可 Web 技术的实用性，尽管对其复杂化有微词。
• “让 emacs 做个纯粹的编辑器吧” → 面对 Emacs 万能化的疯狂，有人呼吁回归本质，但立刻被反驳“已经回不了头了”。
• “emacs 没有一刻在这条路上” → 说明 Emacs 早已不再是简单编辑器，而是自成生态。

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

• dsh 的具体能力与局限：群内讨论显示 dsh 很强大，但未明确其独特性。值得研究：它相比其他 AI agent（如 Copilot、Cursor）的优势是什么？特别是它“Web 图形界面”的实现方式。
• Emacs 与手机交互（ADB + AI）：提出的“用 ADB 截图 + OCR 控制手机 App”方案具有前瞻性，可作为 Emacs 生态扩展的方向，值得探索其技术实现（如用 term-adb 或 Emacs 内调用系统命令）。
• 后端渲染（LiveView）：作为现代 Web 渲染方案，值得关注其相比虚拟 DOM 的优劣，尤其在交互频繁场景下的表现。
• matrix-rust-sdk 构建 Emacs 插件：群友声称要快速实现微信/Matrix 插件，这一项目若开源，可能成为 Emacs 聊天生态的重要补充。值得关注其进展。

观点延伸

当天最值得咀嚼的，不是“哪个工具更强”，而是两种自动化冲动同时出现了：一边是“写代码都不用自己写了”“电脑自己在写代码”，另一边是把聊天、外卖、支付乃至手机 App 都搬进 Emacs。它们背后其实是同一个愿望：把意图直接变成结果，尽量跳过中间那些令人厌烦的界面和重复劳动。

1. AI 编程的分水岭，不是生成速度，而是验证闭环

群里对 dsh 的兴奋，来自“已经能发消息了”这类可见结果，而不是它能不能生成一段漂亮代码。这说明 AI 编程工具真正的竞争力，正在从补全函数转向推进任务：理解目标、修改多个文件、运行程序，再把结果交回来。

但“前端代码 AI 写得比人好”只能在局部成立。前端最容易被自动生成，却也最容易把复杂度藏起来：状态边界、错误恢复、权限、可测试性和后续维护，往往不会因为界面能跑就自动消失。工程上更可靠的判断标准应该是：给 agent 一个可复现的验收条件，它能否自行运行测试、展示差异，并在失败后继续收敛。没有验证闭环的“全自动”，只是把编码成本转移成了审查成本。

2. Emacs 万能化的核心不是“能不能接入”，而是“哪些动作值得被统一”

用 ADB 截图、识别手机界面、操作美团，技术上最有意思的不是把美团窗口显示在 Emacs 里，而是它把 GUI 操作变成了一个可编排的工作流：获取状态、理解状态、执行动作、确认结果。这个抽象同样适用于聊天、邮件和代码工具。

不过，读取信息和执行不可逆动作必须分层。浏览订单可以依赖 OCR 或视觉模型，发送消息需要明确确认，支付则应要求结构化金额、收款对象和最终人工确认。否则，“Emacs 是统一入口”很快会退化成“所有风险都集中到一个模糊的自动化入口”。真正成熟的 telega.el 式体验，不是把所有服务强行塞进 buffer，而是为每类服务建立稳定的数据模型、键位语义和失败回滚路径。

可继续研究/实践

可以做一个最小实验：让 Emacs 统一接入一个聊天服务和一个手机只读页面，只允许 AI 完成“读取—提取—生成草稿”，不允许直接发送或支付；所有动作记录原始输入、模型判断和最终确认。这个实验能验证的不是“Emacs 能不能控制一切”，而是统一界面在什么边界内真正提高了可控性。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：Magit 性能之痛与“功能 vs 速度”的取舍

本日讨论围绕 Emacs 最核心的 Git 客户端 Magit 在大仓库场景下的性能问题展开，并延伸出对底层渲染引擎的探讨。这是开发者日常最直接的痛点，也是解决方案最丰富的主题。

痛点共识：

• Magit 在大文件/大仓库下“卡得用不了”，执行 git diff 甚至可能“卡几分钟”。
• 根本原因在于：Magit 的 diff 和 status 刷新是同步的、且未做增量计算，每次操作都触发大量完整进程调用。
• 更底层的问题还牵扯到 Emacs 自身的渲染引擎 xdisp.c：处理带 :box 属性的文本时，为了判断“相邻字符是否也有 box”，会重复执行大量完整的 face 查询，导致渲染几十万字文档时“输入一个中文要等 10 秒”。

解决方案与观点：

• 用 magit-fast-mode（来自 magit-fast 项目）：通过“多个 section 共享一次 git status；不调用 git diff/不生成 hunk；不插入详细 diff/diffstat；简单 git log 格式化；用 --no-renames 降低 git 状态计算成本”大幅提速。代价是牺牲了 diff/hunk 展开、部分 stage 操作、重命名检测，并作为全局 minor mode 影响所有 Magit 缓冲区。本质上是“用功能丰富度换刷新速度”。
• 拥抱替代品：有人提出用 vc（Emacs 内置）虽然功能少但“日用问题不大”；也有人推荐 Sublime Merge（“反正免费用”）、IDEA。
• 根治问题需 Patch Emacs 源码：群友指出，真正的性能瓶颈在 xdisp.c 的 box 渲染逻辑——只需要解决“重复计算 face 查询”的问题，显示性能就能大幅改善。但这需要修改 C 源码并重新编译，或者更极客的做法是“改二进制”（直接修改编译产物的汇编/机器码）。群友分享经验：二进制 patch 的坑在于代码可能被内联，无法照搬源码逻辑，需要 AI 辅助分析，最终不如直接拉源码编译。
• 心态层面：“习惯改源码”——有位群友表示已经 patch 过 ffmpeg、今天还改了显卡驱动，改 Emacs 源码只是常规操作。

专题二：r/emacs 版主“镇压”与社区“出走”计划

围绕 Reddit 的 r/emacs 子版块的讨论呈现出一种技术社区的幽默与批判。

• 起因是一位群友发布 magit-fast 项目的帖子，疑似被版主盯上或自动标记（“被版主盯上了？”“你触碰了 reddit 的一些规则”）。
• 群友猜测“r/emacs 已经被 vim 间谍渗透了”，并戏称自己“被扼杀在摇篮里”，因为 magit-fast 对 vim 用户来说“太过好用”。
• 由此衍生出“创建 Reddit fork”的想法：NEO Reddit / Neoddit，但从零开始写或基于 Discourse 搭建均被讨论（“不开源你 fork 啥”）。也有人冷静指出“emacs-china 还不够吗”。

专题三：AI 编码的幻觉问题（Elisp 场景）

一位群友报告 DeepSeek-Flash 写 Elisp 时幻觉严重：“编造不存在的函数（window-side、get-buffer-windows、remove-if）、括号没配对、把变量当函数用”，在摆窗口任务里约一半调用失败。

• 结论：这是模型训练不足导致的通病，“没办法从根源解决”，但“遇到了可以让它快速修复”。
• 一个可行的增强方案：引入 MCP server 来提供实时的 Emacs/Elisp 环境反馈，引导模型修正。

---

🔑 关键概念与技术解析

• magit-fast-mode：由 zHaOdANiuu 开发的 Magit 加速模式。核心思路是跳过 diff 计算、共享 git status 结果，并将状态界面简化为“文件状态列表”。这是一个用功能换取速度的全局 minor mode。
• xdisp.c（Emacs 显示引擎）：Emacs 的核心显示代码。群友指出其在处理 :box 属性的文本时存在重复计算 face 的性能瓶颈——判断相邻字符是否还有 box 会触发大量 face 查询，是大型 Org 文档渲染卡顿的关键原因。
• ob-excali（Org Babel 扩展）：excali-mode 新增的模块，用于在 Org Babel 中执行/嵌入 Excalidraw 画板 DSL，支持节点位置等语法更新。
• “改二进制”补丁技巧：不重新编译 Emacs，而是直接修改编译产物的机器码/汇编指令（如 rdi 参数），适合小改动。但代码内联后无法直接对应源码，需要 AI 分析上下文。
• MCP server（Model Context Protocol server）：一种为 AI 模型提供上下文和工具调用能力的服务器协议，在本次讨论中被提议作为“AI 写 Elisp 时实时纠错”的解决方案。

---

💎 碎片知识与金句拾遗

• “赔钱机场，一个月 1.5r 100G”：群友分享的超低价 VPN 服务（“机场”为代理服务暗语），并提到备用方案 ikuuu。
• “微信有点离谱：手机端退出登录电脑端也会自动退出”：对微信登录态的吐槽。
• “双击标题栏可以自动全屏和切换默认大小”：群友发现 Windows 的一个默认行为，虽是“任务管理器代码”里的细节，但对多数人仍是新知识。
• “Sublime Merge 免费用”：有人回应“啊？啥时候免费了”——说明其免费策略已经持续相当长时间。
• “我想解决 org-modern 这种对几万字文档渲染吃力的情况，不可避免地要修改 emacs 底层的 xdisp.c，唉...”：一句典型的极客叹息，随后是“习惯就好”“我连 ffmpeg 都 patch 了”。
• “我的 reddit 到现在都没解封”：说明账号申诉流程不透明，进一步强化社区“出走”情绪。
• “现在大家都比较推荐别人用 buzz 和 raft，不太见到别人推荐 multica 了”：可能指代某个代理工具（如 sing-box 的 fork），但无更多上下文，只记录现状。
• “raft 不开源，buzz 我当时用的时候不行... 所以甚至我当时都懒得提一嘴”：对工具的个人评价，点出“开源”与“实际体验”的双重考量。

---

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

• magit-fast 项目：当前讨论最热门的实用项目。其“牺牲功能换速度”的设计思路是否可被 Magit 官方吸收？值得跟进。
• Emacs xdisp.c box 渲染优化：群友已经定位到“重复 face 查询”这一核心瓶颈。这是一个极具价值的低层性能优化方向，若能提交补丁到上游，将惠及所有大型 Org 文档用户。
• excali-mode + ob-excali：把 Excalidraw 画板嵌入 Org Babel，属于“数字花园”式笔记流的新尝试。值得观察其对知识管理生态的影响。
• AI 写 Elisp 的 MCP 服务器方案：提出用 MCP 给模型提供即时环境反馈，解决幻觉。这是一个通用思路——任何“AI 写代码”场景都可借鉴。
• NEO Reddit / Neoddit 社区项目：目前只是口头构想，但“从零写”的提议若能落地，会是 Emacs 社区的一次基础设施实验。

观点延伸

当天最值得咀嚼的，不是“Magit 到底该不该换”，而是一个更普遍的工程判断：当工具的默认能力开始让核心操作失去可用性时，减少功能并不是妥协，而是在重新定义系统的性能边界。

1. magit-fast 的价值不只是提速，而是把“交互反馈”放回第一优先级

讨论里给出的方案很克制：共享一次 git status，跳过 git diff、hunk、diffstat 和重命名检测，把 Magit status 降级成简化的文件状态列表。它牺牲了审查细节，却保住了“我点击之后马上知道发生了什么”。

这说明性能优化首先是交互设计问题，而不只是算法问题。一个功能完整但要卡几分钟的界面，实际等于把用户赶去别的工具；一个功能少但反馈稳定的界面，反而更适合高频操作。更合理的方向可能不是全局启用或彻底放弃，而是把“快速状态查看”和“深入 diff 审查”拆成两个明确模式：前者追求低延迟，后者允许用户主动承担计算成本。性能预算应当绑定到操作意图，而不是平均分配给所有功能。

2. AI 写 Elisp 的失败，暴露的是“可执行反馈”缺失，而非单纯知识量不足

群里提到模型会编造函数、括号不配对、把变量当函数用，摆窗口任务约一半调用失败。这里最关键的不是模型“记错了几个 API”，而是它缺少一个能快速告诉自己“这段代码在当前 Emacs 里到底能不能运行”的闭环。

因此，MCP server 的意义不应只是给模型塞更多文档，而应提供窄而可靠的验证接口：检查符号是否存在、在隔离环境中执行表达式、返回真实错误位置，并保留窗口与缓冲区状态的最小复现。对 Elisp 这类动态语言而言，实时评估反馈往往比继续堆训练语料更有效。工程上要衡量的也不只是一次生成是否正确，而是失败后能否在一两轮内收敛。

3. xdisp.c 讨论提醒我们：个人工作流最终会撞上底层实现

从 org-modern 几万字文档卡顿，到输入中文需要等待十秒，问题已经不是“换个配置”能解决的。群里定位到带 :box 文本渲染时重复进行 face 查询，这种具体的性能假设一旦被验证，就值得从个人补丁上升为上游性能议题。相比二进制修改，拉源码、建立基准、提交最小补丁更可能形成长期收益，也更容易让后来者复现和维护。

可继续研究的方向：为 Magit 的快速模式、Elisp MCP 验证闭环和 xdisp.c 的 box 渲染分别建立可重复基准，记录首次反馈延迟、完整刷新耗时、失败修复轮数与大文档输入延迟。只有把“感觉很卡”和“快很多”变成可比较的数据，功能与速度的取舍才会从口号变成工程决策。