Geekinney

外观

Emacs 社区日报 2026-10-24

约 5485 字大约 18 分钟

2026-10-24

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

Emacs 中文讨论组

🎯 核心热点与专题探讨

【专题一】GNU ELPA 对 LLM 代码的政策之争

群内围绕 GNU ELPA 是否接受 LLM 生成代码展开了激烈辩论。核心矛盾在于：

  • RMS 的立场：以版权问题为由拒绝 LLM 代码进入 NonGNU ELPA，但这一政策并未获得社区共识。
  • 维护者的担忧：LLM 生成的代码作者缺乏持续维护能力，代码质量会逐渐劣化，且大规模 AI 代码特征明显（几百行以上容易识别）。
  • 执行层面的矛盾：已有 LLM 代码进入 NonGNU ELPA，审查机制依赖 commit 信息是否署名 AI，但实际操作中存在"审查过为何还要署名"的执行漏洞。
  • 理想主义谬误的讨论：有群友指出"政策执行中的问题不能成为否定政策本身的理由"，应当将政策选择与执行问题分开讨论。

【专题二】Git 提交粒度与 commit message 规范之争

围绕 RMS 的小提交和 commit message 冗长问题，群友展开了关于版本控制最佳实践的深度辩论：

  • 支持小提交派：颗粒度小的提交便于二分调试、回归测试，且是 AI 时代推荐的方式——"提交一次跑一次 regression test"。
  • 反对派观点（以 AOSP 维护者为代表）：多 repo 项目中小提交会导致灾难，一个功能改动涉及 3 个 repo、几十个项目几百个提交，没有关联线索就不知道改动归属。
  • 折中方案：在自己分支上保持小提交，merge 前 squash 成有意义的原子提交——"逻辑上原子变更就应该在一起"。
  • 特别指出：RISC-V 初始提交的拆分策略是"按主题拆分"，核心架构代码与驱动剥离，确保可 bisect 且便于评审。

🔑 关键概念与技术解析

  • neomacs WASM：将 Emacs 风格的编辑器编译为 WebAssembly 运行在浏览器中。群友尝试将多个 neomacs 实例嵌入网页格子（1mcells.com），每个格子可独立运行一个 WASM 程序。
  • Org mode @@comment: text@@：Org 的导出注释语法，可以不需空格直接内联使用，但群友认为"输入还要那么多"且渲染效果不佳。
  • NonGNU ELPA：GNU ELPA 的非官方扩展包仓库，由 Philip Kaludercic 实际维护，相比 GNU ELPA 政策更为开明。
  • jj（Jujutsu）：新一代版本控制工具，被多次推荐为 Git 的替代方案——"jj 解君愁"。支持 blame、更自然的 commit 组织，但部分功能与 Git 仍有差距。
  • AOSP 多 repo 工作流：Android 开源项目使用 repo 工具管理多个 git 仓库，一次功能修改通常涉及 3 个左右仓库（代码、sepolicy、device 配置），对提交管理要求极高。
  • EWDK：Windows 驱动开发环境，以 ISO 形式提供绝对的环境一致性，群友评价"nix 都比不了"。

