Geekinney

外观

Emacs 社区日报 2026-10-13

约 4718 字大约 16 分钟

2026-10-13

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

Emacs 社区日报 2026-10-13 手绘图
Emacs 社区日报 2026-10-13 手绘图

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：ETAF —— 在 Emacs buffer 里“写前端”的革命性尝试

今天讨论的绝对核心是 ETAF（emacs-taf），一个正在开发中的、旨在利用 Emacs 文本属性和 SVG 在 buffer 内渲染复杂前端（如游戏、工具界面）的框架。开发者 geekinney 公布了其最新进展，并发布到了 Emacs China 论坛和 Discord。

  1. 开发进度与核心思路：

    • 凌晨宣布已为 Markdown 做了渲染，下一步是做 Org-mode 导出支持，并考虑发布 v0.01。
    • 核心机制是：使用 Emacs 的文本属性来表达 UI，文本属性无法表达的再用 SVG，两者都无法表达的则无能为力。这确立了该框架的能力边界。
    • 对于用户尝试用鼠标滚轮缩放界面导致 UI 断层的问题，开发者定位为 text scale 调整与像素级布局计算冲突，并计划优化为在调整时整屏重绘。

  2. 社区反响与“评级”：

    • 群友给出极高评价，认为“这个框架我能评级到龙”。随之引出了一套群内自创的开源项目评级体系（狼、虎、鬼、龙、神），引起了大家的热烈讨论。
    • 有人提议用 ETAF 写代理工具 mihomo 的前端，展示了其应用潜力。
    • 有群友被其“游戏和 knuth plass 的库”打动，想通过 Telegram 的 Star/Premium/GRAM 进行捐赠，但受限于开发者没有国外银行卡，最终商定通过 telega 的 bridge-bot 方案解决。

  3. 生态与渠道观察：

    • 讨论从 ETAF 扩散到 Emacs 社区活跃度，普遍认为 IRC 人最多，Matrix 和 Discord 相对冷清（“一天有几条消息”、“一年就一两条消息”），并提及 Libera.Chat 对国内 IP 注册有限制。

🔑 关键概念与技术解析

1. ETAF（emacs-taf） 一个正在萌芽的 Emacs 框架，目标是在 buffer 内直接构建“前端”。它利用 Emacs 的文本属性（Text Properties）作为主要渲染机制，以 SVG 作为补充，从而让 Emacs 摆脱纯文本限制，实现更复杂的图形界面（如坦克游戏、UI 控件）。这被视为突破 Elisp 传统能力的尝试。

2. 群内自创的“开源项目评级体系” 一个有趣的、主观的项目价值评价标准：

  • 狼：路边货色，随处可见。
  • 虎：有亮点的工具类小包，锦上添花。
  • 鬼：眼前一亮，使用体验不错，解决日常痛点。
  • 龙：吸引力拉满，完成难度大且复杂，能独立解决整个工作流需求，通常有好看的 UI 前端和可配置的后端。
  • 神：让人眩晕瘫坐，仿佛看到原子弹爆炸，完成 Elisp 几乎不可能完成的事，突破 Emacs 限制，让 Emacs 解决更困难的需求。

