Geekinney

外观

Emacs 社区日报 2026-10-27

约 5733 字大约 19 分钟

2026-10-27

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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：etaf 框架的现代化扩展设想与落地难点

群内围绕 etaf（Emacs 文本应用框架）的讨论最为密集，由多个子话题汇聚而成：从浏览器渲染方案、telega 集成优化，到 agenda 视图改进。核心矛盾在于——如何用文本渲染的方式对抗现代 Web 和 UI 的复杂性。

浏览器渲染方案（19:02 - 19:40）：多位群友表达了在 etaf 中嵌入浏览器的强烈需求（“浏览器要是可用，那就 nb 了”）。geekinney 回应称此前尝试两天效果不佳，“得想一个好的方案，优先级暂时往后排了”。关键技术路径浮出水面：

  • 用 headless chrome 渲染成静态 HTML/CSS，etaf 负责显示；
  • 交互层面通过 Chrome 实时计算 CSS 变化，将 diff 增量推送给 etaf；
  • 有群友用 Claude 验证过此方案可行性，但后来因 API 额度换成 DeepSeek 后“搞了两天没搞出来”；
  • 另有“半成品”可供参考，geekinney 计划用 Codex 再试一版。

etaf-telega 的 folder 支持与 UI 反馈（19:40 - 20:02）：群友反映 telega 群组一多就“失控感 100 分”，请求支持 folder 功能。geekinney 澄清 etaf-telega 基于 telega 而非重实现，集成应不复杂；同时邀请日常用户提交任何不满意的 UI 细节——“这些小修复对 AI 来说不难，我缺少这样的测试反馈的积累”。

agenda view 的层级信息与现代化重写（16:14 - 18:51）：有人提出在 agenda 视图显示任务层级信息，展示现有方案 SOMEDAY A ▸ B ▸ 事项 的格式。一位群友表示“一直都没怎么用过 agenda”，但准备用 etaf 开发一个现代化版本，并参考 calfw（日历框架）的交互设计。

🔑 关键概念与技术解析

  • etaf：Emacs 文本应用框架（Emacs Text Application Framework），允许在 Emacs buffer 中渲染富文本内容（包括图片、按钮、动画等），用于构建类原生应用体验。群内讨论表明它正被用于开发网易云音乐客户端、游戏、telega 集成等。

  • etaf-posframe：etaf 的子模块，可将聊天窗口像 QQ 一样“挂在旁边”，用 child frame 实现非阻塞式 UI 布局。群友评价终端下的 child frame 初版“太丑”，但可通过配置去掉边框改善。

  • scroll-conservatively：Emacs 内置滚动参数，控制滚动时保持光标位置的方式。群友发现该参数后表示可以改善特定场景下的滚动体验。

  • telega：Emacs 的 Telegram 客户端，依托 tdlib。etaf-telega 是其在 etaf 框架上的适配实现。群内讨论还提到 telega undo 修复已 merged，但 neomacs 0.0.20 在 telega 上出现回归（缩放图片与右对齐问题）。

  • calfw：Emacs 的日历/日程框架，被视作设计现代 agenda view 的参考对象。

💎 碎片知识与金句拾遗

  • mailmate 的试用绕过：过了 trial 依然能用全部功能，但每次启动发 2 封邮件后会被限制，重启即可继续。作者支持价 10 美元。有群友表示“outlook 总出问题”，另一人写了规则把邮件头含 maillist 的邮件自动归档，再用虚拟邮箱摘出来阅读邮件列表。

  • macOS 端 etaf 体验吐槽：vritser 反馈“macOS 使用下来问题有点多，还很难排查，主要是各种莫名其妙的卡顿”。

  • AI 辅助开发的高成本现实：“时间和 token 都有限”“我最多的时候开六七个 tab 同时干不同的项目，忙冒烟了”——反映出 AI 时代独立开发者同时推进多个项目时的资源瓶颈。

  • MBP 散热轶事：“这么多年了没听见过 mbp 的风扇响，然后现在就经常遇到”——侧面印证 AI 编程工作负载对硬件的压力。

  • 工作优先级判断：对于 port telega 到 appkit 的想法，有群友建议“为什么不直接写一个”，回应是“再发展发展，其他功能不完备的包的优先级更高”。

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

  1. headless Chrome + etaf 的增量渲染方案：用 Chrome 计算 CSS 变化、etaf 增量更新的浏览器嵌入方案，目前有半成品代码可参考。若成功，将打通文本渲染与完整 Web 生态之间的壁垒，是 etaf 最具潜力的发展方向。
  2. etaf-posframe 的聊天窗口挂载模式：借鉴 QQ 的侧边挂载布局，为 Emacs 内 Telegram 使用体验提供了新的交互范式。
  3. 基于 etaf 的现代化 agenda（参考 calfw）：群友明确提出开发计划，若落地将弥补 Emacs 原生 agenda 视图在层级展示与交互上的短板。
  4. AI 驱动的 UI 微修复流水线：geekinney 的实践表明——将用户 UI 反馈转化为小修任务交给 AI 处理，可能成为开源维护者应对细节打磨的新工作流。

