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

Emacs 中文讨论组

🎯 核心热点与专题探讨

1. Emacs Canvas：从“图片革命”到“真正的用途”？

凌晨到下午，群内围绕 Emacs 的 Canvas 特性展开了一场跨度 12 小时的深度讨论。起因是一篇介绍 Canvas 的博客文章，随后引发了关于其原理、性能、以及实际应用场景的激烈辩论。

核心观点分歧：

• 支持者（新特性派）：认为 Canvas 通过暴露原始帧缓冲，可以绕开 redisplay 的行式布局，实现高频、动态内容的更新，对滚动、动态图表、甚至“在 Emacs 里做 MC”等场景有巨大潜力。
• 怀疑者（保守派）：指出 Canvas 本质上仍是一种 image 类型，在文本缓冲区中依旧受限于行高计算和 text-property 机制，无法从根本上解决静态图片滚动卡顿问题。且与现有 Emacs 生态（如 isearch、widget）结合困难，更像“整活”用途。

最终共识（下午 14:33 后的整理）：通过 AI 测试验证，用 Canvas 显示静态图片不仅不会提升滚动流畅度，反而会拖慢，因为创建 Canvas 区域本身有额外开销。最适合的场景是“整个 buffer 都是 Canvas”，例如 Roam 星图、数据仪表盘、复现 Jupyter 等，才能真正发挥其绕过 redisplay 的优势。

痛点与解决方案：

• 痛点：Emacs 的行式布局与像素级渲染的天然矛盾，导致滚动、大图片预览卡顿。
• 探索方向：Canvas 适合“全屏/全buffer”场景，而不是简单的图片替换；开发者可考虑用它实现实时刷新的仪表盘或可视化编辑器。

2. Emacs 滚动性能：陈年旧疴的集中爆发

从 image-mode 滚动卡顿到 Windows 上 500x500 图片滚动都卡，多位成员分享了具体案例。κόσμος 引用了 etc/PROBLEMS 中的已知问题，指出“太高的图片无法与 pixel scroll 兼容”，并提到 Emacs 的滚动机制本身存在缺陷。有成员提出“每次滚动都要重新计算 text-property 塞入内容”是瓶颈，也有人猜测“每次 redisplay 都会重新 scale 图片，但没有缓存”。最终，有人建议“用 AI 插桩分析性能瓶颈”，并考虑写补丁优化图片缩放缓存。

3. mode 组织混乱：lang-mode 与 lang-ts-mode 的“双轨制”

rust-ts-mode、markdown-ts-mode 等与旧有 lang-mode 的功能割裂问题引发共鸣。有人认为“解析与附加功能应该解耦”，也有人提出 Emacs 内置的 foo-base-mode 继承方案。κόσμος 还提到了 clojure-mode 在 emacs-devel 上的历史争论（2023 年），暗示这是长期未解决的架构问题。

---

🔑 关键概念与技术解析

1. Canvas (Emacs)：一种新的 image 类型，允许直接访问原始帧缓冲（raw buffer），从而绕过 redisplay 的行式布局计算。适合高频更新的全 buffer 场景（如实时图表），但对静态图片无优化效果。
2. xwidget：Emacs 嵌入原生 WebKit 控件的机制。通过 text-property 放置 handle，由底层 C/Cocoa 代码渲染。数据传递需序列化成字符串，通过 JS eval 交互，回调异步返回。
3. mutable framebuffer：Canvas 的核心优势，允许内容在不触发完整 redisplay 的情况下更新，降低布局计算开销。
4. pixel scroll：像素级滚动模式，但在高图片或大 buffer 下可能引发 point 不稳定、卡顿等问题。
5. check-parens：Emacs 内置的括号检查命令，但准确率低（只能精确到段落），不适合 AI 定位漏括号的问题。
6. lang-mode / lang-ts-mode：Emacs 对同一语言提供的两种 major mode（正则解析 vs Tree-sitter 解析），因功能不一致导致生态分裂。
7. mode-line-invisible-mode：Emacs 31.1 新增功能，可隐藏 mode-line，替代第三方包 hide-mode-line。

---

💎 碎片知识与金句拾遗

