Geekinney

外观

Emacs 社区日报 2026-09-29

约 6339 字大约 21 分钟

2026-09-29

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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：Emacs 在 tty 与 GUI 环境下的使用体验

群内围绕 tty 与 GUI 环境下 Emacs 的差异展开了较为深入的讨论。几位群友分享了各自的使用习惯与痛点：

  • 有人坦言“我已经爱上 tty emacs 了”，但同时也指出 tty 下存在按键冲突问题（如 tmux/herdr 环境），需要统一按键方案。
  • 有群友提出“统一按键”但承认“冲突还挺多”，不过表示“能接受很多功能走 M-x”，因此不强求所有快捷键一致。
  • 技术上，tty 的文本属性支持（如 face、underline 绘制）存在局限——Windows 的 tty face 刚支持绘制 underline，而 GUI 刷新流畅度明显优于 tui。
  • 一个值得注意的实现缺陷被提及：tty 下 repeat mode 无法使用 M- 前缀按键（如 M-g M-n 默认无法用 M-n 进行 repeat），被认为是设计缺陷。

专题二：AI 编程助手生态的迭代与选择

群内多位成员围绕 AI agent 工具的选用进行了讨论，观点鲜明：

  • 提到 Pi（原 pi-coding-agent，曾两次改名），有人评价“Pi 真不错，我越来越能体会到它的理念：There are many agent harnesses, but this one is yours”。
  • 也有成员对 agent 泛滥表示反感：“agent 太多完全是熵增，要不是 codex 是订阅式的，我宁愿用 opencode”。
  • 关于 codewhale，有人指出“是个 web，且模型不够强”，并回应了一个笑点——“提到 codewhale 第一个想到的不应该是 deepseek-tui 吗”。
  • 关于扩展质量问题，有成员建议“自己去做扩展和技能。我基本上都是自己做的”，认为现有扩展质量参差不齐且更新过快。

专题三：群内积分与 tag 机制的调整

群主宣布将“直接修改 tag”权限关闭，改为“100 积分兑换 tag”，并提到若可修改机器人逻辑，可以实现“5 积分回答一次问题”的玩法。有成员提出异议：“没必要把已有的功能设置为需要积分来兑换”，群主回应“好滴”，似乎接受了建议。整体氛围偏向娱乐化，积分“仅作排行使用，看看谁最水”。

🔑 关键概念与技术解析

  1. sexp（S-expression）：Lisp 家族的基本语法结构，形如 (test (+ q w) (x a b))。聊天中有人提到“消息里面含有 sexp 可以加分”，暗示这是群内积分机制的彩蛋。

  2. Pi（AI 编程助手）：一个基于 agent harness 的编程辅助工具，原名 pi-coding-agent，历经两次改名。其理念强调“harness 属于你自己”，不同于订阅制的 codex，更注重用户自定义与掌控力。

  3. Lem：一个用 Common Lisp 编写的编辑器，支持插件系统，也可使用 asdf 管理依赖。群内有成员提到“我 vibe 的 lem 已经能当浏览器用了”，暗示其正在发展 WebView/WebKit2GTK 相关的浏览器能力。

  4. vibe / vibing：在此语境下指通过“vibe coding”（受 AI 生成代码引导的开发方式）快速搭建工具，如“lem 已经能当浏览器用了”是 vibe coding 的成果。

  5. Repeat Mode（Emacs）：一种按键重复机制，允许在连续执行某类命令时省略前缀键。群内指出 tty 下无法使用 M- 键进行 repeat，是 Emacs 在终端环境的实现限制。

  6. Agent Harness（编程代理框架）：指用于承载、调度 AI 编程 agent 的工具框架，如 codex、opencode、Pi、codewhale、dsh 等均属此类。

