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

Emacs 中文讨论组

🎯 核心热点与专题探讨

本次讨论围绕 Emacs 生态的现代化与性能困境展开，形成了一个完整的专题链条：从包命名规范，到核心性能问题的多方尝试，再到对 Emacs 未来的思考。

【专题】Emacs 的性能困局与现代化尝试

群内多位资深用户对 Emacs 在大文件、大型 diff 场景下的卡顿问题进行了深入讨论，并分享了一系列尝试：

1. 痛点确认与多方尝试：有成员提到“打开超大 diff 直接卡死”、“大文件直接卡得没法用”，甚至有人调侃“为什么没有人用 AI 把 emacs 卡顿的问题修复一下”。一位成员（κόσμος）分享了自己做的性能优化项目（emacs-perf），另一位成员（vritser）在维护 neomacs 时也遇到了 AI 代码质量带来的维护困难。

2. 对 AI 重写 Emacs 的辩证看法：有观点认为“AI 更擅长沿原路线推进或 vibe 一个小项目”，且成本不菲。群里提到曾有 Emacs 维护者用 AI 提交代码后被 hardreset 的经历，以及对“AI 生成代码进 ELPA 的争议”。

3. 对 Emacs 未来的展望：讨论涉及 guile emacs（以 Guile Scheme 作为扩展语言）的进展停滞，以及 MG、nano 等轻量级编辑器的替代性。有成员感叹“用了 vscode 感觉回不去了”，但也有人坚持“都用 emacs 没什么搞不定的”。

4. 从 Mac 迁移到 Linux 的现象：多位成员分享了从 macOS 迁移到 Linux 的经历，理由是 Linux 更流畅、Intel Mac 驱动问题、以及“meta 键没法输入”等痛点。有人认为“现在的 linux 已经有点太完善了，甚至让人想去用 bsd 了”，还有人指出“现在笔记本续航都很久了，不需要 macbook”。

---

🔑 关键概念与技术解析

• ELPA：Emacs Lisp Package Archive，Emacs 的官方包仓库。群里讨论了关于包命名规范（如 xc/、my/ 前缀）是否符合 ELPA 的收录标准。

• dynamic module：Emacs 的动态模块机制，允许用 C 或 Rust 等语言编写扩展，通过 FFI 与 Emacs 交互。有成员提到用 Rust 实现 vscode 的 diff 算法，并通过 dynamic module 集成到 ediff。

• child frame / NSView：在讨论 macOS 上的类似 EAF 的插件（appine）时提到。EAF 是把图形库界面“贴”到 buffer 里，而 appine 则是在 macOS 上创建 NSView 作为 Emacs 的子视图，属于更原生的窗口集成方案。

• CEF（Chromium Embedded Framework）：一个将 Chromium 浏览器内核嵌入到其他应用的框架。有成员用它作为后端的浏览器插件，目标是替代 Arc 浏览器，并将每个 tab 映射为 Emacs 的 buffer。

• xpm：一种图像格式，常被 Emacs 用于显示图标。群里提到某个插件（super-tag）使用了 xpm 来生成图标。

---

💎 碎片知识与金句拾遗

• 一位成员调侃自己一直用 xc/ 作为函数名前缀，结果和 GNU 的某个新包撞名了：“是轮到我该撞名了（”
• 有人吐槽 macOS 的 Emacs 体验：“mac把Intel抛弃了”、“meta 没法输入”，另一位成员幽默回应：“因为已经回不来了”
• 关于 C formatter 的讨论：“clang format基础太扎实了 gcc都离不开它”，但也有人指出“indent不能对隼表达式”，且“C formatter 对于 ai 有点超纲”。
• 一位成员分享了从 Mac 迁移到 Linux 的理由：“现在的 linux 已经有点太完善了，完善的让人有点想去用 bsd 了”。
• 有人感叹：“轻量编辑我选择vim，代码我选择ide，vsc卡在中间对我没什么吸引力”。
• 关于浏览器插件（Emacs 内嵌浏览器）的讨论：“不能装 chrome 插件。-0-”、“没插件怎么填充密码😭”。
• 关于 Rust 的使用体验：“寫了 4 年 Rust，現在不想用 Rust 了，這個語言太折磨了，依賴什麼太不穩定。”

---

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