💎 碎片知识与金句拾遗

  • "他的 commit message 会被用来生成 ChangeLog，所以有格式要求（当然用了 git 之后 ChangeLog 也确实没啥用了）" —— 关于 Emacs 提交规范的历史背景。
  • "小提交遇到 bug 才好回退吧（" —— 反驳"小提交导致回退困难"的观点。
  • "linus 数十年前就不写代码了吧，他自称每天最多是在看邮件" —— 关于 Linus 工作方式的观察，随后有人指出 RMS 最近仍有提交（5月14日，emacs-mirror）。
  • "微软的提交都是 msg 比 code 长" —— 指出大公司 commit message 冗余现象普遍。
  • "阁下的发言非常 AI，怀疑是不是 LLM 代写的" —— 群内开始互相识别 AI 发言的有趣现象。
  • "建议用 jj，jj 解君愁" —— 多次出现的工具推荐。
  • "C 的社区是以项目划分的，而不是语言本身" —— 对 C 语言社区结构的重要观察，且"c 的编程规范都没有社区共识"。
  • "安装的目录结构（include/bin/lib）是 POSIX 标准吧（" —— 对目录规范归属的考证。
  • "Windows 对于库分发来说很痛苦，很多时候得是自己拉源码下来了" —— Windows C 开发者的共同痛点。
  • "C 的库很多都稳定到接近死亡了，你不如直接 vendor" —— 对 C 库稳定性的判断与 vendor 建议。
  • "git 的粒度只有 commit 不好用，如果能提供高阶的层次就好了" —— 对 git 模型局限性的反思，日常用 branch 凑合。
  • "git 最重要的功能就是 blame 吧，不然怎么扯皮" —— 对 git blame 的另类重要性解读。
  • "单人项目用啥 git" —— 小型项目使用 Git 的必要性质疑。
  • "以前是为了适合人读，现在都给 AI 整理了" —— 提交历史的主要消费者正在从人变为 AI。
  • 对 Sydney AI bot 的模型身份测试：在不同配置下分别声称 Kimi K3.1 Pro、Claude Fable 5.1、Gemini 4 Argon，引发了群友对 AI 身份一致性的调侃。
  • "我用 telega 在群内折叠 AI 发言，Matrix 端看不到" —— 跨平台群聊（Telegram + Matrix）桥接带来的内容可见性差异。

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

  • neomacs WASM 内联方案：将 neomacs 编译为 WASM 嵌入网页的应用场景值得探索，尤其是 1mcells.com 这类网格化页面的交互设计。
  • jj（Jujutsu）作为 Git 替代品：群内多次力荐，值得深入研究其 commit 组织模型、blame 实现与 Git 的差异，以及大型项目的适配性。
  • telega + gptel 插件集成：有人提出"给 telega 写个插件让它取聊天上下文插入 gptel"，这个思路可以将群聊上下文直接接入 Emacs AI 工作流，但目前仅停留在脑洞阶段。
  • 本地虚拟 monorepo 方案：群友提到"可以本地拼一个虚拟 monorepo 来开发"以应对 AOSP 多 repo 管理的痛点，这个思路值得实践验证，但目前只是个人方案，未有开源实现。

观点延伸

今天两场最热的争论——LLM 代码能不能进 ELPA、提交该不该拆小——看起来无关，实质在争同一件事：“可维护”的责任该落在谁身上。前者想落在作者身上，后者想落在 commit 上。区别在于，后者可观测，前者不可观测；而一条挂在不可观测量上的规范，最后一定会退化成形式检查。

一、“作者能不能维护”是个测不出来的门槛，所以只能查署名。

政策对外说的是版权，维护者反复念的是可维护性。版权至少还是个能吵的法律问题；可维护性一旦拿来当准入门槛，麻烦就来了——它不可观测。群里那句“你审查过的话为什么还要 AI 署名”已经把漏洞说尽了：如果 review 真能判断代码质量和后续维护能力，署名与否就不该影响准入；如果署名是准入依据，那 review 就只是走过场。这不是执行不力，是判据选错了。

同一件事还有个反证：那天一个 AI bot 被连问三次，报出三个不同的底层模型；与此同时，有人因为发言太顺被怀疑是 LLM 代写。人对“这是不是 AI 写的”的判断，准确率大概不如掷硬币。既然如此，把准入建立在披露与识别上，注定只能筛掉老实人。可执行的替代是把门槛从作者移到产物：测试、文档、issue 的响应时延、后续修复 commit 的密度。谁写的不重要，接不接得住问题才是可验证的。

二、提交粒度之争是“检索键”之争，不是大小之争。

AOSP 那边的痛点不是提交小，而是同一个功能散在三个 repo 里、没有共同的检索键；Emacs 和 Linux 能坚持小提交，是因为单 repo 加上邮件列表 thread 天然提供了这个键。“逻辑原子变更就该在一起”这条原则没错，但它需要载体：一个功能一个 issue、一个 topic 分支、一个 Change-Id。缺了载体，squash 只是把线索藏得更深，并不产生线索。群里提到的本地虚拟 monorepo、jj 的 change 抽象，补的都是这个键。