💎 碎片知识与金句拾遗

  • “消息里面含有 sexp 可以加分😏”——积分系统的隐藏彩蛋，S-expression 爱好者的小乐趣。
  • “现在改成 100 积分兑换 tag，然后关闭了直接修改 tag 的权限🌚”——积分体系从“开放性”转向“可交易化”，但已有成员提出反对。
  • “macOS 27 感觉有问题，Emacs 就一个 frame，他显示四个，有时候甚至更多”——后台起的 Emacs 在 macOS 上出现 frame 数量异常，可能是 window-manager 与 server-client 模式的问题。
  • “你是 server-client 模式启动的吗？我直接 desktop 没有见过这个问题”——区分不同启动方式对 bug 定位的意义。
  • “我 vibe 的 lem 已经能当浏览器用了”——Lem 编辑器通过 WebKit2GTK 获得了浏览器能力，是 vibe coding 的成果展示。
  • “tty 的文本属性支持全嘛？——应该要用到界面本身的机制吧”——关于 tty 与 GUI 渲染差异的讨论。
  • “tui 方面的编辑器我用的微软的 edit 编辑器”——有人偏好微软的编辑器的 tui 体验。
  • “2k 还能买到 32G 啊（”——2000 元价位买到 R7 8845HS + 32G + 1T 的机器，被认为是群友友情价。
  • “曾经的包名就叫 pi-coding-agent，改了两次名”——工具的命名演变，暗示项目方向的调整。
  • “我绝的 agent 太多完全是熵增”——对 agent 生态过度膨胀的批评，但“熵增”一词也暗合“熵减”的哲学追求。

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

  1. Emacs tty 环境下 repeat mode 的限制：tty 无法使用 M- 前缀进行 repeat，是 Emacs 终端实现的核心缺陷。若深入探索 Emacs 终端层（如 term 端字体渲染、keymap 处理）或对比 Windows 与 Linux 终端差异，可能发现更优雅的解决路径。

  2. Pi 的理念与实践：Pi 强调“harness 属于你自己”，与 codex 的订阅制形成对比。研究其架构（如何通过 agent harness 自定义工具链）及改名历程，可能揭示 agent 工具从“通用”走向“个性化”的趋势。

  3. Lem 编辑器 + WebKit2GTK 的浏览器化尝试：Lem 已能通过 WebView 作为浏览器使用，这对编辑器的扩展边界提出了新的想象空间。值得关注其插件系统与 asdf 的集成方式。

  4. 群内积分/tag 机制的玩法实验：虽然目前仅用于“看看谁最水”，但群主提出“5 积分回答一次问题”的 bot 交互设想，未来若实现，可能形成新的社区激励模式。

观点延伸

今天两条主线表面无关——tty Emacs 的按键妥协、AI agent 生态的取舍——底层其实是同一个工程命题：当约束来自你控制不了的层，正确动作不是"统一"，而是先分层，再把不可控的东西关进边界里。

一、tty 的按键问题不是 Emacs 的缺陷，是终端协议的缺陷。 有人指出 tty 下 repeat mode 用不了 M- 前缀（所以 M-g M-n 默认要再补一个 n），判断是"实现缺陷"。这判断只说对一半：Emacs 的 keymap 能绑任意键，卡住的是终端对修饰键的编码——终端能交给你的信息本来就比 GUI 少，某些终端与多路复用器下 M- 与无修饰键根本区分不开。所以"统一 tty 和 GUI 按键"这个目标本身要拆：命令层（功能一致、M-x 可达）可统一，物理按键层不该也不可能统一。同理，Windows 才刚支持 tty face 画 underline，说明 face 属于终端实现能力，不属于编辑器。判据很简单：绕不过终端的差异，就别塞进"配置统一"清单，塞进去只会变成长期债。

二、repeat mode 那个坑该做一次最小验证，而不是停在印象里。 它的可验证形态很清楚：纯终端起一个 Emacs，试 M-g M-n 后能否用 M-n 继续 repeat；再定位卡点在 input-decode-map、key-translation-map 还是 repeat-mode 自己的前缀判断。这决定了处置方式——"终端给不了"只能接受并写进文档，"Emacs 没接"就是能提 patch 的真 bug。今天讨论缺的正是这一步。

三、agent "太多是熵增"别用数量论证，用可替换性论证才准。 "要不是 codex 是订阅式的，我宁愿用 opencode"——这句话其实承认了选择自由度已被计费模型改写。而 Pi 那句 There are many agent harnesses, but this one is yours 之所以打动人，是它把卖点从"更强"换成了"可替换"。这可以当体检表：列出你每天真实敲的命令，看哪些换一家 harness 就失效。失效越多，harness 越不是你的。

