Emacs 社区日报 2026-10-23

约 6149 字大约 21 分钟

2026-10-23

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

🎯 核心热点与专题探讨

本次讨论主要围绕三个专题展开，其中 Emacs 通知机制与 AI 代码审查的讨论尤为激烈，形成了跨越多轮对话的完整脉络。

专题一：Emacs 通知机制的演进与设计哲学

参与者从个人邮件应用 appkit 出发，深入探讨了 Emacs 内部通知的最佳实践。核心争议点在于展示层与交互粒度的平衡：

现状：内置 + 第三方方案（如 posframe、modeline 组件）已很成熟，但缺乏统一抽象。
关键分歧：nvim-notify 式弹窗过于干扰视觉，而系统通知粒度太粗。多数人倾向分层策略——普通通知放 echo area，重要通知用 posframe 弹框，紧急通知联动系统通知。
新思路：提出用 etaf（Emacs 即时渲染框架）结合 posframe 构建通用通知接口，甚至支持 buffer 内自弹窗。参与者认为这能惠及所有 Emacs 包。
痛点：通知泛滥会失去意义，必须按紧急程度分级。

专题二：RMS 对 AI 生成代码的态度与 ELPA 政策灰色地带

因群友提交的 AI 辅助生成的包被拒绝进入 nongnu elpa，引发对上游政策的辩论：

RMS 的直接回复几乎等同「一票否决」，但群友 κόσμος 指出 RMS 对 Emacs 开发并无绝对权威，日常也常被质疑。
维护者担忧：AI 代码难以被新维护者理解或重写，违背 GNU 包的可维护性原则。而 nongnu elpa 虽非严格意义上的 Emacs 组成部分，但需遵循相同法律政策。
模糊空间：存在「AI 辅助但人工重写」的中间态，但 RMS 发话后只能作罢。群友选择继续自用，并感叹「欺负老实人呀」。

专题三：org-mode 的语法本质与工具演进

由群友对 org 语法「行首命令打头」的观察，引发对 Logseq 设计选择的回顾：

org 语法：命令集中在行首，便于机器解析，但列表与代码块嵌套有局限性。
Logseq：曾被误认为用列表作为容器，实为 headline 结构；最新版已移除 org 支持，群友表示「没有 Org 不想支持它了」。
个人工作流：有人正在重构 org 工作流，并分享了一个纯 AI 生成的 Android 日历应用 orgenda-android（见下文），体现 org 生态的活跃。

🔑 关键概念与技术解析

etaf：一个为 Emacs 提供即时渲染能力的框架，允许将 UI 组件映射到 buffer 或 frame，支持复杂交互。被提议作为统一通知系统的底层基础。
posframe：Emacs 第三方库，可在任意位置弹出独立 frame，常用于补全提示、通知等。讨论中强调其与 etaf 结合能实现「不只是画界面」的交互创新。
appkit：群友自研的 Emacs 邮件客户端抽象，支持多账号多实例，是通知机制讨论的实践来源。
enriched-encode / format-insert-annotations：Emacs 内置的文本属性编码机制，可将 text properties 转换为外部格式，实现存储与输入格式分离。
xcuitest：iOS 的 UI 自动化测试框架，但群友反映其速度慢且需多模态配合，而 Android 可通过 adb 直接模拟操作，开发测试效率显著更高。
RaTeX：Rust 实现的数学渲染库，兼容 KaTeX 语法，用于群友个人项目的公式渲染。

💎 碎片知识与金句拾遗

关于 UI 细节：「有些为了方便起见有些地方让它先用原生组件搭出来，后面再调了」——承认快速原型与完美打磨的取舍。
关于通知设计：「通知不能泛滥，太多就没有意义了。所以按紧急程度使用不同的展示方式是不错的。」——精辟总结通知系统的核心原则。
关于 AI 与开源维护：「AI 写的代码目前是不具备这个条件的」（指无法交给新维护者），反映社区对 AI 代码可维护性的普遍顾虑。
关于 Android 优势：「可以用 adb 操作手机和模拟，测试超级快」——相比 iOS 的 xcuitest 慢且需多模态，Android 的自动化测试生态明显更高效。
关于 org 的顿悟：「这种命令打头的风格，前面是关键词，应该用代码的语法，后面跟着的可以视为内容」——对 org 语法的独特解读。
冷知识：Logseq 最新版（2025年12月）已移除 org 支持，仅保留 markdown。
一个实用的 bookmark 工具：bookmark-gt（群友询问试用情况，未获直接回应）。

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