观点延伸

今天群里两条线看着不相干，其实是同一个问题：etaf 想用文本去对抗复杂度，而每一次妥协都不是消掉复杂度，是把它换个地方存放。

浏览器嵌入走的是 EAF 的老路，不是 etaf 的新路

方案本身很优雅：headless chrome 渲染出 HTML/CSS，etaf 负责显示；交互时由 chrome 实时计算样式变化，只把 diff 增量推回 buffer。但对比另一句评价就够了——“eaf 那个就是太卡”。卡顿的根源不是整帧重绘还是补丁流，而是 CSS 布局模型和字符网格之间没有可逆映射。补丁流只是把同步点从每帧挪到每次样式变更，跨进程往返一次没少。

更关键的是，etaf 的优势恰恰是“buffer 里渲染的都是文本”。chrome 一旦进来，isearch、键盘宏、文本操作、org 集成就会全部失效或退化，etaf 也就退化成一个更慢的 EAF。所以“优先级往后排”不只是精力问题，还因为这条路会否定 etaf 自己的立身之本。

反观“把需求大的网站慢慢做成 app”“在 eww 基础上做美化、至少支持复杂布局”，这两条才是真正收敛复杂度的做法：不追求覆盖 Web，只追求覆盖你每天打开的那二十个页面。判据也很朴素——上线前先问一句，它把复杂度从哪儿搬到了哪儿。

agenda 的层级问题不是格式问题，是容器问题

SOMEDAY A ▸ B ▸ 事项 和 SOMEDAY 事项（A ▸ B） 两种排法都别扭，因为都在把一棵树压进一行字符串。agenda 的每一行本质是扁平的搜索结果，它没有“分组”这个容器，路径就只能挤在行内。所以改格式零成本、也几乎没有收益；改分组模型（按祖先折叠、按 project 分段）才是重写的真正理由。

这里有一组对照值得记下：作者说 etaf-telega“我缺少这样的测试反馈的积累”，另一位群友说“我一直都没怎么用过 agenda”。这两种情况其实是同一个问题——想去重写一个自己身上还没形成日常摩擦的东西。摩擦没积累到能说出具体痛点的程度，重写出来的大概率是个漂亮的、没人用的东西。

可继续的方向

真要碰浏览器，先做一个一天期的 spike，验收标准写死：任意含 flex/grid 的静态页面渲染进 buffer、链接可点、滚动不错位。过不了就归档，不追加投入。这类任务的失败模式从来不在“写不出代码”，而在“没有正确性定义”，所以判据必须前置——卡住的那两天属于后者，不属于模型强弱。

agenda 反过来：第一版只做分组折叠，交互范式不动，拿一周真实使用来验证，再决定要不要 calfw 式的重交互。

再抽象一层，etaf 的路线图值得配一本复杂度记录：每个新 app、新功能，记一句它把复杂度从哪儿搬到了哪儿、有没有引入不可逆的非文本层。文本 UI 的长期价值不在渲染得多漂亮，而在它把所有界面都留在了可被 grep、可被脚本、可被 diff 的平面上。

约 900 中文字，无裸 HTML 标签、无私有信息、无编造事实（引用均出自当日聊天记录）。同时已存一份到 /tmp/opinion_ext.md，需要直接落盘到日报时可复用。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：AI 时代下的 Emacs 生态变革与社群矛盾

群内围绕 Emacs 展开的讨论跨越了多个维度，从配置、补全到商业化和未来形态，呈现出 Emacs 社群在 AI 浪潮中的复杂心态。