四、"自己做扩展"的真正理由是变更速率，不是质量。 面对"扩展质量不高、更新还超级快"，回答是"自己去做扩展和技能"。要精确：好处不是你写得更好，而是 breaking change 由你决定何时吞。上游快迭代对上游用户是 feature，对你是不可控的输入速率。操作判据就是依赖数 × 升级摩擦——每加一个扩展先问一句"它改了我跟不跟"。

可继续实践：维护一张"能力差异清单"，只记两类——底层给不了、只能接受并写清理由的；以及绕不过去但其实能修的（值得复现、值得提 issue）。第一批先填 tty 下的 repeat mode M- 前缀。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：AI 模型与订阅额度之争（持续全天，热度最高）

背景：群内多位成员深度依赖 Claude、GPT（Codex）、DeepSeek、Astra 等模型进行日常编码和自动化任务，当天多家模型额度调整引发剧烈讨论。

核心观点与痛点：

  1. 额度消耗异常加速：多位成员反馈新升级的 Codex 额度极不经用——“一点半用的重置卡，现在只剩35%”；“这几分钟用了4%”；“一个任务快把5h额度用完了”。有成员分析认为“升级了新版 codex 之后，额度就更不经用了”。
  2. Codex harness 粗粒度问题：成员批评 Codex 的“harness 不知道咋做的，喜欢干完之后发现不行就全部撤回，然后就是白消耗 token”。进一步指出“太粗粒度了，代码开发不是这么回事啊，谁这么写代码啊，天天推倒重来”。
  3. Pro 200 额度调整预告：据 Tibo 消息，OpenAI 计划调整计划倍率——Plus = 1X、Pro 100 = 5X、Pro 200 = 10X，现有用户将“在一段时间内继续保留 20X 倍率”，但整体额度收缩已成定局。群友建议“立刻蹬，把手动刷新都用了。等更新了，估计一张重置的额度只有现在的一半”。
  4. 模型轮流降智的猜测：“感觉就是正常周期，轮流降智。猜测有个训练节奏什么的，训练耗算力多了就会降智”。另有观点认为“额度他是真的降了很多，gpt 最近几代只有首发能用”。
  5. Astra 变拉 vs Claude 超长思考：“现在明显 astra 变拉了，开始超长思考了”；“我经常会出现 more thinking，deep thought，thinking some more，ultra think”。
  6. Claude Sonnet 5.5 发布：群友分享 Anthropic 链接，评价“好快”“美美狙击 openai”，并传出“sonnet 5.5 接近 opus 5.5，然后 opus 5.5 是接近 fable 的”的说法。

解决方案与替代：

  • 群友强烈推荐 DeepSeek：“deepseek现在是我最大生产力”“又聪明又主动”；“deepseek-v4.1-falsh 已经很强了，只要指导模型够强，代码质量还是可以的”。具体案例：用 DeepSeek 成功打通音箱协议自动控制播放，并“用 AI 来逆向和搞搞硬件设备”。
  • 有群友推荐 Gemini：“没人用gemini，比ds便宜，比ds好用😆”。
  • 配置建议：将 Fable 或 Astra 设置为 /advisor 的建议模型，“spec review 能找出不少东西”；“astra 在建议方面表现很不错”。

专题二：Emacs 生态的现代化探索（持续多条线索）

1. video.el 与 excali-mode 的 DSL 方向

  • 群友发现 video.el 用十六进制数字表示颜色（#xff8000 应为 #ff8000），引发“给我人干傻了”的吐槽。
  • excali-mode v0.1.1 发布，修正了体验问题并添加 DSL 语言支持。群友提出“搞一个 DSL 来绘制应该是一个不错的方案。把绘图结构化，这样 AI 就可以直接生成代码来画图”，并分享 excalidraw-dsl 项目。
  • 群友体验反馈：素材库需支持同步官方素材库、误添加的素材无法删除。