etaf + posframe 统一通知系统：讨论中提出的「两种模式」（posframe 弹框 + modeline 指示）具有成为通用 Emacs 通知包的潜力，值得关注其后续抽象化设计。
orgenda-android：群友「纯 AI 零人工」生成的 Android org 日历应用，体现 AI 辅助开发在个人工具领域的可行性与边界，是观察 AI 代码质量的现实案例。
macos-screencast-cli skill：位于 forgejo.vhkd.top/pi-hub/macos-screencast-cli，为 macOS 屏幕录制提供 CLI 接口，可能对自动化测试或内容制作有用。
bookmark-gt：群友询问试用结果但未展开，可能是一款新的 Emacs 书签管理工具，值得进一步检索。

观点延伸

中心判断：当天最值得咀嚼的不是“AI 能不能写 Emacs 包”，而是两个讨论得最激烈的话题其实是同一道题——你今天省下的力气，最后记在谁头上。

一、被否决的是“交接”，不是“生成”

这个包被 nongnu ELPA 拒绝，表面理由是 AI，但维护者给出的真实理由是：包进去之后，要能完全交给一个新维护者读懂、甚至重写。这句话把争论的焦点从“作者是谁”拉回到“成本由谁承担”，这比道德层面的指控可靠得多。

但有个细节被轻轻放过了。群友的推测是：对方 commit 里没有 AI 署名，自己这边有。若属实，这就形成了一个很不合理的激励结构——披露的人被挡在门外，不披露的人照进。所以“欺负老实人”说的是一种准确描述，描述的是规则的实际执行方式，而非单纯的情绪表达。

反过来也不能顺势得出“上游错了”。GNU 的准入条件从来都是可维护性，而非流行度，这个门槛本身合理。真正的问题在于它无法被检验：没人能定义“多好懂才算好懂”，于是标准退化成对作者身份的观感。规则一旦不可检验，就必然按印象执行。这种毛病并非 Emacs 独有，凡是“质量标准加人工裁决”的组织都有。

二、通知分层是注意力调度，不是 UI 选型

讨论很快得出一个共识：普通通知走 echo area、重要通知用 posframe、紧急通知走系统通知，以及“两种模式：弹框与 modeline 指示”。方向是对的，但抽象层次选错了。

如果按 renderer（渲染方式）来分模式，就等于把“显示在哪里”当成了主要区分标准。真正的主要区分标准是打扰预算：值不值得打断当前操作、值不值得跨屏、值不值得留存以便回溯。这三个问题定下来之后，用哪个 renderer 就只是实现上的自由选择。顺序反了，包就会被写成一大堆 if 分支。

还有两个被错误地并列在一起的东西：knockknock 那类 modeline 组件之所以好用，是因为它常驻且低噪，只在余光中累积状态；posframe 的本质是瞬时抢夺注意力。两者并不属于同一维度，不该叫“两个模式”。合理的分层是三段：常驻态（modeline 或角标）→ 事件态（echo area，可被下一条覆盖）→ 强打扰态（posframe 或系统通知，必须确认）。中间那层最容易做坏，因为它同时要求“可见”和“可丢弃”。

可继续研究的方向

把通知做成一个带优先级与去重窗口的队列，而不是一个渲染函数：同一个 key 在短时间内多次触发的事件合并计数，超时后自动降级（强打扰在 N 秒内无响应，就退回常驻态），并保留一个可查询的历史 buffer（对应 magit-process 那一路做法）。这套语义可以先用纯 Elisp 来验证，不依赖 etaf；等接口稳定后，再让 etaf 只负责“怎么画”。先确定打扰预算，再谈渲染。

已写入 /tmp/_ext.md（2766 字节，无裸 HTML，行内代码均为反引号包裹）。中文正文约 900 字。两处延伸都标注了来源（维护者原话、echo area 与 modeline 的分工讨论），未引入群里没出现的具体事实；“对方 commit 是否有 AI 署名”明确写为群友推测，未当成结论。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：Arc 浏览器落幕与浏览器替代方案

背景： 群内消息指出 Arc 浏览器被其公司彻底移除，不再维护。成员们对此展开讨论，并积极寻找替代方案。

各方观点与讨论：