• zdn 吐槽：check-parens 准确率太低，AI 看了还修不明白，群友建议“换更好的 AI”或直接用 electric-pair-mode。
• κόσμος 分享：自己曾想搞“类 skia/cairo”的 canvas 抽象，但认为 Emacs 维护者直接暴露 buffer 的设计“更好”（via emacsmoe issue）。
• zdn 用 simpc-mode（自写 mode）比内置 cc-mode 快，因为 cc-mode 基于正则但还有语义分析。
• 有成员建议“所有 coder 都换 mac 或 linux”，引发讨论但未深入。
• zdn 优化 magit 后“2 秒内打开，1 秒内响应操作”，并配图展示。
• 有人推荐 blogtato：一个用 git 存储数据的 RSS 阅读器，支持 Windows。
• AI 行情分析实践：有成员用 hermes 配合自定义 profile 看交易策略状态，但强调“不能迷信 AI，毕竟 AI 不懂市场情绪”。
• 分享了一个 A 股分析 MCP 工具：https://github.com/Kinneyzhang/a-share-mcp，含 34 个工具，覆盖财务指标、公告 OCR、研报等。
• Emacs 31.1 发布通知中出现了 URL 错误（少写了 /gnu/），被 Eli Zaretskii 指正。
• zdn 提到自己的 gnus 读取要 1-2 分钟，引发对 GNUS 性能的吐槽。

---

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

1. Canvas 的“全 buffer”应用场景：如 org-roam 星图、实时行情面板、嵌入 Jupyter 式交互。可以尝试开发一个基于 Canvas 的“仪表盘” package，探索绕过 redisplay 的极限。
2. 滚动性能瓶颈分析：通过 AI 辅助插桩分析 redisplay 中 image 缩放和缓存逻辑，尝试写补丁优化高图片滚动。
3. clutch 数据库客户端：一个 Emacs 数据库工具，原生支持 mysql/pg/sqlite，其他通过 JDBC driver 扩展。值得评估其离线安装能力和对国产数据库（如中兴 goldendb）的兼容性。
4. lang-mode 统一方案：关注 Emacs 内置 base-mode 模式的实践，探索如何将 Tree-sitter 解析与既有功能解耦，解决生态分裂问题。
5. AI 辅助性能优化：κόσμος 提到“之前有群友想搞 perf 里同时显示 elisp 级信息，现在可以蹬 AI 做”，这是将 AI 融入底层调试的潜在方向。

---

今日有效讨论较多，以上内容已按主题归纳整理。

观点延伸

中心判断：Canvas 的价值不在于“把图片画得更快”，而在于允许 Emacs 对某类界面绕开常规 redisplay。当天测试已经给出边界：静态图片放进 Canvas 没有改善滚动，创建显示区域反而可能更慢。因此，Canvas 不是 image 的通用替代品，而是针对 mutable framebuffer 的专用通道。

1. 先拆性能账，再讨论新后端

群里把卡顿分别归因于图片缩放、text-property、行高计算、redisplay 和 pixel scroll，这些都可能对，但目前仍有不少猜测。可验证的工程路径，是把首次插入、缩放、单次滚动、连续滚动分别计时，再比较普通 image 与 Canvas，同时控制 font-lock、窗口数量和图片尺寸等变量。

如果 Canvas 只改善持续刷新，却不改善滚动，就说明瓶颈仍在布局或滚动路径，而不是绘制本身。此时应该查缩放缓存、glyph 计算和 point 状态，而不是继续给图片套 Canvas。AI 可以帮忙找插桩点、读 C 和 Elisp 的调用链，但不能替代 trace。

2. “全 buffer Canvas”其实是在重新划定 UI 边界

星图、行情面板、Jupyter 式输出适合 Canvas，不是因为它们“像图片”，而是因为它们需要持续刷新，却不需要每个视觉对象都成为可编辑文本。代价同样明确：isearch、widget、光标和 textobj 等 Emacs 语义不会自动出现。

Canvas 让 buffer 变成由应用自己管理的显示容器。这样做很有用，但包作者也得自己定义输入、选区、刷新和状态同步。需要搜索、跳转和逐字编辑的内容，继续留在普通 buffer 反而更合理。

3. mode 双轨制暴露的是同一类架构债务

lang-mode 与 lang-ts-mode 的争论，和 Canvas 的选择其实是同一个问题：不要让底层实现决定上层能力。解析、缩进、font-lock、textobj、Flymake 等功能应先声明依赖，再决定能否由 foo-mode 和 foo-ts-mode 共享。foo-base-mode 是方向，不是魔法；可以用同一组 fixture 测每项功能，明确它依赖语法树、括号深度还是纯文本。