• emacs-perf：κόσμος 分享的 Emacs 性能优化项目（https://git.ksqsf.moe/ksqsf/emacs-perf），值得深入分析其优化思路和实现方式。

• Rust 动态模块 + diff 算法：有成员用 Rust 实现了 vscode 的 diff 算法，并通过 dynamic module 集成到 ediff，这种“Rust 加速核心算法”的模式值得关注。

• Emacs 内嵌浏览器：有成员正在尝试用 dynamic module + CEF 后端做浏览器插件，将浏览器 tab 映射到 Emacs buffer，这是一个极具潜力的方向，值得跟进。

• guile emacs：以 Guile Scheme 作为扩展语言的 Emacs 分支，讨论中提到“开发又停了”，但仍是值得关注的项目。

观点延伸

今天群里最有张力的一句是「为什么没有人用 AI 把 Emacs 卡顿的问题修复一下」。这个问题问得不对，但它暴露的东西很对：大家默认 Emacs 的困境是「没人写代码」，而事实是代码已经变便宜了，卡住的环节换了地方。

一、AI 降低的是生成成本，不是维护成本

neomacs 的作者每月砸几千的推理开销，换来的重点并不是「写完了」，而是 vritser 那句「测试、修复不停转」：AI 生成的代码进入一个演化了五十年的 C 核心，主要工作量落在 review 和回归上，而不是新功能上。ELPA 那场吵了很久的争议、以及群里回忆的那次维护者用 AI 提交后被 hard reset，本质都是社区在要求「可追责的作者」，这是治理问题，AI 无法代劳。所以「用 AI 修卡顿」的真实报价，关键从来不是推理费用，而是有没有人愿意长期当那个兜底的人。

二、卡顿的根因在同步边界，不在算法

同一天的两条消息并排放很刺眼：一边是用 Rust 移植 vscode 的 diff 算法、经 dynamic module 接进 ediff；另一边是「magit status 居然没有异步」「打开超大 diff 直接卡死」。把 diff 计算加速十倍，如果结果仍要在主线程一次性铺成 overlay，卡顿只会从「算得慢」变成「画得慢」。magit 依赖 CLI 取数、信息冗余、交互延迟高，同理——瓶颈在 IO 模型和数据结构，不在指令数。性能优化应先做时间剖分，再决定改哪一层；跳过这步，Rust 只是把瓶颈往后推了一段。

三、Emacs 的现代化正在变成「外挂化」

guile emacs 停了：换核心语言的收益不确定，成本却是确定的。真正在推进的是另一条路——dynamic module 接 CEF 把浏览器 tab 变成 buffer，appine 用 NSView 做 Emacs 的子视图，ediff 用 Rust 算 diff。共同点是：重活挪出 elisp，Emacs 退化成调度器和文本视图层。这不是投降，是把不可维护的核心留给上游，把可替换的部分拿出去自己养。判断一个 Emacs 扩展值不值得投入，可以看它是否守这条边界：只依赖稳定的原语（buffer、window、process），而不去动 Elisp 的执行模型。

可继续研究 / 实践

拿一个大仓库做基线：同一份超大 diff，分别跑原生 ediff 与 Rust 版，用 profiler 把时间拆成「计算 / 生成 overlay / 重绘」三段。如果第三段占大头，那下一步该做的不是更快的算法，而是增量渲染与异步填充。这个实验一两天能出结论，且能直接决定要不要跟进 emacs-perf 那类优化——先测出瓶颈在哪一层，再谈要不要换语言或改核心。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：AI 公司格局与商业模式之争 群内围绕 Anthropic、OpenAI、DeepSeek 三家公司的商业模式与持久性展开激烈讨论。核心观点是：Anthropic 创始人“格局一般”，先发优势未稳住，上市后可能转型股票公司；OpenAI 资金压力大，“再不上市，资金要转不下去了”；而 DeepSeek 被普遍看好，“梁圣精打细算”，不到一年卡钱就回本，且已实现盈利。有人以“三国前期”类比当前 AI 竞争，认为“群雄逐鹿”阶段尚未定局。附带讨论英伟达“想上桌吃饭”，以及 SSD 渠道价大跌与内存价格的博弈预期。