2. Emacs App 框架之争（ETAF vs APPKit）

  • 群友在晚上展开“Emacs App”路线的讨论：ETAF（所有内容在一个 buffer，组件化替换实现页面切换，类似前端单应用）vs APPKit（多个 buffer 各干固定事，一个 app 是一系列 buffer 的集合）。
  • 交互设计讨论：有人提出用 Vimium 式单字母按键操作可交互元素，支持纯键盘；有人建议研究 embark（“根据光标所在对象提供不同操作，有点像鼠标右键”）；也有人强调触屏交互需求。
  • 群友用 DeepSeek 制作了网易云音乐技能，将后端能力接入 ETAF 前端，并惊叹“5分钟直出一点都没有调”“Deepseek 的 UI 审美真可以，至少比 GPT 要好”。

3. simpc++-mode：大文件语法着色的替代方案

  • 群友分享 simpcpp-mode（GitHub 仓库名无法写 ++），主打超大文件下的快速着色：“30w行代码用我的 simpc++-mode 就是秒开”“treesitter 和 c++-mode 做不到”。原理是绕开纯正则和树解析的折中方案，但群友认为“还是比不了 c++-mode”，建议“10w行以上的文件就用 simpc++-mode”。
  • 讨论中顺带指出“纯正则无法完美着色函数的参数解析”“正则是一行一行匹配的，性能可能比 treesitter 快，但复杂场景就不行了”。

专题三：家庭网络与 NAS/存储的实践分享

  • 群友成功解决公网 IP 无法使用的问题：“找到家里的公网 ip 用不起来的原因了，这是经典的旁路由的坑。解决方案就是内网把一台机器的网关指向主路由，然后内网服务用这台机器来做反向代理暴露出去”。
  • 群友讨论 NAS 的价值：“现在 nas 最大的意义就是数据冷备份了”“量大管饱”。分享群晖 ds923+ 约 5k 元配置。
  • 硬盘价格对比：2020 年希捷 8TB 1399 元 → 现在 1899 元；24TB 约 4950 元。“机械硬盘单纯拿来存数据的话还是挺不错的吧”“便宜量大，数据可恢复，冷备份不频繁读写的话寿命更长”。
  • 有群友分享极复杂的家庭网络结构（月支出 400+），推测需求包括 TikTok 带货、AI 使用、防封号等。

专题四：开发者生存现状与职场讨论（午后高潮）

  • 多位群友处于失业/接单状态：“我失业 6 年了”“我也失业”“我应该算失业1年”。有群友自嘲“我是最菜的 javaer”“我只会写意大利面条代码”。
  • 讨论国内就业歧视：Gap 歧视（“gap 在某些人眼里跟进过监狱差不多”）、女性婚育歧视、年龄+学历问题。
  • 分享公司“利用内部转岗逼退”案例：合同签南京范围内可转岗，“转岗要征得员工同意且有上岗培训”，实际操作“降薪或转外包，不同意就得离职，有 N+1”。群友提醒“合同还是得仔细看”“扫地出门前保存好各种记录”“支持水印的相机拍照作为补充材料”。

🔑 关键概念与技术解析

  • 旁路由（旁路网关）的坑：家庭网络中若设备网关指向旁路由而非主路由，公网 IP 可能无法正常映射。解决方案是将某台机器网关指向主路由，再通过反向代理暴露内网服务。
  • ETAF：Emacs 文本应用框架，采用单 buffer + 组件化替换实现页面切换，类似于前端单页应用（SPA），适合承载图片、视频等 Emacs 能渲染的内容。
  • APPKit：另一个 Emacs App 后端框架，采用多 buffer 模型，每个 buffer 干固定的事，一个 app 是一系列 buffer 的集合。
  • Vimium 式交互：借鉴浏览器 Vimium 插件的思路，用单字母按键操作页面中可交互的元素，支持纯键盘巡航（Tab 键切换焦点）。
  • embark：Emacs 的交互命令框架，可根据光标所在对象动态提供相关操作（类似鼠标右键菜单），适合用于 App 框架的上下文感知交互。
  • DSL 绘制：将绘图操作结构化为 DSL（领域特定语言），使 AI 可以直接生成代码来画图，降低 AI 参与图形创作的门槛。
  • simpc++-mode：针对超大 C++ 文件优化的 Emacs 语法着色模式，绕过正则和完整树解析，牺牲部分准确性换取秒开性能（“30w行秒开”）。
  • Hugging Face Pro（9刀/月）：包含 20 个 2C/16G/50G 的 Docker Space + 10 个 104G 内存 ZeroGPU Space + 每天 40 分钟半块 RTX6000 GPU + 2 刀 API 额度 + 1T 私有化存储，群友正在评估是否值得尝试。