💎 碎片知识与金句拾遗

  • 关于 Emacs 与编辑器：

    • “离不开 emacs 的理由是什么？”——“对我来说没有什么理由，其它编辑器我也偶尔会用。不过我用的其它编辑器都是闭源的，没emacs好用。”（点出了自由与可定制性才是核心吸引力）
    • “用了一段时间emacs,现在使用普通的文本编辑器都会不小心按C-x C-s来保存文件”—— 一种甜蜜的“肌肉记忆”副作用。
    • 关于 Helix 编辑器：“推进缓慢，长期不更新，社区不回应问题”，并质疑“开发团队是不是他们自己都不用这编辑器了”。
    • 近期 GitHub 维护数据：“编辑器维护最活跃的还得是 vscode，其次是 zed”，但随即被吐槽“vscode 已经屎山了”、“vibe人不应该不用编辑器了”。

  • 关于输入法与键盘布局：

    • vritser 展示了自己使用了多年的 Dvorak 键盘布局，并称“热区比 qwerty 集中”，但承认“换键盘布局比换编辑器还难做决定”。
    • 有人想放弃 Rime 输入法，自己用 SQLite 词库“搓”一个，认为双拼和大写辅助码降低了实现难度。甚至有人讨论利用 Emacs 特性实现“上屏後繼續顯示待選”这种超越 Rime 的功能。
    • 有人分享了把“输入法状态和 evil 的 state modeline 合到一起”的做法，被认为是“相当合理”的设计。

  • 关于文本排版与品味：

    • 针对王垠主页风格的转变，引发了关于“品味”的争论。有观点认为“有品味是需要有一些独特的见解，和是否有成就和产出无关”，而直接说人“没品味”与骂人“傻逼”无异。
    • 技术讨论：Computer Modern（CM）字体在屏幕上显示不佳，“细节太多”，建议用粗一点的 newcm 的 book 字重，或者改用 libertinus、tinos 等替代。
    • 有人分享了一个“基于 LaTeX 排版引擎的阅读器” hintview-reader，特点是可以通过缩放浏览器窗口来重新排版，技术原理见 hitex。

  • 杂项与观察：

    • 对 Emacs 的一个 bug 的确认：“首次打开 client 字体好小，关闭重新打开后恢复正常”的问题，vritser 表示“我也遇到了，还没空看”，且“好久了”。
    • “是不是以后练手项目不再是 todo list，而是 ps。”—— 指 Photoshop，感叹现在开发者练手项目越来越复杂，同时感慨“想要什么工具自己搓已经是常态了”。
    • 有人尝试让 AI 写一个 modeline 动画效果（“vibe了一个”），表明 AI 辅助编程已深入日常配置。

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

  1. ETAF 框架：尽管尚未发布，但其“文本属性 + SVG”的渲染思路极具潜力，可能为 Emacs 的 UI 开发生态带来新的范式。关注其 Org 支持进展和 v0.01 发布。可以尝试用 Agent 基于其链接进行开发试验。
  2. hintview-reader：一个基于 LaTeX 排版引擎（Hitex）的网页阅读器，能根据视口大小实时重排内容。这是一个把经典排版引擎与现代 Web 交互结合的独特尝试，值得跟进。
  3. 基于 SQLite 的自制输入法：开发者计划抛弃 Rime，用 SQLite 做词库并结合 Emacs 特性（如“上屏後繼續顯示待選”）实现自定义输入方案。这体现了将 Emacs 作为“操作系统”来深度定制的思路。

观点延伸

当天最值得咀嚼的，不是 ETAF 能不能画出坦克，而是它把一个长期被默认的边界说清楚了：Emacs 不必模拟传统 GUI，也不必追求“什么都能表达”；它可以把文本属性当作 UI 的基本语义，把 SVG 当作越界后的补充，剩下的部分明确承认做不到。这个判断比“在 buffer 里做前端”更重要。工程系统真正的能力，往往不是功能列表，而是对表达边界的诚实定义。

1. ETAF 的价值在于建立新的中间层

如果 ETAF 最终只是一个能渲染游戏和漂亮界面的库，它会很快陷入“又一个 UI 工具包”的竞争。但如果它能把 Org、Markdown、modeline、交互控件统一成一种可组合的表示层，意义就不同了：文档、程序状态和界面不再是三套对象，而可以在同一个 buffer 里互相转换。

这也解释了为什么 Org 导出是关键节点。Markdown 只是证明“能渲染”，Org 才能证明“能承载结构”。后续真正该验证的不是再做多少 demo，而是同一份结构化内容能否稳定地导出、局部更新、响应事件，并在缩放或窗口变化后保持布局一致。text scale 导致 UI 断层，暴露的正是这类框架的核心难题：文本编辑器的排版机制是流式的，而前端布局往往要求几何稳定。整屏重绘可以解决一致性，却也会把性能、状态保留和增量更新的问题推到台前。

2. “自己搓”正在从个人偏好变成软件工程策略

群里从 ETAF、输入法、远程访问一路聊到 modeline 动画，反复出现一个趋势：当现成工具的抽象层不再匹配需求，用户宁愿用 SQLite、文本属性和少量 Elisp 重建一个更窄、更懂自己的系统。AI 让原型成本进一步下降，但不会自动降低维护成本。

因此，判断一个自制项目是否值得继续，不能看它是否“酷”，而要看三件事：发起人是否持续使用；核心状态是否简单可迁移；外部依赖是否少到能够独立修复。群里说“只要发起人还在用，问题就不大”，其实已经接近一条实用的项目评价标准。它比单看 GitHub 更新频率更可靠，也比“有没有社区”更贴近个人工具的真实生命周期。