三、“历史现在给 AI 读了”值得认真对待，但不能当免罪符。

如果 commit message 的主要读者从人变成 agent，格式要求确实会松，但可检索性的要求会更高——agent 更依赖结构化线索，不会像人那样靠上下文猜。所以“msg 比 code 长”从来不是问题，问题是 msg 里有没有写清“为什么改”和“影响面在哪”。那位抱怨回退时不知道回哪个 commit 的群友，缺的其实是这个，不是更少的提交。

可继续做的一件事：挑一个真实的跨仓库改动，用 issue 号当唯一检索键，把散落的提交串成一条链，然后测两个指标——从报 bug 到定位到具体 commit 的耗时，以及这条链在半年后还能不能被独立还原。如果 issue 号真能替代目录结构和人的记忆，那“提交该多大”这个问题就不用再吵了。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：1mcells 产品迭代与社区反馈

1mcells 是群友 geekinney 正在开发的一个“百万格子”产品，用户可以在一个巨大的画布上购买像素格子并放置图片/链接。今天的讨论围绕该产品的功能迭代、用户体验与商业推广展开。

  • 移动 Cell 功能上线：geekinney 在凌晨实现了“移动 cell”功能并部署上线。用户可以在右侧 asset detail 中点击 MOVE 按钮来移动自己的格子。有群友感叹“一百万个格子，就只有咱俩人在这儿玩”，geekinney 回应称项目确实有些复杂，可能需要简化结构。
  • 购买流程设计建议：一位群友提出了一个详细的产品设计建议——将购买界面直接放在画布上完成。电脑端右侧弹出 sheet（类似对话泡风格，指针指向画布上的像素），手机端使用 BottomSheet 并将背景定位到目标 pixel，以便用户实时预览上传图片后的效果。geekinney 对此表示认可，但也指出“右边这一小块放不放得下上传和付款内容要看具体效果”，需要在直观性与现有模态框设计之间权衡。
  • Cell 内容空白问题：有群友购买了 cell 但没有上传图片或链接，导致 Trending 页面看起来空荡荡的，甚至怀疑是否有 bug。geekinney 提醒用户上传图片和链接，并建议后续改进默认状态。
  • Product Hunt 推广：geekinney 投递了 Product Hunt 并已发布，请求群友帮忙 Upvote（自己不能给自己投票）。

专题二：代码复用与抽象层级讨论

围绕代码复用和抽象设计展开，核心讨论点是“过度抽象会降低代码可读性”。

  • appkit.el 的迁移困境：一位群友提到“代码复用还是有点难”，感觉 appkit.el 问题依然很多——本意是让各个应用不写重复代码，结果迁移一波后“没什么行数优化”。
  • 约定优于抽象：另一位群友提出“没必要过度的抽象，更高维的代码会让代码的可阅读性降低”，主张采用“约定优先的原则”，应用只按照框架的约定进行配置就完成开发。并以 vuepress 之于 vue.js、vueplume 之于 vuepress 为例，说明抽象应该根据 app 的类型和需求一层层构建。

专题三：输入法方案探索

群内连续讨论了多种输入法方案，从商业输入法、开源方案到硬件输入法，再到 AI 增强输入法。

  • 需求定义：有人提出“能用 AI 做出一个理想的汉字输入法吗”，但立即被反问“先定义理想”，因为“每个人的需求都是不一样的”。
  • 具体诉求：一位群友想要“适合 dvorak 的，布局整齐，取码简单的，顶功类的输入法”，并表示现在用的是仓颉。
  • 硬件输入法：有人提出“要不要整硬件输入法”，即键盘上自带输入法、直接把汉字发到电脑里。可行性讨论涉及 Linux/Windows/macOS/安卓支持，但 iOS 不行。
  • AI 增强输入法：有人提到“AI 时代，输入法肯定要 AI 加强”，但担心“每一句话都走一遍 remote LLM，太恐怖了”。
  • 商业方案对比：群友认为“如果考虑商业输入法，全拼的话其实感觉搜狗做的还不错的”。另有群友推荐仓颉，称其“相对五笔更符合中国文化”。也有人提到“qingjian”这个纯 Rust 输入法，认为 AI 时代“vibe 自己的需求比较方便”。