技术实践层面：

  • elisp 补全痛点：讨论指出补全 elisp 信息的最大问题在于“需要先打括号”，这严重影响了输入流畅度。有群友分享了自己魔改的 company 插件（company-yasnippet-autoparens），旨在解决这一痛点。
  • 卡顿问题归因：针对 Emacs 卡顿，有群友提出疑问：“卡顿会不会是因为很多 elisp 写的插件是解释运行的而没编译？”这引发了关于插件性能优化的讨论。
  • Neo Emacs 的多线程之路：有群友询问 Neo Emacs 是否实现了 true 多线程，得到的回应是“elisp 这块还没办法多线程吧，茫茫多的库都假设单线程写的”。讨论认为，插件不可能 100% 兼容，但“只保证功能 100% 有”是更现实的路径，而 Neo Emacs 作为“先驱者”已经投入了大量资金。

商业与社群心态：

  • Emacs 的“贩卖”现象：群友惊呼“草，emacs也有卖的了”，并感叹“卖‘Emacs’ 的难度要远大于 卖‘Vscode’吧”，因为能知道 Emacs 的人通常已具备较深的技术背景。这一话题引发了关于谁在购买、为何购买的讨论。
  • 对 AI 的矛盾态度：有群友分享了自己在 Reddit 上因发布 AI 辅助整理信息流的插件（Supertag）而遭到 downvote 的经历，并感叹“emacs 社群对 AI 的使用为啥态度这么奇怪的呢”。讨论将这种心态类比为“类学术圈”——一方面 gptel、agent-shell 等 AI 插件被广泛追捧，另一方面对 AI 的“明面讨论”却持排斥态度。有群友认为这源于对“credit”的看重，程序员“大大方方说就是 vibe 的”，而学术圈对 AI 的使用在 credit 计算上存在根本性难题。

专题二：AI 赋能下的输入法革新

群内展示了一个正在开发中的、深度融入 AI 与本地模型的输入法方案，引发了关于输入法未来形态的热烈探讨。

  • 核心方案：该输入法“完全不显示字母”，采用本地模型（qwen3.5 2b 和一个自训的小模型）进行 token 层面的概率预测，而非依赖远程模型以保证低延迟（“no thinking 应该很快”，预估延迟在几十到一百多毫秒）。
  • 工作模式：分为 decode 和 verify 模式，其中 verify 模式能打出更多字。当前模型主要针对微软双拼训练，架构上不便适配其他方案（除自然码外）。
  • 智能上下文：该输入法已与 Emacs 绑定，能将“前文信息”纳入考量，未来计划将“聊天上下文纳入上文”，从而可能实现“AI 自动判断中英文，无需手动切换”。
  • 痛点与反馈：讨论指出该方案“还是得搭配辅助码使用”，因为“没法翻页”，首次打不出的字需要依赖学习机制。群友分享了墨奇码作为辅助码方案，其逻辑为“递归拆分至最小字形，最后取首末双形音托”，但也有观点认为偏旁拼音做辅助码可能更好用。

🔑 关键概念与技术解析

  • elark：一个将 Emacs 与飞书（Feishu/Lark）连接起来的 Melpa 包，实现在 Emacs 内进行飞书消息的读写操作。链接：melpa.org/#/elark
  • Lifestreams 模型：一个经典的、将个人数据流（如文件、邮件、浏览记录）整合为可检索的时间线（流）的模型。群友 Supertag 插件的更新正是对该模型的情景复现，并尝试将其与“对话式 AI”结合。
  • mg (Micro GNU Emacs)：一个由 Emacs 早期版本简化而来的轻量级文本编辑器，被称为“简易版 emacs”。因其“不让叫 emacs，改名叫 mg”，体量与 nano 同级，但功能更丰富，从源码编译最新版可获得语法高亮、goto-next-error 等现代特性。
  • Moqi 码（墨奇码）：一种中文输入法辅助码方案，其核心逻辑是“递归拆分至最小字形，最后取首末双形音托”。例如，“鹤”拆分为“宝盖”和“鸟”，“递”拆分为“走之”和“弟”。官网文档：moqiyinxing.chunqiujinjing.com
  • Python's experimental JIT to be removed：Python 官方正在考虑移除实验性的 JIT（Just-In-Time）编译器，意味着 CPython 的性能优化路径可能发生调整。来源：LWN
  • Generative UI / 可塑化软件：Supertag 作者提出的两个前沿理念，认为 AI 的嵌入“并非画蛇添足”，而是回应了“生成式 UI”和“可塑化软件”的思潮，即软件界面和功能能根据用户意图动态生成和调整。