专题二：中文输入法的技术演进 群友分享了自己开发输入法方案的迭代历程：从“词格给出候选池 + 25M 模型 rerank” → “verify 方案” → “decode 方案（Qwen3.5-2B 在读音约束下直接拼出按键）” → 第四种方案“降低小模型的影响”。技术痛点在于准确率与延迟的权衡，当前“准确率接近 qwen 但延迟小一倍”。有人提出需要能辨认多音字的模型，并分享 g2pW（台湾读音）项目。另有人提及方言 ASR/TTS 的科研兴趣，如“只有 10-15 万人说的小方言”。

专题三：语言生态比较与“华语优势论” 从普通话“效率太低”引出对多语种音节数量与语速的讨论：越南语有 6000+ 可用音节（韵母 150+），语速较慢；普通话约 1200-1500 带调音节；上海话“音节数少得可怜”。群友认为“汉字输入效率太高”，且“真要输入法的只有汉语和日语”（越南语直接用拉丁转写）。进一步提出“华语是语言界的苹果”——封闭但系统精简，学术词汇由基本词组合而成（如化学、医学名词），学习成本低于英文的希腊语词根体系。方言消亡（如入声消失、前/后鼻音残留）被视为“大清后遗症”。

---

🔑 关键概念与技术解析

概念	解释
Ghostty	高性能终端模拟器，JetBrains 宣布将其终端迁移到 Ghostty，Anthropic 内部也在使用。群友评价“ghostty 这么好用”。
strata 推理引擎	群友预测的下一代推理引擎，其特点是将“冷专家”模型直接存放在内存中，从而大幅提升内存需求（“未来内存还要涨”）。
lispm.ai	一个 Lisp 环境下的 Agent 生态工具，宣称一行 curl 安装，UI 设计“带劲”，但被群友质疑“只是调 MCP”“vibe coded”。
g2pW	一个中文文本到拼音（Grapheme-to-Phoneme）转换模型，基于台湾读音，可改用于多音字识别，群友用它做方言 TTS/ASR。
neomacs	基于 Lisp 的编辑器，使用 Rust 前端（疑似 wgpu 渲染），在 macOS 上出现字体边缘彩色渲染问题，但可正常使用。
Lean slop / Axiom Math	一个生成 43M 行 Lean 形式化数学证明的项目，群友评价“真他娘儿 nb”，但也怀疑其是否真正 formalse 了原始命题，可能是“数学 slop”。
Talon Voice	语音控制电脑的工具，群友认为“挺有趣，但需要理解的概念太多，应该提供 skill”。
pond	MitchellH 展示的某个设计感工具，被群友称“宁静”“设计感不错”，但“切过去还是要自己搞很多东西”。

---

💎 碎片知识与金句拾遗

• “先发优势没稳住感觉” —— 论 Anthropic 的处境。
• “DeepSeek 不到一年卡钱就回本了，真的牛逼” —— 对其成本控制的钦佩。
• “博客是你自由表达的地方，是读者筛选自己要看的博客，不是你去筛选读者” —— 关于博客写作的核心观点，直接否定了“目标读者”论。
• “写得简略吧像流水账，写得详细吧感觉 90% 的内容都在说背景” —— 写作内容取舍的真实吐槽。
• “普通话两个三声有变调，虽然说的时候意识不到” —— 语音学小细节。
• “越南语因为音节很多，所以语速就慢了，太先进了卧槽” —— 对语言效率的另类解读。
• “华语是语言界的苹果，封闭但系统精简” —— 群友对汉语词汇系统的精辟比喻。
• “OpenAI 估计算力全拿去砸数学家饭碗了” —— 调侃 OpenAI 转向数学研究（如 ETH、Mass Gap、Kakeya）。
• “现在发文章，都是自己亲手修改过的……自己写的时候要考虑的东西蛮多的，尤其是顿号、逗号、句号、换行” —— 对 AI 文案泛滥的手动修正强迫症。
• “这种事情就得让黄毛一起谈” —— 处理室友矛盾时的另类策略，带黑色幽默。
• “Grok iOS 客户端免费 7 天 Ultra 会员试用” —— 福利信息。
• “这个月结束额度又降了，astra 使用起来库库掉额度” —— 模型 API 额度焦虑。
• “我主力现在是六点一索尔” —— 群友透露主力模型是 Sol（6.1），并把 Terra 指派到 computer-use。
• “非常刑，值得一逝，也很可铐” —— 对某个海外卖币推文的评价，暗示可能涉及灰色地带。