专题四：iPad 上的 Linux 桌面环境 —— LinPad OS

一位群友分享了 LinPad OS 项目，引起了不少兴趣。

  • 项目介绍：LinPad OS 是给 iPad 装上一套 Linux 桌面环境的开源项目，支持完整电脑桌面、多窗口、VS Code、Python、Node.js、Git，甚至能在终端里跑 Claude Code。所有东西都在 iPad 本地运行，无需远程连接 Mac 或 VPS。
  • 应用场景：分享者描述了“早上带着 iPad 去咖啡馆，接上键盘，打开 Claude Code，让 AI 帮忙改改网站、写写代码”的场景，认为一台设备就能覆盖出门所需的全部工作。
  • 群友反应：有人提问“这岂不是意味着可以在 iPad 里运行 emacs？”，也有人感叹“卧槽这么炫酷”。

🔑 关键概念与技术解析

  • appkit.el：一个 Emacs 应用框架，旨在让各个应用复用代码、避免重复开发。但群友反馈迁移后“没什么行数优化”，说明其抽象成本较高，实际收益有限。
  • 顶功类输入法：一种键盘布局设计理念，强调“布局整齐、取码简单”，适合 Dvorak 等物理键盘布局。群友寻找此类输入法，说明对键盘效率有较高要求。
  • LinPad OS：为 iPad 提供完整 Linux 桌面环境的开源项目，支持本地运行 VS Code、Python、Node.js、Git 及 Claude Code 等。核心价值在于“无需远程连接 Mac 或 VPS”，实现移动开发。
  • Product Hunt (PH)：产品发布与推广平台，开发者可以提交产品并获取用户 Upvote（投票），用于提升产品曝光度。geekinney 将其 1mcells 投递到 PH，寻求社区支持。

💎 碎片知识与金句拾遗

  • 1mcells 购买建议：有人买了（114，514）格子，群友调侃“下次记得 1919 810”——这是二次元网络流行梗（“好臭的数字”）。
  • 学校停电与 /tmp 丢失：一位群友吐槽“学校司马了，又停电，仓库损坏了，/tmp 内容也丢了”，另一位建议“你需要一个 UPS”。另有群友补充“好多学校的线路老化很严重，一般不给用大功率的电器”。
  • AI 生成字体成本：有人分享“现在用 AI 制作字体不少，不过这个居然需要 3 个 20x 的 gpt 额度，缩水太严重了”——说明 AI 生成字体成本依然较高。
  • Codex GUI 代理配置：有群友询问“codex gui 如何走代理”，讨论后结论为“直接改配置就好了”，但 ChatGPT 应用端难以配置。有人提到“—proxy-server 可以”，并分享了相关 issue。
  • 127.0.0.2 的妙用：一位群友提到“之前好像还真有什么需求要用到 127.0.0.2 这种”——在软路由场景中，ArchLinux 通过网线连接 MacBook Pro 上网时，曾通过 127.0.0.2、127.0.0.3 解决。
  • Opus 的“幻觉”：一位群友分享“我在 opus 工作的时候给文件删了一些空行，结果他停下来问说是不是有其他 agent 在同时工作”——Opus 误以为有其他 Agent 在协作，说明 AI 对自身行为认知存在边界。
  • 录视频的自我纠结：一位群友表示“录视频好难呀”，因为“我不是用 AI 配音，而是自己去讲，经常感觉有点啰嗦”，另一位建议“让 opus+hyperframe 帮你录，你只需要审核脚本”。群友最终决定“不管了，最后一遍，不管讲的啥样，就这样了”，另一位鼓励“跨过去之后，就不是什么难事了”。
  • Claude Desktop 的封号风险：有群友提到“容易增加被封的概率”，认为 Anthropic 通过遥测和设备指纹来封账户。但也有人反驳“我用 desktop 好久了，我感觉 cli 可以拿到一样的权限”，表示“还是不想用 Desktop，虽然这一切极可能源自我的幻觉”。
  • Elisp 高亮：群友发现 Claude Desktop 有 elisp 高亮，另一人惊讶“你居然敢用 claude-desktop”，后来发现 Codex Desktop 也有。
  • Trending 页面不空荡了：1mcells 的 Trending 页面终于有内容了，群友分享了一个“猛人”的个人主页：https://tianyin.github.io/。

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

  • 1mcells 购买流程新设计：群友提出的“画布上直接预览上传图片 + 右侧 sheet/底部 sheet”设计，若实现将大幅提升购买体验。值得关注 geekinney 是否会采纳，以及实现效果如何。
  • LinPad OS：https://linpados.com —— 为 iPad 提供本地 Linux 桌面环境的开源项目。其“本地运行 Claude Code”能力若成熟，可能成为移动开发新范式，值得跟进其技术实现与生态发展。
  • 硬件输入法方案：群友对“键盘自带输入法、直接把汉字发到电脑里”产生了浓厚兴趣，但硬件选型（能接 Linux/Windows/macOS/安卓）仍在探索中，暂无具体方案落地。
  • AI 生成字体成本：当前 AI 生成字体仍需要 3 个 20x 的 GPT 额度，说明成本高企，未来若出现低成本的生成方案将值得关注。