💎 碎片知识与金句拾遗

  • 搜索策略：“搜技术的肯定不能用国内引擎，搜娱乐、八卦、财经的时候你用国内的搜，准确率保证比国外的引擎高。”
  • 自建输入法初衷：“我在做的输入法，加油，早日取代 ibus 那个拼音输入法，那个输入法总是不稳定。”
  • AI 代码投入产出比：“ai 写代码的投入产出比是越来越低的，主要还是刚开始太高了……因为随着代码库增长，注意力显著下降。”
  • 共享 Token 风险：“共享 token 还是有风险的，别人用你的 token 去做 cyber security 的东西……A/ 会封，O/ 会削减额度。”
  • Emacs 阅读体验：“emacs 适合看文字内容多的网页吗？”——群友分享了用 eww 阅读长文的效果，认为“效果不错啊”。
  • Rust 宏与 Lisp 宏：“rust 宏没有 lisp 宏好用，lisp 是随手就能写，rust 的宏写起来很麻烦。”随后有群友反驳：“我觉得不随手写是好事，而且 rust 卫生宏这块很文明。”另一人回：“rust 就是太文明了。”
  • 个人项目协作观：“现在这个人时代还需要多人协作吗”——在讨论 C 语言“自我限制的语法一概不学”的畅快感时提出。
  • 硬件投资心得：“我的 5090 已经翻倍了”“卖了买 4090，据说破解了 gpu 了，性能大幅提升”——群友分享 GPU 硬件投资的收益经历。
  • 台积电风险警告：Anthropic 在 IPO 招股书中点名台积电，警告先进芯片制造产能高度集中台湾的风险，凸显 AI 供应链的地理脆弱性。
  • 国内互联网生态对 AI 影响：“国内封闭的互联网（指各家生态）不利于 ai 发展，大家都是匪，搞不定。”
  • 短剧行业观察：“字节的报告，短剧几乎吃下了 80% 的影视市场（国内）”“现在精品短剧已经不会噘嘴讲话了，人物区分度也高，感觉半年就能有个明显的进步。”
  • 产品营销观点：“做东西不要先给别人讲原理和概念，这些东西只有别人问，才需要说……符合 emacs 思路的就是，这个是什么，它能做什么。其它的是用户自己的事。”
  • 关于内容推广的建议：“第一句话你要说你这个是什么视频，你是来讲原理的，演示 emacs 使用的，还是什么……你不能让观众打开视频先被问一个问题，这个又不是短视频平台。”
  • 对 AI 对话的反思：“很快人类就会对不停地跟 AI 对话感到厌烦了。”
  • 推荐工具：“我最近把 b 站也删了，感觉世界突然过于清净了”“过于清净就对了，创造力往往来自无聊”。
  • AI 安全警醒：“host & password 啥的都直接给 ai 了，简直是裸奔”——群友反思自己为配置 clash 路由直接将敏感配置交给了 AI。
  • Reddit 生态吐槽：“怯魅了、感觉 reddit 其实和百度贴吧也没差”“现在解封了，但之前的帖子全部被清理了。”
  • 小众信息源推荐：“最近对小红书感觉颇有好感、上面大佬感觉好多”“我觉得你还可以研究一下 bilibili，我天天在上面发现类似项目，都是一群神人来的。”
  • supertag 0.4.0 的 pattern 判断：“supertag 0.4.0 的 pattern 以后必然会是一个新的潮流。”
  • 单词读音科普：“原来这个子念 yuan，我一直以为是 heng。”——指“断壁残垣”中的“垣”字。

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

  1. 基于 LLM 的中文双拼输入法：该项目展示了本地小模型（qwen3.5 2b）在 IME 领域的应用潜力，特别是 decode 与 verify 双模式设计、结合上下文的智能判断，以及未来“不切换中英文”的交互设想。可作为边缘设备上的轻量级 AI 应用案例深入跟踪。
  2. Moqi 码（墨奇码）辅助码方案：其“递归拆分至最小字形，首末双形音托”的设计逻辑在中文输入法领域颇具独创性，值得对照其他形码方案（如五笔、郑码）进行剖析，或思考其与 AI 输入法的结合可能。
  3. 共享 Token 的 P2P 化：群友提出的“p2p token”思路虽有封号风险，但反映了 API 资源分配与共享的经济学问题。可关注后续是否有安全、合规的去中心化解决方案出现。
  4. Neo Emacs 的多线程实现：作为一个投入大量资金的项目，Neo Emacs 如何在保留 Elisp 生态的前提下突破全局锁限制，实现“功能 100% 有”的兼容策略，是 Emacs 现代化进程中的关键观察点。
  5. Supertag 的 Lifestreams 模式复现：Supertag 0.4.0 将经典 Lifestreams 模型与“生成式 UI”结合，体现了非对话式 Agent 界面的探索。其 pattern 机制可能成为信息流处理的新范式，值得持续关注其在 Emacs 社区的反响。