💎 碎片知识与金句拾遗

  • 关于 AI 自动化体验：“太聪明了。它前面会问我有没有听到音乐，用来测试协议有没有打通。然后后面它就能想到直接用我当前的电脑的麦克风来收音，自动去判断它的这个链路有没有去打通……真正的自动化的处理，挺惊艳的。我觉得其他的模型真的不一定能做到。”
  • 关于 AI 生成 UI：“Deepseek 的 UI 审美真可以，至少比 GPT 要好。”“好看确实挺好看的”“这和真的 app 有啥区别哟”。
  • 关于指针：“指针这东西也是时代眼泪了，除了 C 系里面，现在的高级语言都没有这个概念了吧”“指针运算现在看来真的黑魔法了”“初学是挺难理解的，反正记住存的是地址就行了”。
  • 关于 Emacs 使用场景（群友列举）：
    • “1. herdr 跑 coding-agent，切其他 tab 进行查看 spec、diff；2. 记笔记；3. gtd”
    • “用 emacs 给 GNU 贡献一点代码；给自己写个人疑难杂症文档.org；用来收发邮件和参加讨论；用来当 telega 客户端；用 eww 阅读一点文档；生成个人博客”
    • “我还用 emacs 写了一个本地音乐客户端”“我拿 emacs 听音乐，聊天，订阅 rss 等等”
  • 关于 Emacs vs Vim：“我个人是更喜欢 emacs，vscode 这种以修饰键为主的快捷键绑定”“我把 vim 给换成 edit 了。edit 更简单，而且保持了我用 emacs 的纯度，不被 vim 的模态编辑思想影响”。
  • mg 编辑器：BSD 家的 nano，仅 200k，与 Emacs 按键高度重合，定位“终端里面很好用”，被视为轻量应急备选。
  • 字体回调：Emacs 可以指定非常丰富的字体回调，其他编辑器做不到。
  • 网络配置观察：“vps 这个东西，一定得勤换，反正 ip 能迁移”“vps 第一件事，就是要测试 ip。有的 ip 被污染了，好的 ip 在提问 gpt 都是不需要登陆的，注册 gmail 也容易”。
  • 关于 C++-mode：“我得承认 emacs 的 c、c++-mode 虽然慢但是着色更准确”“c++-mode 应该是在纯正则的时候去传函数然后调用 lisp 函数去扩大上下文了”。
  • 关于群友状态：“最近做的事情太多了，每想到一个 idea 都能实实在在用我的 pi 做出一个东西来。常态就是四五个终端 tab 同时在用 Pi 跑 Deepseek。”
  • 关于国内就业：“国内另外一个歧视就是女性到了适婚年龄还没生孩子的（不管你结没结婚）”“国内人太多了；-（”“我觉得是国内钻空子的人多，利用怀孕钻空子的女性很多，其实是在损害集体女性的利益。”
  • 关于 Arch TTY 字体：“arch 的 tty 里面的字体很好看，就是中文没有什么和他相配的字体”。
  • 黑莓怀旧：“有点想买个黑莓的手机玩玩，以前 bbos 的设备也有个安卓 4.4 的虚拟机，后面也有带键盘的安卓设备”。
  • Termux 吐槽：“上次装 termux 发现很多功能都收费了”“开源咋收费的”“我再看看”（疑似误记）。
  • 荷兰政府基于 NixOS 打造办公系统：群友评价“荷兰人都是神，承载不败的传闻”。

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

  1. excali-mode + excalidraw-dsl（https://github.com/yibie/excali-mode、https://github.com/tyrchen/excalidraw-dsl）：Emacs 内 AI 辅助绘图的 DSL 方向，值得关注其 v0.1.1 的 DSL 支持能力。
  2. simpcpp-mode（https://github.com/zHaOdANiuu/simpcpp-mode）：超大 C++ 文件的秒开着色方案，虽然准确性不如 c++-mode，但性能优势明显，值得深挖其实现思路。
  3. ETAF / APPKit 框架（https://github.com/orgs/emacs-apps）：Emacs 文本应用的两种路线之争，结合 DeepSeek 生成 UI 的能力，可能开辟 Emacs 作为“原生应用平台”的新方向。
  4. ob-mermaid（https://github.com/arnm/ob-mermaid）：Emacs org-babel 的 Mermaid 渲染支持，与 excali-mode 的 DSL 绘图可以形成互补。
  5. chirp fork（https://github.com/emacs-im/chirp）：X（Twitter）网页接口的 Emacs 客户端，避免 API 收费问题。
  6. Hugging Face Pro（https://huggingface.co/pro）：9 美元/月的 GPU + 存储 + Docker Space 组合，性价比极具竞争力，适合 AI 推理和模型微调实验。
  7. 家庭网络反向代理方案：旁路由公网 IP 暴露的解决思路（内网机器网关指向主路由 + 反向代理），可作为自建 NAS 或 HomeLab 的实用配置参考。
  8. DeepSeek 自动链路验证：模型主动用麦克风收音验证协议打通，这种“闭环自动化”能力值得在 IoT 自动化场景中系统化应用。

