Geekinney

外观

Emacs 社区日报 2026-09-02

约 5193 字大约 17 分钟

2026-09-02

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

Emacs 社区日报 2026-09-02 手绘图
Emacs 社区日报 2026-09-02 手绘图

Emacs 中文讨论组

🎯 核心热点与专题探讨

【专题：Emacs 多光标编辑的实践与争论】

群里展开了约一小时的长篇讨论，围绕多光标、宏、矩形编辑的优劣展开了激烈交锋。

背景： Neovim 宣布原生支持多光标编辑（multi-cursor），引发了 Emacs 用户群的讨论。有人认为 Emacs 的宏足够强大，不需要多光标；有人则认为多光标更直觉、更好用。

各方观点：

  • 宏派：认为宏适合复杂场景，录制时一次想好就能套用。缺点是“不够直观，容易写错，中途出错就要重来”。
  • 多光标派：认为“多光标和吃饭喝水一样自然”，尤其适合对同类文本做批量处理。强调“可以边做边调整”，比宏的“录制前完全想好”更灵活。
  • 矩形编辑派：有人表示主要靠 C-x SPC 矩形编辑 + replace-regexp 就能覆盖大多数场景。

痛点与吐槽：

  • 有人吐槽 Emacs 的矩形编辑“一次编辑完就要重新选区”，体验不够流畅。
  • 有人提到在矩形编辑模式下 backspace 和 C-y 失效，需要先选中才能操作，认为这很“神秘”。
  • 有人提到 Emacs 矩形模式下的零宽选区提示（rectangle-indicate-zero-width-rectangle）在 TUI 下不可见，因为 TUI 不支持 :height 属性。

结论： 群内没有达成一致，但普遍认为多光标“不需要特别学”，且对数据处理场景（如 SQL 对齐）很高效。有人总结：“更复杂的匹配替换直接丢给 AI 了”。

【专题：Valve 对 Linux 生态的贡献】

群内对 Valve 的开源投入给予了高度评价，提到几个关键项目：

  • Wine/Proton：让 Windows 游戏在 Linux 上运行的核心兼容层。
  • FEX-Emu：一个 x86 模拟器，用于 ARM 设备上运行 x86 游戏。
  • Linux 图形驱动：Valve 深度参与开源图形驱动栈的开发。
  • HDMI 2.1 驱动开源：群友指出 HDMI 标准组织“不干人事儿”，Linux 只能用残废的 HDMI，Valve 解决了这个难题。
  • 与 Arch 社区的合作：Valve 直接与 Arch 官方展开合作，但群友指出“Omarchy 目前还没有和 Arch 官方合作的迹象”。

【专题：Omarchy 与 vibe coding 的风险讨论】

群里持续讨论了 Omarchy 项目（一个基于 AI 编程的项目）以及 vibe coding 的隐患：

  • 有人评价“Omarchy 总归是个好事”，只要后续能掌控住项目不腐化。
  • 但对 vibe coding 持悲观态度：“必然失控的，被营销吸引过去的用户大部分是识别不出来有什么坑的，感觉黑客们有的赚了”。
  • 关于“AI 写的漏洞多”，有人指出核心不是“AI 写的漏洞多”，而是“vibe 的东西没人负责”。在公司里“你 vibe 自己不管，出了事故你还是要背锅”。
  • 有人感叹“写的快，review 的 AI 也快，漏洞检测的 AI 也快，太快了”。

🔑 关键概念与技术解析

  • FEX-Emu：Valve 参与开发的 x86 模拟器，用于在 ARM 平台上运行 x86 游戏，是 Linux 游戏生态的重要组件。
  • vibe coding：指完全依赖 AI 生成代码的编程方式，不手动审查或修正。群内讨论其安全性隐患，核心问题是“没人负责”。
  • telega + tgs2png：telega 是 Emacs 的 Telegram 客户端。它无法直接渲染 Telegram 的动画表情（TGS），需要外部工具 tgs2png 转换为 PNG 后才能显示。
  • rectangle-indicate-zero-width-rectangle：Emacs 31 新增选项（默认 t），当矩形选区宽度为零时用 region face 高亮显示。仅在 GUI 下有效，TUI 不支持 :height 属性。
  • epub-reader：Emacs 新发布的 EPUB 阅读器，支持目录、高亮、鼠标操作、KP 算法对齐、自定义版面选项（行距、段间距、页面两侧留白）以及阅读进度显示。