现状确认：有成员指出 Arc 已一年多不维护，仅更新 Chrome 内核，现在被完全删除，产品彻底终结。
技术分析：有观点认为 Arc 的技术栈是公司独有的，维护困难，所以选择“重启”或放弃。
替代方案探索：
- 有人提及 Ladybird（一个非 Chrome/WebKit 内核的浏览器），预计今年发布，可能成为新选择。
- 有人分享了 Yet Another Browser (https://yetanotherbrowser.com/)，但指出其是 WebKit 内核，插件兼容性可能存在风险。
- 讨论了 Agent 浏览器，如 Tabbit，作为给 AI Agent 使用的浏览器，也是一个方向。
个人影响：有成员表示还在使用 Arc，对停止维护感到尴尬。

结论与痛点：Arc 的停运给依赖它的用户带来了迁移成本。用户在选择替代品时，主要关注内核、插件兼容性和可持续维护性。讨论中对非 Chrome 内核浏览器（如 Ladybird、WebKit 系）表现出兴趣，但也担忧其生态成熟度。

专题二：AI 编程工具与订阅付费模式讨论

背景： 围绕 AI 编程助手（如 GPT、Claude）、App 订阅制、开发者收益等话题展开多轮讨论。

讨论焦点：

AI 编程体验：成员吐槽 GPT 在生成代码时“转半个小时还没结果”、“加很多没必要的安全要求”，认为其 “harness 出了问题，模型问题很大”。而 Claude 被普遍认为“用起来都够用了”。
订阅与付费：
- 有开发者分享自己的 App（Emacs 相关）定价策略：两周免费试用，0.99 美元/月，并吐槽“数据很差，只有两个人订阅了”。
- 讨论苹果开发者年费 99 美元是“过路费”，独立开发者很难靠订阅赚回成本。
- 提及通过第三方代充 GPT（价格 ¥1043），但存在风险且“被套牢”。
AI 工具性价比之争：
- 成员对 “sol xhigh” 的性价比提出质疑，认为其“降智又慢，毫无性价比”，甚至谐音“傻叉嗨”。
- 有人分享 AmpCode 支持自定义 baseurl，可接入不同模型，并推荐其用于部署测试。
- 有人提及 CommandCode (https://commandcode.ai/zh) 网站流量达 200 多万，侧面反映 AI 编程工具的火爆。

结论与痛点：AI 编程工具在提升效率的同时，也带来了新的“痛点”（如响应慢、过度安全限制）。订阅制对独立开发者而言经济压力大，且用户付费意愿低。模型性价比成为用户选择的关键因素，口碑差异明显。

专题三：Emacs 生态、性能与开源项目

背景： 围绕 Emacs 的性能、未来发展和独立开发项目展开讨论。

讨论焦点：

Neo/Neomacs 项目：
- 开发者 Neo 分享其项目 Neomacs（一个 Emacs 的现代化/性能优化项目），并计划购买 AMD 线程撕裂者 9995WX（约 10 万元）用于跑测试，以确保与 GNU/Emacs 100% 兼容。
- 有成员建议他应依赖 CI/CD 平台（如 GitHub CI）和社区贡献，而非单靠个人硬件。
- Neo 发起了众筹项目 One Million Cells (https://1mcells.com/)，目标是为 Neomacs 的 CI/CD 购买高性能硬件，目前已有群友支持。
Emacs 的未来：讨论认为 Emacs 的问题是“性能”，如果 Neomacs 能以 Rust 化（🦀化）实现“第二春”，可能会带来新的活力。但也有观点认为 Emacs 用户“穷13抠13”，且“固执又保守”，可能看不上 Neomacs。
Emacs 内存优化：提到 telega（Emacs 的 Telegram 客户端）配置优化，包括使用 telega-autoplay-custom-emojis、telega-autoplay-mode 等，并推荐工具 tgs2png 来支持动态 emoji 播放。

结论与痛点：Emacs 的现代化（性能、内存、社区）是核心议题。Neo 的独立开发与“众筹 + CI/CD”结合的模式是一个值得关注的尝试。Emacs 社区的保守性对新项目推广存在阻力。

专题四：独立开发与出海项目

背景： 群内分享了多个独立开发/出海项目，并讨论了相关策略。

项目分享：

Neo 的 One Million Cells (1mcells.com)：一个“百万格子”众筹页面，用户购买格子（cell），支持开发者。已有群友购买并反馈 UI/UX 问题（如拖拽交互、图标形状、位置修改）。
Lucius 的 Emacs App：一款基于 Emacs 生态的 App，采用订阅制（0.99 美元/月），目前订阅量少。
新点子：Neo 提出“地图标注适合休息/工作地点”的 App 创意，但被群友认为“太 neo 了”且可能已有类似产品。

讨论要点：

独立开发者普遍面临“用户池小”、“付费意愿低”的问题。
有人建议通过“众筹”或“大渠道”来推广项目，而非依赖个人知名度。
群内对“一天赚一万 U”的出海神话表示羡慕，但也认可“游戏爆款太难了，一般靠量轰炸”。

结论与痛点：独立开发者在产品定位、推广渠道和用户付费转化上面临巨大挑战。众筹、社区支持、AI 辅助开发成为新的探索方向。

🔑 关键概念与技术解析

vibe 编程：指通过自然语言描述需求，让 AI 自动生成代码/应用的开发方式。群内多次提及“vibe 一个”（如“是时候 vibe 一个了”、“我那个 app 是 vibe 的”），指快速用 AI 搭建原型。
telega-autoplay-custom-emojis / telega-autoplay-mode：Emacs 中 telega 客户端的配置项，用于控制自定义 emoji 和 GIF 的自动播放，提升消息预览体验。
tgs2png：一个工具，可将 Telegram 的动画贴纸（TGS 格式）转换为 PNG 序列，便于在 Emacs 中显示动态内容。
Nix 和 Bazel：提及用于解决跨平台依赖环境不一致的问题（如 glibc 版本差异）。Nix 是包管理器，Bazel 是构建工具，都能提供可复现的构建环境。
Agent 浏览器（如 Tabbit）：专为 AI Agent 设计的浏览器，允许 AI 在网页上执行任务、采集数据，是自动化测试和 AI 应用的新方向。
Neomacs：一个旨在提升 Emacs 性能、现代化其架构的项目，可能是用 Rust 等现代语言重写 Emacs 核心。
AmpCode 自定义 baseurl：AmpCode 支持用户自定义模型路由（baseurl），允许接入不同 LLM 服务，提高了工具的灵活性。
CommandCode：一个 AI 编程工具，网站流量高，表明该领域市场热度大。

💎 碎片知识与金句拾遗

“用 AI 做游戏比玩游戏还爽”（群友感言）
“部署环境不一致，当时用 monorepo 的时候，发现 vps 除了 ubuntu 版本足够，红帽系连 glibc 版本都是旧的...”（关于环境一致性的吐槽）
“是时候 vibe 一个了?”（快速用 AI 搭建项目）
“这都 vibe 出来了”（对 AI 生成能力的惊叹）
“不尝试上 elpa 就不受压力（”（Emacs 插件开发者的心态）
“lucius 给苹果蕉保护费了吗”（吐槽苹果开发者年费）
“过路费的钱赚回来了吗”（指苹果的 99 美元年费）
“大部分做游戏的都是消费行为，就像炒股票是金融消费”（对游戏行业的观察）
“所有金币都是你爆的，她有啥资格跟你吵架🤔”（群友调侃“kk 被对象砸了 Switch2”的八卦）
“kk 女友：我最好的青春都给你了，你有啥资格和我吵架”（群友接梗）
“打人不打脸，打脸就过分额”（夫妻吵架哲学）
“emacs 人基本都是穷13抠13🫠”（对 Emacs 用户群体画像的戏谑）
“sol xhigh毫无性价比，听名字就知道，傻叉嗨”（对某 AI 模型的评价）
“降智又慢，哪来的性价比”（吐槽某 AI 模型）
“最近 gpt 重置比较多，需要解决一下积累的一些需求”（AI 使用经验）
“gpt 的使用我觉得非常浪费时间”（AI 工具痛点）
“关键是给你加很多没必要的安全要求，很浪费时间；- ）”（AI 工具的过度安全限制）
“做出来浏览器就很完美了，这样基本不需要出 emacs 了🤓”（Emacs 用户的终极幻想）
“neo就是rms 2nd”（对 Neo 项目的赞誉，类比 Richard Stallman）
“说来说去 emacs的问题还是性能”（Emacs 核心痛点）
“🦀化肯定第二春”（用 Rust 重写 Emacs 的可能性）
“AI 时代了，不萎缩就谢天谢地了”（对 Emacs 社区的悲观预期）
“你的图标怎么不是正方形的”（用户对 1mcells 的 UI 反馈）
“拖动是按住鼠标中键。”（1mcells 的交互设计，用户觉得反直觉）
“我发现要调整音量，输入数字也可以是一种交互”（交互设计洞察）
“对于那种列表的选择，我也喜欢数字。直接按1234，就直接选中列表当中的第几个。”（交互设计偏好）
“我草，苹果又有完美越狱了，都多少年没出来这玩意了啊”（对 iOS 越狱的感叹）
“我的网易云音乐客户端也越来越好了，现在写代码听歌两不误。”（Emacs 也能听歌）
“第一次把整个 Makefile 的逻辑疏通完，感觉人要死了。”（代码调试的痛苦）
“感觉梳理这个编译产物好麻烦啊，就算是 build.zig 都没让我感觉多轻松。...是我使用方式的问题吗？”（构建工具吐槽）
“比起CMake，有好用的补全了，这很文明”（对 build.zig 的正面评价）
“是不是可以在 makefile 上开发一个更好理解的语法形式，交给 AI 应该不难”（对构建工具的未来设想）
“构建一直是个难题”（开发者的共识）
“复杂度不会消失”（对构建复杂性的哲学思考）
“我讨厌 cmake 的一点是，用了一门非常晦涩的 dsl”（对 CMake 的吐槽）
“明明 cmake 能处理那么多的工具链，背后做的事情也多”（对 CMake 功能的认可）

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

Agent 浏览器（如 Tabbit）：作为 AI 与网页交互的新接口，在自动化测试、数据采集和 AI 应用开发中潜力巨大，值得关注其技术实现和生态发展。
Neomacs 众筹项目 (1mcells.com)：通过“百万格子”众筹为开源项目筹集资金是一种新颖模式，其效果和后续发展值得跟踪。
telega 在 Emacs 中的深度配置：telega 作为 Emacs 的 Telegram 客户端，其优化配置（如自动播放、内存管理）体现了 Emacs 生态的深度定制能力，其实现方案可借鉴。
AmpCode 自定义模型路由：支持自定义 baseurl 意味着用户可以自由切换和组合多种 LLM 服务，这种灵活性可能成为 AI 编程工具的重要趋势。
构建工具的未来：讨论中提及用通用编程语言替代 CMake/Makefile 的 DSL 来构建项目，以及让 AI 协助理解/生成构建脚本，是解决构建复杂性的潜在方向。

以上为本次讨论的知识库总结。若群聊中出现的网址或项目名有错误或失效，请以实际为准。

观点延伸

中心判断：AI 把“写”的成本压到接近零，成本就整体转移到“验证”上。今天群里两件看起来无关的事，一个是有人想花十万块买 CPU 跑测试，另一个是有人花一整天慢慢梳理 400 行 Makefile，它们是同一个瓶颈的两种表现。

一、买硬件是在错误的维度上靠算力求解

先看数字：Neomacs 的全量 oracle 测试现在要跑半小时，作者预期会涨到三小时。用 128 核去压，最好情况也只是线性收益；而兼容性问题的复杂度会随平台数量呈指数增长，因为平台、版本、场景三者是相乘的关系。群里已经有人把话说准了：靠一台电脑覆盖这么多平台不合理，开源项目应该让更多人参与测试。

真正的解法是测试分层，而不是买更多算力：分钟级的快速回归留在本地，小时级的全量兼容矩阵交给 CI 和社区，而且必须能定位失败落在哪个平台维度上。作者自己说“已经在耗 GitHub 的 CI”，方向是对的，缺的是分层，不是核数。

二、1mcells 卖的是参与感，而格子本身只是形式

花一美元买一个格子的动机，和买一块更快 CPU 的动机完全不同：前者求的是“我在场”。所以这个项目真正的产品是 leaderboard 和那张能被转发的分享卡片；作者当晚自己也意识到“share card 不够吸引人”。

算术上很直接：一美元一格凑十万，需要十万人。而 Emacs 付费用户池的实测数据就摆在同一天：一个正经上架的 App，两周试用、0.99 美元每月，订阅者两个人。所以这笔众筹不该以“买 9995WX”为目标，而该以“把 Neomacs 的测试基础设施做成公开可赞助的公共品”为目标。前者是买设备，后者才是能进大渠道的故事。

三、Makefile 的痛苦在于状态不可见，而非语法

“复杂度不会消失”这句判断是对的，但方向要修正。CMake 的痛点是晦涩的 DSL，那是可读性问题，AI 已经能替你读；400 行 Makefile 真正的难点，是它记录了大量机器状态和历史遗留的特殊情况：某个发行版的 glibc 太旧、资产打包的顺序不能换、某个工具只能用系统自带的。这些信息不在那 400 行里，AI 读不出来，所以“看懂逻辑但一点不会改”是必然结果。

也因此我不太相信“用通用编程语言当构建语言”能解决问题：Nix 和 Bazel 早就是编程语言，当天凌晨那条关于 monorepo 与旧 glibc 的吐槽已经证明，用编程语言当构建语言并不会让构建变轻松。真正的收益在于把隐式依赖显式化：把它们写成断言、写成会失败的健康检查，而不是换一门更好看的语法。

可继续研究/实践： 挑一个自己在维护的项目，把构建与测试拆成分钟级、小时级两层，把所有“必须成立却没写下来”的环境前提逐条变成脚本里的断言。做完再评估 AI 能替你改到哪一步，你会得到一个关于验证成本的实测数字，这比任何关于 AI 编程效率的争论都可靠。