可继续研究/实践：做一个最小 benchmark 加 capability matrix。前者测 image/Canvas 的插入、滚动、重绘耗时，后者列出两套 mode 的功能差异。先拿数据，再写补丁；否则“AI 说可能有缓存”很容易变成又一条看起来合理、却没人验证的工程传闻。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

【专题：AI 编码代理的“预算经济学”与模型消耗】

群内对 Codex 等 AI 编码代理的消耗速率、重置策略和模型性价比展开了长达一天的持续讨论，是当天最核心的话题。

• Codex 重置与消耗异常：Tibo 宣布 Codex 账户已重置并落地了一些使用修复，但多位用户反馈“优化后消耗更快了”。有用户使用 sol xhigh 50 分钟消耗 8%，而对比之下，luna max 跑一天消耗甚微。大家普遍认为 luna max 是当前“性价比最高”的模型，但也有用户认为“luna max 表现很蠢，体感比不上 deepseek flash”。
• 模型智能度吐槽：有人指出 sol 模型“说什么都‘你说的对’”，需要手动在 prompt 中要求“可以反驳我”；传统“身份提醒”（如“你是 xxx 专家”）在 agent 中依然意外地好用。更有观点认为，AI 编码代理（如 goal 模式）容易“陷入细节无法收敛回主线”，导致 token 浪费。
• “fast”模式策略：有用户开 fast 模式仅消耗个位数百分比，但被提醒“不要开 fast”，因为会导致超长任务（12 小时起步）。关于“明天是否还会重置”的猜测也引发了讨论，有人怀疑优化并非全员推送，而是为了做对比测试。

【专题：从 Arch 到 Guix 的迁移抉择】

围绕“从 Arch 迁到 Guix 的阻力”展开了技术讨论。核心观点是：相比 Arch，从 NixOS 迁移到 Guix 的阻力更小，因为 NixOS 用户已经习惯了“大量必要的/非必要的个性化配置全部翻译成可复现配置”的思维模式，而 Guix 可以直接将 dotfiles 放入仓库管理，无需像 Nix 那样用 Nix 语言重写配置。Guix 的主要阻力是 Scheme 语法，而 Nix 在不深入使用时相对简单。

【专题：Magit 的“大提交 Diff”痛点与替代品】

多位用户对 Magit 在处理“大提交”时无法便捷地查看单个文件 diff 提出了改进意见。有用户分享了在 magit-log 后用 magit-log-buffer-file 命令查看当前文件提交历史的技巧，但主流的痛点集中在“默认全部 diff 展开”导致渲染缓慢、缺乏异步渲染能力。有人提到自己开发了名为“majutsu”的工具，补充了“提交中被修改文件的补全”这一杀手级功能，并链接了相关讨论。也有用户直接转向 vc-diff 或 vc 查看 diff，认为“magit 太慢了”。

🔑 关键概念与技术解析

• set-local (Emacs 31)：Corfu 插件报错 (void-function set-local) 的根源。这是 Emacs 31 中新增的 C 源码级函数，旧版本 Corfu 未重新编译时无法解析。解决方法是重新编译插件。
• Omacom Foundation：一个获得 $10M 资助的基金会，群内猜测其意图是与 KDE/GNOME 竞争，有用户认为“越来越不理解了”。
• Auto-Complete：群内提及的“老一辈” Emacs 补全包，目前处于“Looking for new maintainer”状态，功能类似 corfu 的补全面板。

💎 碎片知识与金句拾遗