💎 碎片知识与金句拾遗

  • “让 Linux 生态好起来的是 Valve。” —— 群友评价 Valve 对 Linux 图形栈、Wine/Proton、FEX-Emu 的贡献。
  • “做一个成熟的桌面是需要大量脏的工作的，这一部分人类很少去做。” —— 吐槽桌面开发的工作量大且乏味。
  • “营销能力顶级了可以说😁” —— 评价 Omarchy 的营销手段。
  • “讲个笑话，dhh 有审美。也可以说每个人都有审美。” —— 对某项目设计审美的讽刺。
  • “多光标在大部分场合下都更方便。” —— 多光标派的辩护。
  • “我是不理解 nvim 为什么现在要加多光标的。” —— 质疑 Neovim 新增多光标的意义。
  • “宏我感觉适合更加复杂的场景，多光标很直觉。” —— 两种工具适用场景的总结。
  • “多光标很简单，不需要特别学，和吃饭喝水一样。” —— 群友对多光标易用性的评价。
  • “我是 evil 用户，喜欢用 C-v, j,j, I, space, space。我把这种行为称为：行云流水。” —— evil-mode 用户描述自己的多光标操作习惯。
  • “把视频播放这个独立抽出来吧，太叼了。” —— 群友对 Emacs 视频播放器项目的评价。
  • “chirp 是好用啊。” —— 简短肯定某个工具。
  • “刚发现有 twitter dm 到 matrix 的桥。” —— 发现一个有趣的中继工具。

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

  • Emacs 视频播放器（video.el）：群友正在开发，支持嵌入式/全屏两种模式，基于 canvas，支持暂停、静音、进度条、缩放、拖动，并计划集成到 appkit。后续打算支持“流媒体”，且“现在能共享 session，切换时可以连续播放”。这是一个极具潜力的 Emacs 多媒体扩展。
  • Neovim 原生多光标：Neovim 刚合并了原生多光标支持，群内讨论热烈。值得对比 Emacs 的 multiple-cursor.el 和 rectangles，看看未来 Emacs 是否也会加入原生支持。
  • Valve 的 HDMI 2.1 开源驱动：解决了 Linux 上 HDMI 功能残废的问题，对 Linux 桌面和游戏生态意义重大，值得深入了解其实现。
  • chirp 的集成：群友提到“在做 chirp 的集成”，后续可能有更大的框架出现。

观点延伸

今天最值得咀嚼的不是“Emacs 到底需不需要多光标”，也不是“AI 写代码是不是漏洞更多”，而是同一个工程判断：工具真正改变质量的地方，不在它能不能完成任务，而在它是否让人持续看得见、停得住、负得起责。

1. 多光标赢的不是能力，是可中断的直觉

宏、replace-regexp、矩形编辑都很强，复杂匹配甚至比多光标更适合。但群里反复出现的关键词是“直觉”“边做边调整”“不用特别学”。这说明多光标的价值不是表达能力，而是交互闭环短：选中、扩展、删改、撤销，每一步都在眼前发生。

宏的问题恰好相反：它要求操作者在录制前先把路径想完整，中途错一步就有重来成本。矩形编辑的问题也类似，能力存在，但状态提示、按键复用、零宽选区在 TUI 下不可见这些细节，会直接打断心智模型。工程上这不是小体验问题，而是“错误可见性”和“恢复成本”的问题。

2. “更复杂丢给 AI”不是终点，而是分层信号

讨论里有人说，复杂匹配替换直接给 AI。这个判断很现实，但也危险：多光标适合局部可视修改，正则适合可声明批处理，宏适合重复动作，AI 适合需求模糊或转换规则难形式化的场景。问题不在用不用 AI，而在有没有清楚知道自己跨到了哪一层自动化。