可继续研究/实践

可以用一个极小的 ETAF 项目验证这套判断：把输入法候选、编辑器状态和一段 Org 内容放进同一界面，只实现局部更新、缩放重排和键盘导航三项能力。若这些基本交互能稳定工作，ETAF 才算从展示技术跨入可复用的界面运行时。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题：Emacs 新锐扩展 etaf 与 AI 编程工具的实战体验

本群讨论了 emacs-taf 系列扩展的发布，尤其是 etaf-md-preview 和 etaf 主包。核心亮点是它基于 text properties 实现 UI，而非传统的 buffer 文本操作，甚至支持 SVG 游戏渲染。群友感叹“难以想象”，并有人计划用它重写 Gmail 客户端的前端（原本是 tabulated-list-mode 和 ewoc）。这体现了 Emacs 社区对轻量级、可嵌入 UI 框架的持续探索。

另一方面，AI 编程工具（如 Claude Code、Codex、Pi）的使用体验是群内高频讨论点。核心痛点包括：

  • Claude 封号问题：多位群友分享“养号”经验，如美区购买、日本代理、固定 IP、避免触发 cyber 标志。有群友称“只要不触发cyber就不会死”，但也有“买完活不过5小时”的惨痛经历。部分人转向 Cursor 或 GitHub 的企业版以规避风险。
  • 模型选型：OpenAI 的 GPT 系列被吐槽“上下文太短（256K）”和“口碑败得快”，而 Claude 的 Opus 在设计与代码阅读上被认为更强。有群友采用“20 刀 Opus 做设计 + GPT-6.1-sol 实现”的组合策略。
  • Pi 与多模型调度：对于 Pi 的使用，群友认为“如果你不知道怎么用，那大概就是不需要”，Claude Code 对大多数人已足够。但有人提到 orderwell 工具可以自动分配任务，并提及 CUA (Computer Use Agent) 和 decision model（如 JEV） 用于辅助 AI 操作图形界面。

专题：REA（Reverse Engineer Anything）与硬件逆向热潮

REA 是一个 MIT 开源的逆向工程工具，从 3 万 Star 涨至 12 万+，一天新增 2.5 万以上。群友分享了利用 REA 逆向空调协议的案例：通过 adb 抓取官方 App、分析 HAR/mitmproxy 抓包、Binwalk/Unblob 拆固件、Ghidra 分析，最后交给 Claude Code/Codex 还原协议。这被视为“一切软件都可逆”的宣言，并引发了关于“AI 时代逆向能力”的讨论。

🔑 关键概念与技术解析

  • etaf / text properties：Emacs 中一种将文本属性（如颜色、字体、点击回调）直接附加到 buffer 字符上的机制，可实现轻量级 UI。etaf 扩展将这一机制用于构建复杂的界面组件，甚至游戏渲染，突破了传统 Emacs 扩展的 UI 限制。
  • CUA (Computer Use Agent)：指 AI 模型通过模拟鼠标键盘操作直接控制电脑，如点击按钮、输入文本。群友指出通用模型直接读截图效果差，需结合决策模型（如 JEV）辅助判断。
  • orderwell：一个用于 AI 任务自动分配的工具，可根据模型能力将任务（如生成 spec、实现代码）分发给合适的 sub-agent，以优化缓存与效率。
  • REA：一款 AI 驱动的逆向工程工具，集成了 adb、抓包、固件分析、反编译等链路，能够从 App 或硬件中还原通信协议，进而实现“破解”或“重写”控制逻辑。
  • WebDAV：一种基于 HTTP 的分布式文件传输协议，群友讨论用它接网盘时提到“相对麻烦一些”，并推荐 clouddrive2 作为替代方案。