观点延伸

今天最关键的线索并不是两个新项目，而是同一句话在两个地方被独立说出来：复杂度并没有消失。在产品这一侧，有人说“把项目搞简单一点，把不必要的结构去掉”；在代码这一侧，有人说“迁移一波没什么行数优化”。这两件事是同一个错误的两次发作——以为抽象和简化是删除，其实只是把复杂度搬到了别处。

抽象是为了让下次更便宜，而不是让这次更短

appkit.el 的目标是“各应用不写重复代码”，结果行数没降。这个结果本身就很有诊断价值：它说明重复代码很可能不是这个项目的主要成本，理解和定位才是。行数是最差的复用指标，因为它奖励把逻辑往框架里塞。

“约定优于抽象”这条主张成立，但有个不常被说出的前提：场景足够同质。vuepress 之于 vue 能成立，是因为博客的形态高度收敛；appkit 面对的应用形态是发散的，此时“约定”会退化成“必须记住的规矩”，成本从代码转移到人的脑子，而脑子不可 grep。

一个可操作的判据：如果新增一个应用必须先读懂框架内部，这个抽象就是负资产，不管它省了多少行。

同一个问题也出现在产品复杂度上

1mcells 那条购买流程建议，正确的读法不是“加一个 sheet”，而是把复杂度从用户的脑内模拟搬到渲染层——现在用户得在模态框里想象“这张图放到那个格子上是什么样”。模态框本身不差，差的是预览太远。

所以取舍标准可以写得很硬：一个设计让预览更近、让配置更远，就值得做；反过来就再想想。这也解释了为什么“去掉不必要的结构”这类建议往往落不了地——结构可以删，被它承接的那部分需求不会跟着消失。

AI 输入法：先定义理想，再谈分层

“先定义理想”是今天最硬的一句反问。后面所有技术讨论其实都受它约束。有人说每句话都走一遍远端模型“太恐怖”，这个恐惧的重点不是钱，是把输入法的可用性绑在网络和账号上——输入法延迟敏感，且必须永远在线。

硬件这条路也要冷静看：键盘自带输入法在桌面和安卓或许可行，iOS 直接封死。这说明输入法在很多平台上属于系统特权，不是应用。想走这条路，第一步不是选硬件，是确认目标平台允不允许注入。

可继续研究 / 实践

给 appkit.el 定三个数：新增一个应用的代码行数、必须读的框架文件数、首次出错到定位的平均耗时，迁移前后各测一次。三项都没改善，就大方接受“重复是更便宜的抽象”。

输入法侧做个一天能做完的实验：拿自己 200 句真实输入，比较本地小模型重排与云端整句改写的接受率和延迟，再决定 AI 该放在哪一层。这比争论“要不要 AI 增强”有用得多。