一旦从多光标跨到 AI，反馈粒度就变粗了：你不再逐字符观察，而是在审查一段结果。这里就和 Omarchy/vibe coding 的争论接上了。群里那句“不是 AI 写的漏洞多，是 vibe 的东西没人负责”很准。速度本身不会带来质量，速度只会把责任瓶颈暴露得更快：写得快，review 也快，检测也快，但如果没有明确 owner、边界和验收标准，整个系统只是更快地产生不可追责的变更。

3. 可验证的工程标准：看自动化是否保留责任链

判断一个编辑器功能、AI Agent 流程、vibe 项目是否靠谱，可以先问三件事：操作过程是否可观察；错误是否可局部撤回；结果是否有独立验收。多光标在小范围文本处理上天然满足这三点，所以它“像吃饭喝水”。纯 vibe coding 如果缺少 review、测试、安全边界和维护 owner，就同时破坏这三点。

可继续实践的方向：把 Emacs 里的文本变换按“手工可视、多光标、正则/宏、AI Agent”分成四层，分别记录典型任务、失败模式和验收方法。真正值得做的不是争哪种工具高级，而是建立一套从可视编辑平滑升级到 AI 自动化、同时不丢责任链的工作流。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：Emacs 生态与开发者“出圈”之路

讨论从凌晨持续到深夜，核心围绕几位群友的 Emacs 插件开发与推广展开。一位群友的 minibuffer-frame 插件被 Emacs News（sachachua.com 的周报）收录，引发了他“必须用最快速度写博客营销”的兴奋。随后话题扩展到为 Emacs 提交 patch、阅读 Emacs 源码的痛苦以及 neomacs（一个视频组件正在重构中的 Emacs 变体）的宣传策略。

  • 关键观点：Reddit 和长毛象（Mastodon）是反 AI 的极端保守派大本营，不适合推广新锐 Emacs 项目；相比之下 X 的算法推荐更有助于破圈。
  • 核心痛点：Emacs 核心成员中几乎没有中国人（群友提到“老风扇”可能是唯一例外）；连续 2 个 Reddit 账号被 ban，阻碍了社区宣传。
  • 解决方案：先专注开发，等 neomacs v0.0.17 视频功能完成后，再通过 X 平台推广；同时群友计划通过提交 patch 逐步“混上 Emacs 核心成员”。

专题二：JJ（Jujutsu VCS）的潜力与商业化争议

下午消息推送了 Jujutsu 创始人 Martin von Zweigbergk 加入 ERSC（East River Source Control）创业公司的消息，引发热烈讨论。群友分析了 jj 的独特价值——它能在不放弃 Git 生态的前提下，提供不同的数据模型和工作流。但商业化引发担忧：

  • 核心观点：Git 分三层（磁盘格式、CLI、wire protocol），jj 的特殊之处在于能同时兼容 Git 生态又突破其限制。
  • 争议焦点：Martin 离开 Google 后，jj 开源项目与公司产品开始“走向分化”，存储层方向由公司主导，治理结构存疑。群友感叹“要搞 jj native 的服务端”，但也有人认为“现在的 VCS 都是在 git 屎上雕花，扬了 git 又没人用”。
  • 实际使用反馈：有群友因公司强制 Git hook 监控而改用 jj；也有群友因国内模型“思考链写代码”的怪癖（消耗 worktree 资源）而“被迫切回 jj”。讨论涉及 jj 与 git 的用法差异（如 jj new 与 stage 区的类比），以及 majutsu（Emacs 的 jj 客户端）的性能——在 Windows 上更快，其他平台差别不大。

专题三：AI 模型订阅经济学

围绕 ChatGPT Plus/Pro、Cursor、Grok 的订阅策略展开了长篇讨论，核心是如何在多家模型服务商之间找到性价比最优解。

  • 核心结论：Cursor Pro+ 用户如果用第一方 Grok 模型，大概有 400-600 刀的额度，性价比极高。老账号的 pro 可能有 300 刀额度，但“老马收购后有没有砍掉”存疑。
  • 对比观察：ChatGPT Plus 只是少了 Spark 和 Pro 模型，与 Pro 差别不大；但“如果不一直开 sol xhigh 去干活”，比 GitHub Copilot 耐用得多。
  • 吐槽：Grok 降智太快，建议买 Cursor；OpenAI 算力似乎不够，“一到晚上 gpt 就很慢”。有人提到“GLM 又开始送周限额重置卡了”，群友表示要“多开几个号白嫖 1 亿 token”。