💎 碎片知识与金句拾遗

  • “API要钱吧” → “有免费的” → “肯定还是逆逆Web端方便”：关于 AI 服务成本与便捷性的简短对话。
  • “Claude 不封号了？” → “我周日刚被封”：关于 Claude 封号问题的自嘲式交流。
  • “Rust 编译为何需要占用硬盘这么大的空间” → “无共享缓存，元数据重复存储，调试符号膨胀，旧产物不自动清理”：关于 Rust 编译缓存机制的精准吐槽。
  • “node_modules 都得往后稍了”：对 Rust 中间产物体积的夸张对比。
  • “用存储换简单逻辑，减少复杂性，外加可能更好的性能。这几乎是我总会采取的策略。”：关于工程权衡的个人观点。
  • “PI 这种是给目标明确的人用的，不必强求，claude code 对大部分人来说很足够了。”：对 AI 工具选择的冷静判断。
  • “现在人的欲望被撑那么大，怎么给安全感？”：关于生活压力与心理状态的感慨。
  • “AI 一周就能写百万行代码，不休不眠一周人都看不完。”：对 AI 编程能力的量化比喻。
  • “X 是别人发 reset 已经没人鸟了，转发和点赞都没得。”：对 OpenAI 口碑下滑的观察。
  • “REA 逆向一切，拆硬件通信协议，家里的空调、热水器、灯，基本都配了一个难用的厂商 App。”：REA 应用场景的生动描绘。
  • “色盲是X染色体隐性遗传，女儿必须有两个致病的X染色体，但父亲的X染色体没有的话，那就不可能给女儿了。”：群友对生物遗传学的硬核科普。
  • “我们都双眼皮 娃单”：关于遗传随机性的日常闲聊。

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

  • emacs-taf 系列扩展：基于 text properties 的 UI 框架潜力巨大，尤其适合开发 Emacs 内的复杂界面（如 Gmail 客户端、Twitter 客户端）。值得研究其实现原理与生态。
  • REA (Reverse Engineer Anything)：AI 驱动的逆向工具链，从 App 抓包到固件分析全流程自动化。可用于智能家居协议破解、老旧设备控制等场景，极具开发潜力。
  • Hardware Use Agent (HUA)：群友提出用摄像头加主控做硬件操作代理，目前尚无成熟方案。结合 CUA 和决策模型，这可能是下一代人机交互的方向。
  • Claude 封号规避策略：群友分享的“养号”经验（美区购买、固定 IP、避免 cyber 标志）值得进一步验证，可能涉及风控模型的具体触发条件。

观点延伸

当天最值得咀嚼的，不是“哪个模型更强”，而是一个更硬的判断：AI 编程正在把工程能力从“写出代码”推向“定义问题、组织上下文、验收整体结果”。群里有人说 AI 一周能写百万行代码，人却一周都看不完；也有人已经在讨论主 Agent 如何生成 spec、如何分发给不同模型，以及上下文缓存是否友好。这说明瓶颈很快就不再是产量，而是系统能否被人类有效约束。

1. “会用 AI”本质上是建立可验证的中间层

如果只是让模型直接改仓库，规模一大就会出现局部正确、整体失控：单个函数看不出问题，架构、依赖边界和长期维护成本却可能已经恶化。群里提到“先用 Opus 做设计，再让其他模型实现”，方向是对的，但还不够。设计不能只是一段自然语言，而应当包含不变量、接口边界、迁移步骤、测试策略和失败回滚方式。否则所谓 spec 只是更长的提示词，不能真正提高可控性。

可验证的工程流程应该是：模型提出方案，人确认约束；模型分步实现，每步产出测试和差异；另一个模型或人工只检查关键不变量。真正有价值的能力，不是跟上 AI 的代码速度，而是能迅速判断“这批代码是否仍然属于同一个系统”。

2. CUA、REA 与 etaf 指向同一个方向：界面正在变成可操作的结构

CUA 讨论里有人指出，通用模型直接读截图效果很差，需要决策模型辅助；REA 则把抓包、固件分析、反编译和协议还原串成证据链；etaf 用 text properties 构建复杂 UI，也是在把界面从“看起来像页面”变成可组合、可响应的结构。三者共同说明：AI 最难处理的不是动作本身，而是缺少稳定的状态表示。

截图只能告诉模型“现在看到了什么”，不能可靠说明哪些元素可操作、操作后应保持什么约束。下一步的工程重点，应是给 Agent 提供结构化状态、动作前置条件、结果校验和可回放日志。无论是点击 Emacs 界面、控制手机，还是逆向空调协议，能否把黑箱交互转成可观测状态，决定了系统能不能从一次演示变成长期可用的工具。

可继续研究/实践

可以做一个小型实验：为一个 Emacs 客户端或个人知识库加入“状态—动作—验证”三层接口，让模型不能直接随意改 UI 或数据，而必须先读取状态、提交变更意图，再通过测试或快照确认结果。这个实验比单纯比较模型排行榜更能回答：AI 到底是在替人写代码，还是在推动我们重新设计软件的可验证边界。