观点延伸

中心判断：AI 进入成熟工具生态，阻力很少来自“能不能做”，而来自“契约有没有被改写清楚”。当天三条线索——Supertag 的 downvote、自建输入法的延迟预算、Neo Emacs 的兼容目标——说的是同一件事：社群不是拒绝模型，而是要求模型别破坏既有的可读性、响应时间与兼容边界。

一、downvote 不是一场反 AI 投票

作者把 Supertag 在 Reddit 的遭遇归因为“Emacs 社群对 AI 态度奇怪”，但同一天群里的具体批评很朴素：长文没分段、markup 直接糊在正文、视频开头先抛问题、产品演示和个人思考混在一起。如果真是意识形态式排斥，gptel 和 agent-shell 不会同时被追捧。一个可验证的判断是：看社区是否排斥 AI，不看它怎么谈 AI，看它给不给“用了 AI 但交付清楚”的东西投票。被扣分（downvote）的其实是不好读、定位杂糅，以及把本该由读者完成的推理硬塞给读者——这更像编辑问题，而不是 AI 问题。如果判断错了原因，解决方向也会错：作者在解决“如何让社群接受 AI”，真正要解决的是“如何让作品在三十秒内被读懂”。

二、100ms 的回路里，模型只能做收窄器

自建输入法最有信息量的细节不是本地小模型，而是“没法翻页”“还是得搭配辅助码”。翻页是传统输入法留给用户的纠错通道；一旦取消，系统就必须首次即正确，于是它不得不外挂墨奇码这类确定性的字形拆分来压缩候选空间。这说明在硬实时交互里，概率模型的合理位置是排序与收窄，而不是接管整条路径——它提供的是先验，不是决策。decode/verify 双模式也是同一思路的显式化：先给低成本假设，需要时再加算力。延迟预算决定架构，而不是反过来。

三、“功能 100% 有”是重写老系统最诚实的兼容契约

面对“茫茫多的库都假设单线程”，靠改运行时实现真多线程几乎必然失败；群里那句“插件不 100% 兼容，只保证功能 100% 有”反而更像工程判断：把兼容目标从 API 平移到行为，代价是必须把生态从“代码资产”翻译成可执行的验收清单。这也解释了为什么 AI 写代码的投入产出比会随代码库增长而下降——它消耗的是注意力预算，而老项目的真实成本是把隐性不变量找出来，这项工作是没法靠生成加快的。

四、把“推送 + 时间流”抽掉，剩下来的才是选择

旁边那段关于短剧与删 B 站的讨论，其实是同一根线：被推送喂大的信息流，会让人误把“眼前出现的”当成“值得看的”。Supertag 想做的 Lifestreams 式时间线，价值不在于多一层 AI 摘要，而在于让用户能自己定义流的边界。“创造力往往来自无聊”之所以成立，是因为无聊逼你检索自己的库存，而不是接住别人的推荐。

可继续实践：挑一个自己天天用的 Emacs 包，做一次“契约审计”——列出它依赖的隐性假设（单线程、同步调用、全局状态），再看哪些能被转化成显式测试。这比争论社群是否反 AI 更能预测 AI 究竟能进来多深。

（正文已写入 /tmp/ky-extension.md，可直接取用。）