🔑 关键概念与技术解析

  1. minibuffer-frame：群友自研的 Emacs 插件，将 minibuffer 放在独立 frame 中显示，被 Emacs News 收录后引发“这个包太好用了”的感慨。
  2. JJ（Jujutsu）/ jj：一个兼容 Git 的下一代版本控制系统。其核心创新在于将 working-copy 本身视为一个提交（commit），使得每次修改都能被追踪和回溯，彻底改变了传统 Git 的“暂存区”心智模型。
  3. org-timegrid：一个基于 Org 文件的 SVG 周历视图，支持鼠标和键盘操作，可选的 day strip 用于 Org Agenda。群友评价“这个好看”。
  4. majutsu：Emacs 的 jj 客户端（类似于 magit 之于 git），依赖 plz（用于 Gerrit）。其性能优势主要体现在 Windows 上（减少进程创建开销）。
  5. ERSC（East River Source Control）：一家企业级源码控制创业公司，刚刚招募了 jj 的创始维护者 Martin，押注下一代源代码管理基础设施。
  6. Fable 5.1：发布了新版本，群友观察到“反倒更便宜了”。
  7. sing-box：通用代理配置工具，被推荐用于网络代理配置，群友表示“还不错”，计划将 Mac 也迁移过去。
  8. ChatGPT 桌面应用内嵌 430MB LibreOffice：群友评价“桌面端应用就喜欢搞无依赖，然后就是臃肿得可怕”，并预言“以后会是一个应用内嵌一个 python”。

💎 碎片知识与金句拾遗

  • 关于 AI 生成内容：“我非常痛恨 ai 的一点……就算 ai 生成的视频这些，没有灵魂。” 另一位群友反驳：“没有灵魂的是输入 prompt 的那个头脑。和拍照一样，拍得不好是镜头后面的脑子不好。” 随后补充：“和 AI 交互的唯一窗口就是提示词，如果有人能用 AI 作出了不起的事情，那么做不到一定就是人的问题。”
  • 关于国产模型的怪癖：“国内模型喜欢在思考链里面写代码，实际上会把思考链当成自己的笔记，然后疯狂写有的没的。代码在思维链里写一遍，然后又往文件里写一份一毛一样的。”
  • 关于 X 平台图片布局算法：有群友在逆向 X 平台的图片布局，发现有两套算法，“打算都给它复刻了”，后续感叹“只能上 svg 科技了”。
  • 关于生活哲学：“得珍惜你的不良嗜好，那是你热爱生活的主要原因。” 有群友回应：“我不热爱生活，我很痛苦。” 随后有人推荐 shibari、暴食、钓鱼等爱好。
  • 关于 AI 自制剧：抖音上出现不少“几乎看不出 AI 感”的自制剧，群友推荐了《和樱花妹互换身体的日常》《老祖你邪得发正》（万魂幡变成人皇幡了）等。
  • 关于生活压力：“每月 3w3 工资只剩 4k 租房吃饭”；“最高点南京买的房子，欠 230w”；“我现在 10 点就睡了”。
  • 关于家乡记忆：多位群友分享了关于罂粟的记忆——小时候路边就有、卤菜里会放一点提香、老人临终镇痛用等。“00 后完全没听说过”引发了代际差异的讨论。
  • 关于工作地选择：“南京互联网不行，很多外包，国企太多，就是一个躺平状态”；“深圳纯压榨”；“宁波是财阀聚集地，搞特殊”；“杭州蛮喜欢的，很多元”。
  • 关于苹果平台：苹果群发邮件通知 Mac 软件开发者“已经没必要再适配英特尔 CPU”，macOS 27 将完全停止对 Intel Mac 的支持，Rosetta 2 将在 macOS 28 中停用。“苹果真的狗，黑苹果无了”。
  • 关于个人品牌：“今天博客也没有写”；“我要 x 上多发一点推销我个人的内容”。
  • 关于游戏：“我在等 kingdom rush 的新作，9-24 日放出”；“打游戏是好事儿啊，现在很少有连续的长时间用来沉浸在游戏中了”。
  • 一个深刻的观点：“穷人也可以结婚，穷人的生活其实也可以很快乐，吃拼好饭，住拼好房，买红米手机。”
  • 关于自我剖析：“没老婆，没孩子。依然觉得生活很苦”；“生活没什么精神寄托，只靠读读书只能暂时缓解”。

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

  1. org-timegrid（https://github.com/Gleek/org-timegrid）：一个基于 Org 文件的 SVG 周历视图，具备完整鼠标和键盘支持，是 Emacs 日历视图的新范式。值得关注其实现方式。
  2. majutsu（https://majutsu.org）：Emacs 的 jj 客户端，刚上线宣传网站。由于 jj 在 Windows 上的进程开销问题，majutsu 通过减少 jj 调用次数优化性能，值得深入测试。
  3. JJ native 服务端：群友提到“要搞 jj native 的服务端”，这将摆脱对 Git 底层的依赖，是 jj 从“Git 增强”走向“真正下一代 VCS”的关键一步。结合 Martin 加入 ERSC 后的分化趋势，值得长期跟踪。
  4. 视频组件重构中的 neomacs：群友正在大重构，目标是在 v0.0.17 中让视频功能可用。这是 Emacs 生态中极具前瞻性的探索。
  5. X 平台图片布局算法逆向：有群友在复刻 X 的两套图片布局算法，并打算用 SVG 实现。这一思路可用于任意 Web 前端图片墙的自动布局。