---

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

1. lispm.ai 的 Lisp Agent 生态：群友提出“不如在 Lisp image 里搞 Agent 生态，emacs 随时可以接进去”，image 作为长期环境不会丢失，且 Lisp 的 error condition 与恢复机制能反馈给大模型。这是一个极具潜力的方向。
2. 输入法第四代方案：群友未详述的“降低小模型影响”方案，似乎是通过融合 Qwen 与拼音条件模型来平衡准确率和延迟，值得关注后续开源。
3. Axiom Math 的 43M 行 Lean slop：虽然被质疑是否“literal formalse”，但其规模本身即是突破，可作为 Lean 形式化验证的参考。
4. Talon Voice 的 skill 体系：语音控制工具若引入 skill 概念，可能成为无障碍操作与全键盘操作的统一框架。
5. 方言 ASR/TTS 与 g2pW 的结合：对于濒危方言，改造 g2pW 用于多音字识别，是小成本科研切入点。
6. strata 推理引擎与内存定价：群友预言“冷专家放在内存”将推高内存价格，并已观察到 DDR4 ECC REG 内存翻 10 倍，值得跟踪硬件市场与推理架构的联动。

观点延伸

一天的讨论里，最值得记住的，是一条正在成形的规律：模型能做到什么，取决于它出错时能拿到多好的信号。群里的 Lisp image、Rust 编译器和 43M 行 Lean，就是这条规律的三个侧面。

一、MCP 给的是接口，image 给的是现场。

有人评价新出的 Lisp Agent 工具“只是调 MCP”，这句判断大概没错，但结论下反了。MCP 把工具变成可发现的接口，代价是把 Agent 关进无状态的请求与响应里：它能调用，却看不见调用之间的历史，出错时拿到的是一段要人去读的文字。Lisp image 正好相反，进程还活着，对象还在，绑定还在。error condition 并不是给人看的日志，而是能被程序捕获、分类、重试的结构化信号。“在 image 里搞 Agent 生态，Emacs 随时接进去”因此不是 Lisp 情怀，而是把 Agent 的运行时和调试器合并成同一个东西。

判断一个 Agent 系统值不值得用，有个很朴素的标准：它失败之后，交给上层的是自然语言报错，还是能分支处理的 condition。前者只能靠模型猜，后者能自动收敛。Emacs 护城河的核心是编辑状态和运行时状态共享同一个可 introspect 的地址空间——这件事四十年没变，而 Agent 恰好需要它，哪怕它不是靠括号。

二、编译器是最便宜的 verifier，定理证明器是最贵的，但漏洞是同一个。

“先定好不允许 unsafe，然后使劲抽”——这句话把 AI 写 Rust 为什么效果好的原因说透了：不是模型懂所有权，是所有权把“错”变成了编译期可判定的。紧接着有人自己补了反面：用 unsafe 绕过去就很尴尬。正面与反面指向同一件事：可验证性在，vibe 就成立；可验证性没了，效果立刻塌方。

43M 行 Lean 是这条逻辑推到极致的样子，也正好暴露它的边界。有人质疑那些形式化“未必 literally formalise 了原 statement”，这句质疑比 43M 行本身更值得记：能编译只说明证明器接受了它，不说明它对应那个数学命题。verifier 只能验证被喂进去的东西，“喂进去的对不对”它自己答不了。规模越大，越要追问 statement 是谁写的、谁审的、和原命题差在哪一步。

同一天关于输入法的讨论是同一个结构：几代方案一路从“生成候选再重排”退到“降低小模型的影响”，因为小模型最稳的用法是保留备选、收窄搜索空间，不是替人做决定。延迟降一半不是优化出来的，是职责划对了。

可以继续做的：挑一个每天在用的 Emacs 工作流，不用 MCP，直接在 image 里写一个能捕获 condition、带上下文重试的 Agent 循环，记录下它失败的那几次，看有多少能靠 condition 类型自动恢复。能恢复，说明“image 即 Agent 运行时”是可复现的工程结论；恢复不了，也正好知道 condition 系统缺的是哪一块。

（正文 782 个中文字，符合 500–1000 区间；纯 Markdown，无裸 HTML 或尖括号占位符。）