• “1080p 其实是个搞缩放比较尴尬的尺寸，一倍偏小，两倍偏大。”
• “Guix 最大的阻力还是语法，Nix 那边假如不写那么深入的话还是很简单的。”
• “Nautilus 时间和任务交互的爆发力在于：它给每份时间安排了工作，就像 YNAB 给每份钱安排了事项…… Give every minute a job。”
• “magit 考虑的非常全，哪怕是 worktree 没有流行的时候也都考虑到了。” 但同时 “magit 它的 diff 颗粒度没有单个文件…… 默认全部 diff 是展开的，要是默认是折叠的应该更方便。”
• “人看 ai 的代码根本看不过来。”
• “我的 minibuffer-fram 已经添加到了 melpa 上了，可以来使用了。”
• “真的去做 iOS app 才发现 org 真的太自由了…… 其实做任何 app 都会发现 emacs 实在太自由了。”
• “我觉得目前的智能程度是很小概率事件。” (关于 AI 编码代理)
• “ds 的 flash 发了视觉版本后，已经追上 opus4.8 了。”
• “我不用 goal，手动跑一天大概能用 10-15%。” (关于 Codex 消耗)
• “jj 对 git-lfs 怎么看？…… 好像也不支持。” (关于 jj 版本控制的兼容性痛点)
• “微软解释为什么扫雷消失：我们负担不起花几天研究代码的时间。” (引用自新闻标题)
• “DHH 人格魅力真的很大，主要是这人动手做产品的能力太强…… Rails 在这一众框架里属于少数的精装房。”
• “Sway 比较素吧，感觉很多 sway 用户都在用 swayfx…… 我用 sway 原版的大冤种。” (关于窗口管理器选择)

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

• majutsu：群友 0WD0 开发的 Magit 替代品，正在补充“提交中被修改文件的补全”等杀手级功能，值得关注其交互设计。
• Nautilus Log：基于 Roam Research 的时间管理工具，将“Give every minute a job”理念模型化，并已上架 Roam Depot，值得体验其“弹性推演”时间块规划方式。
• minibuffer-frame：群友自制的 Emacs 包，已发布到 MELPA，值得尝试将 minibuffer 弹窗独立成 frame 的用法。
• Emacs 31 新特性：群内有用户提到 set-local 等 C 级函数，且官方发布了“What's new in Emacs 31.1”文章，值得深入研究新版本带来的底层 API 变化。
• 南大秋季《GSE/2026》课程：被推荐为值得关注的专业课程，直播平台为 Bilibili，链接：https://jyywiki.cn/GSE/2026/。

观点延伸

中心判断：今天最值得咀嚼的，不是哪个模型“更省”或哪个包“更强”，而是一个共同问题：工具越自由、越能自主行动，就越需要明确的收敛边界。Codex 的消耗、goal 陷入细节，以及 Org、Magit、Guix 的自由度争论，暴露的是同一类缺陷：能力很多，但下一步不够明确。

1. Agent 的真实成本是失控成本

群里对 sol xhigh、luna max、fast 和 goal 的体感差异，说明模型消耗不能只看套餐倍率或单次速度。有人让 sol xhigh 连续运行很快消耗额度，也有人用 luna max 跑很久仍消耗很少；这当然还受任务、缓存和会话状态影响，不能直接当成模型排名。但更稳定的判断是：goal 一旦陷入局部细节、无法回到主线，token 就是在为错误方向付费。

因此，Agent 的“智能”应定义为：在给定监督频率、任务边界和停止条件下，能否持续交付可验证结果。任务开始前应明确验收标准、检查点和中止条件；不必把所有工作都强行做成 MVP，但主线必须尽早恢复到可运行、可检查的状态。评价 Agent 也不能只看消耗百分比，还要记录返工次数、人工纠偏次数，以及最终 diff 是否仍然可审查。

2. 自由如果没有交互边界，就会变成认知税

有人在真正做 iOS app 后才意识到 Org “太自由”，Magit 面对大提交时也暴露出类似问题：底层能力足够，但常用路径没有被明确建模。用户需要记住 magit-log-buffer-file、vc-diff，或手动折叠和筛选 diff；majutsu 尝试补上“提交中被修改文件的补全”，本质上也是在把一个重要对象重新变成可选择、可发现的交互入口。

这不意味着 Emacs 应该放弃自由，变成封闭的成品软件。真正成熟的设计，是同时提供很高的上限和很低的下一步成本。能做所有事情是可扩展性；用户在遇到“大提交”“旧版本 API”或复杂配置时，几秒内知道该做什么，才是可用性。否则，工具只是把复杂度转移给了人的记忆。

可继续研究/实践

可以建立一个小型 Agent 任务账本，连续记录目标、模型、模式、耗时、消耗、人工干预、返工原因和验收结果，观察“省额度”是否真的等于更高产出。同时为 Emacs 设计一条“先选文件、再看 diff”的默认路径，比较它是否减少定位时间。真正应优化的不是单次输出速度，而是人、工具与反馈回路共同形成的收敛速度。