观点延伸

中心判断：今天群里大半的吐槽，最后都指向同一件事——AI 编程的瓶颈已经从「模型有多强」转移到「脚手架的粒度有多细」。

一、「推倒重来」不是模型的锅，是 harness 的锅

多位群友把额度见底归因于模型降智、额度缩水。但「干完之后发现不行就全部撤回」这个描述，指向的不是模型，而是 agent 循环的设计：它把一次会话当成一个不可分割的事务，失败即整体回滚。人写代码从不这样——人的做法是留下半成品、注释、待办，下次接着改。所以「粗粒度」的准确含义是：harness 不产出中间态。由此有个很硬的推论：把回滚换成检查点，让失败那一步的 diff、日志、失败原因变成下一轮的输入，同样的额度就能换到更多有效信息。这类改动不依赖任何模型升级，是今天就能动手的工程量。

二、额度是推理预算，不是订阅费

按倍率换算（Plus 1X / Pro 100 5X / Pro 200 10X）再把重置卡挂上到期时间之后，用户的真实决策变量变成了「每个任务的边际成本」。这解释了为什么同一天里同时出现「立刻蹬完手动刷新」和「额度是真的降了很多」两种反应：前者把它当会贬值的资产，后者把它当生产效率。更值得警惕的是多车道并行——一个模型出 spec、另一个实现、第三个 review：收益随车道数上升，成本却随轮次非线性上升，因为每一轮上下文都要重付一遍。所以「用 DeepSeek 做主力」的真正优势不只是便宜，而是便宜到让「多轮试错」重新变回默认选项。

三、把操作变成 DSL，是把人的隐性知识变成 AI 的可生成物

excali-mode 新版加上 DSL 支持、excalidraw-dsl 被拿出来讨论，和 ETAF / APPKit 的路线之争，其实是同一问题的两面：人类操作里那些「讲不清的部分」（图形拖到哪、按钮按什么顺序），能不能被结构化成机器可生成、可验证的形式。DSL 路线的优势在于它天然可 diff、可 review、可被一次生成。而单 buffer / 多 buffer 的分歧，本质是「状态放在哪里」：ETAF 把状态聚合成一个前端式应用，APPKit 把它拆成一组各司其职的 buffer。纯键盘、触屏、鼠标三种输入的兼容性会决定哪条路线更长久——因为「可交互元素」必须先被显式枚举出来，Vimium 式的单字母跳转才有东西可跳。

可继续研究的方向：挑一个自己高频的任务（画架构图、或让 agent 改一段代码），在它前后各加一层——前面写一个最小 DSL 或 spec 结构，后面加一个「失败也留档」的检查点机制——然后量一下同一个模型在同样额度下的有效产出差多少。这个话题的价值就在于：它不靠等新模型。