观点延伸

今天最值得咀嚼的不是“Emacs 又出了几个新玩具”，而是两个老问题重新撞在一起：好工具怎样越过同温层，以及新工具怎样不被旧生态拖死。Emacs 插件出圈、neomacs 宣传、jj 商业化，其实都在讲同一件事：工程价值只有落到分发、治理和迁移成本上，才算真的成立。

1. Emacs 项目的核心瓶颈不是代码，是可见性

minibuffer-frame 被 Emacs News 收录后，群里第一反应是“必须写博客营销”。这不是虚荣，而是小众生态的硬现实：一个插件再好，如果没有截图、博客、安装路径、对比场景和持续曝光，它在用户眼里就等于不存在。

所以“去 Reddit、Mastodon 还是 X 宣传”的争论，本质不是平台喜好，而是受众筛选。Reddit 和 Mastodon 对 AI、新锐分支、商业化叙事更敏感；X 的算法分发更容易把东西推给非订阅者。工程判断很简单：如果目标是获得核心 Emacs 黑客反馈，保守社区有价值；如果目标是让 neomacs、视频组件、窗口级串流这类项目破圈，算法平台更有效。不要把渠道问题误判成信仰问题。

2. jj 的张力在于：兼容 Git 是入口，也是天花板

群里对 jj 的讨论很准确：它强在不抛弃 Git 生态，却提供了另一套 working-copy 即 commit 的心智模型。这对 AI Agent 很关键，因为 Agent 写代码时最怕“中间状态不可追踪”。jj 把每一步都变成可回退对象，比 Git 的 stage 心智更适合多轮试错、拆提交和审查。

但问题也在这里。只要底层仍依赖 Git，jj 就能接入 GitHub；也正因为如此，它很难完全摆脱 Git 的历史包袱。所谓 jj native 服务端，真正要验证的不是“能不能写一个新后端”，而是三件事：能否保留现有协作入口，能否解释清楚迁移收益，能否避免公司产品和开源项目在存储层上分叉到互相拖累。

可继续实践

可以拿 majutsu、org-timegrid、neomacs 视频组件做一个小型验证：每个项目只测三项——首次安装耗时、核心交互是否五分钟内可理解、遇到问题时是否能定位到日志或文档。能通过这三项的 Emacs 项目，才有资格谈“出圈”；通不过，就先别怪平台保守。