Geekinney

外观

Emacs 社区日报 2026-08-27

约 5651 字大约 19 分钟

2026-08-27

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

Emacs 社区日报 2026-08-27 手绘图
Emacs 社区日报 2026-08-27 手绘图

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：Windows 下 Emacs 的中文路径与编码难题

这是群内持续时间最长、讨论最深入的议题。起因是 zdn 在 Windows 上用 Emacs 31.1 时，尝试通过 make-empty-file 创建带中文路径的文件（如 ~/.emacs.d/测试/a.js）失败，报错 file-missing: No such file or directory，但同样的配置在 Linux 上完全正常。随后他做了一系列排查：

  • 外部 ls 与 ls-lisp 的取舍：Emacs 默认在 Windows 上用 ls-lisp 实现 dired，但为了支持符号链接，他改用外部 ls（coreutils），结果遇到编码问题——外部 ls 需要 --dired 选项配合 Emacs 返回文件名范围，但 Windows 下的编码处理（尤其中文）会出现乱码或文件创建失败。
  • 修改 coding-system 后引发新问题：即使调整编码，find-file 反而无法识别中文字符串，甚至导致无法创建文件。
  • 版本差异：在 Emacs 32.0.50 (master) 上复现不出此问题，而 31.1 则必现，推测是 31.1 的回归 bug。zdn 自嘲“将成为 emacs31 一生之黑”，并计划提交 bug 报告。

群友也给出了各种建议：

  • 有人建议直接用 ls-lisp，或者干脆改操作系统（换 Linux/WSL）。
  • 关于 WSL 的讨论：有群友指出 WSL 不是原生体验（配置重复、老机器装不上、mpv 无图形界面），但也有群友提到在 WSLg 下跑 Emacs 有高分屏缩放模糊问题，所以高分屏用户最好直接上 Linux 或 macOS。
  • 底层原理：有群友提到 Windows 的 C 运行时基本是 Windows API 的封装，早期 API 没有 w 前缀（如 wfopen），所以文件名编码问题一直存在，这是历史技术债。

这个专题揭示了 Windows 作为 Emacs 运行环境的“二等公民”处境，尤其是中文文件名、外部工具链与 Emacs 内置 Lisp 实现之间的摩擦。

专题：Emacs 内嵌终端与 Agent 的使用方式

由一位群友提问“emacs + 很多 agent 大家都咋玩的？”引发。核心观点是：Emacs 与 Agent 的集成并没有一个名为“emacs + agent”的特殊概念，区别只在于“在哪里打开 Agent”——是在终端模拟器里，还是 Emacs 内部的终端 buffer（如 vterm、eshell）。

  • 最简单直接的方式是 Emacs 内开一个终端，运行 herdr 等 CLI Agent。
  • 也有人推荐 ghostel（一个 Emacs 与 Agent 集成的包），效果比终端要好，且支持 ACP（Agent Client Protocol）原理。群友 κόσμος 提到“ghostel 的效果要好不少”，还可以用 agent-shell 等其他集成包，不一定非要用终端。
  • 有人尝试 emacs-libgterm（https://github.com/rwc9u/emacs-libgterm），但认为总会有小毛病。
  • 关于 ghostel 的配置，有人提到可以给它配置类似 herdr 的提醒，并通过 consult 浏览 ghostel buffer，体验会更流畅。

总体上，群友们认为这种集成更多是“终端工作流的迁移”，而非 Emacs 赋予了 Agent 额外的能力。值得关注的是 ghostel 这个新兴包，可能会成为 Emacs 生态中 Agent 集成的关键组件。

🔑 关键概念与技术解析

  • Unicode 代理对（Surrogate Pairs）：zdn 提到 JavaScript 的 slice、charAt 等 API 在处理 Unicode 字符时，如果码点超过 0xFFFF（65536），字符串长度就不是 1。这是因为 JavaScript 字符串基于 UTF-16，码点超过 BMP 区需要使用代理对（两个 UTF-16 单元），所以 charAt 会返回单个代理单元而不是完整字符。这是历史上 Unicode 从 16 位定长标准扩展到 21 位的“背刺”之一。
  • --dired 选项：GNU coreutils 的 ls 命令为 Emacs 专门提供的选项，用于输出附带文件名范围信息，方便 dired 模式精确定位文件名（尤其处理特殊字符）。这是外部 ls 能在 Emacs 中正确工作的关键，Windows 下的外部 ls 若无此支持则无法替代内置的 ls-lisp。
  • ACP（Agent Client Protocol）：用于 Emacs 与 AI Agent 通信的协议，ghostel 基于此实现集成，允许 Emacs 内嵌 Agent 的交互界面，替代传统终端方案。
  • Preedit（输入法预编辑）：在终端或图形界面中，输入法打码过程中的临时候选/预编辑文字。群友遇到“输入法看起来有点毛病”，κόσμος 建议“关掉 inline preedit”，即禁用行内预编辑，以避免渲染冲突。

💎 碎片知识与金句拾遗

  • 千问自称 Gemini 的逸闻：有人吐槽“千问骗人，说自己说 gemini”，随后群友指出这并非故意“蒸馏”或灌输身份，而是因为让模型记住自己是谁会降低模型质量，所以一般不会这么做。如果模型没有明确身份信息，它会“猜一个”，历史上出现过 GPT/Claude 自称 DeepSeek 的笑话。这揭示了 LLM 身份设定的设计取舍。
  • 最小 PNG 的手写经验：zdn 展示了自己以前写的“最小 PNG”文件，用 Unicode 转义写二进制（如 \u0089PNG\r\n\x1A\n），并提到曾手写 PNG 解析器、写了大量脚本小工具。这展示了硬核开发者的业余爱好。
  • Windows 编码的历史债：有群友提到“以前 Unicode 就是 16 位定长，微软设计 Windows NT 时 API 全面 Unicode 化，不想后来被 Unicode 标准背刺了”。这个评论精准概括了 Windows 编码混乱的根源——早期 API 的 A（ANSI）后缀版本成了遗留问题，连 wfopen 等都是后来补上的。
  • Emacs 邮件客户端联系人补全：有人问“现在的 emacs 邮件客户端有支持联系人补全的吗？”，群友 φuzy 回答“有的吧，好像叫 ecomplete”，并提到是本地的补全。这是一个具体但实用的 Emacs 细节。
  • 公司纸多的调侃：在讨论 WSL 配置时，有人幽默地说“公司就是这点好，纸多😂”，暗指打印配置文档方便。
  • UCRT 的猜想：有人提到“还没有试试 UCRT 对 win 上编码有什么影响”，UCRT（Universal C Runtime）是 Windows 的 C 运行时替代方案，未来可能改善编码处理。

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

  • ghostel 包：一个新兴的 Emacs Agent 集成包，基于 ACP 协议，群友评价“效果比终端好不少”。值得研究其架构、与 agent-shell 等其他方案的对比，以及如何与 consult、herdr 等工具协同。
  • Emacs 31.1 的 Windows 中文路径 bug：zdn 已准备提交 bug report，这是一个明确的回归问题（在 master 上没有），值得追踪修复进展。如果读者使用 Windows + 中文文件名，需要格外小心。
  • UCRT 对 Emacs/Windows 编码的影响：群友提出但尚未测试，这是一个潜在的改进方向——现代 Windows 的 UCRT 是否解决了 ANSI API 的遗留问题，值得实验验证。
  • 最小 PNG 实现：zdn 提到的手写 PNG 解析器/生成器是一个极客向的开源项目灵感，可以深入研究 PNG 二进制格式，尤其是如何用 Unicode 转义在脚本中直接写二进制数据。

注：今日有效讨论较多，以上内容已按主题整合。部分闲聊（如“为什么时间这么多”）已忽略，但保留了“公司纸多”等有上下文趣味的碎片。

观点延伸

中心判断：今天最值得咀嚼的，不是“Windows 该不该用”或“Emacs 里该不该跑 Agent”，而是两个问题都指向同一件事——真正决定工作流可靠性的，是边界是否清楚、失败是否可观察，而不是工具表面上是否“集成”在一起。

1. 不要把版本回归误判成个人配置问题

make-empty-file 创建中文路径失败，且在 emacs -Q 下仍可复现；换到 30.2 或 master 后现象不同。这已经足够把排查重点从“是不是我的配置写坏了”移到“31.1 在 Windows 文件名处理链路上改变了什么”。

更关键的是，问题并非单点编码错误：外部 ls 需要 --dired 提供文件名范围，Windows 又涉及运行时编码，修改 coding-system 后还可能让 find-file 不再理解中文字符串。也就是说，故障发生在 Emacs Lisp、外部命令、C 运行时和文件系统的交界处。此时用一个全局编码设置“压过去”，很可能只是把错误从创建文件转移到查找文件。

工程上更稳的做法，是保留最小复现：固定版本、-Q、中文路径、外部 ls 与 ls-lisp 两条路径，逐项记录结果。能把边界条件写清楚，才有可能形成可合并的 bug report，而不是一句“Windows 乱码”。

2. Emacs 集成 Agent 的价值，在反馈回路而不在窗口位置

群里那句“没有 Emacs + Agent 这个概念”其实很准确：把 CLI Agent 放进终端模拟器，首先只是改变了启动位置。真正产生价值的，是 Agent 输出之后能否快速回到文件、diff、测试和下一轮指令。让 Agent 写文档时仍然要看文件，恰好说明“完全不看”不是自动化，而是放弃验证。

因此，ghostel、agent-shell 或基于 ACP 的方案，评价标准不应是“看起来比终端漂亮”，而应是：状态是否清楚、输出是否可检索、失败能否恢复、人工审阅是否更顺畅。consult 浏览 Agent buffer 的想法有价值，因为它把一次性对话变成了可定位的工作记录；但 ACP 功能不全、输入法 inline preedit 等小毛病也提醒我们：协议层增加了结构，同时也增加了新的故障边界。

3. 可继续研究/实践

做两组对照实验：一组测试 Emacs 30.2、31.1、master 在 Windows 中文路径上的行为；另一组用同一个小任务比较 vterm、ghostel 和 agent-shell，记录“生成—看 diff—运行测试—继续指令”各环节耗时与失败点。最后选择的，不应是最像“原生集成”的方案，而是最容易发现错误、纠正错误的方案。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：AI 时代，程序员还有没有价值？

这是今日讨论最激烈的主题。起因是群内提到某论坛上“懒猫”（某赞助人）宣称“Emacs 在 AI 时代没有价值了”，随后引发了一场横跨数小时、多方参与的激烈辩论。核心观点分两派：

“程序员无价值论”派：认为写代码这件事本身将被 AI 取代，程序员角色转变为“产品经理”，只需打磨产品，代码交由 AI 生成。有人甚至直言“我都认为程序员没啥价值了，做什么只需要让 ai 去做”。

反方观点（占据上风）：强调底层知识与对实现细节的掌控不可替代。有人举了亲身例子：开发 iOS app 时，原生 tab 默认没有二级菜单，但 Telegram 有，自己知道实现方式、AI 却搞了两天都没搞出来；又有人指出 AI 改代码“直接改坏，而且修复不了那种”，其输出“极度脏、没人能接手、哪怕是大模型自己”。群友 @一位成员 的总结颇为精辟：“你就当它写的东西都是加过混淆的就行了”——AI 代码读得懂但改不动，且腐化速度快于人类。

更有群友从宏观趋势上泼了冷水：“顶再过一年可能都不要，一些被裁的人就会被联系返岗”、“泡沫太大”。但也有人回应“知识不会过时，过时的是程序员”，以及“没有一些底层的知识，我就做不了相关产品啊”。

最终讨论的落点是：AI 作为“快速孵化想法”的助手确实好用（尤其是 UI 设计、音频转文字、快速原型），但“让代码库不变成屎山的能力”反而成为人类程序员的核心竞争力。这一话题与后续关于模型订阅、编程工具的讨论构成了完整闭环。

专题二：终端模拟器之争——从 mouse-first 到 terminfo.dev

由一条 Reddit 帖子引发，讨论者吐槽 TUI（Terminal User Interface）越来越倾向“mouse first”，不理解为终端还要用鼠标操作。由此开启了终端模拟器的大对比：

  • 力荐 Ghostty 的有：多位群友从 iTerm2 切换到 Ghostty，反馈“流畅”“macOS 上全面转了，目前还算舒服”，也有人顺便从 tmux 切到了 herdr。
  • 老派 iTerm2 用户仍在观望，但被吐槽“真的慢，会卡”“卖力但领榜的是 benchmark 不是体验”。
  • foot 被点名“wayland 特供”，但有人跑 terminfo.dev 测试得到 99% 的成绩（被回怼“脚本太老了”）。
  • 有人分享了 terminfo.dev 对比站，群友跑分结果各执一词，最后发现网页显示 254 项测试但 npm 发布的版本还是几个月前的只有 111 项，测试公平性存疑。

最终落点：macOS 用户转向 Ghostty 趋势明显，Linux 下 Kitty/foot 仍是主力。

专题三：代理工具选型——sing-box 与“刘大爷”

群友讨论 iOS 代理工具，有人吐槽 sing-box 不支持解析地址提取节点，于是开始对比：

  • 有人力挺 Loon：“iOS 小火箭 qx loon 我都买了，loon 好用”“还能屏蔽开屏广告”；也有人反对 QX “好些协议不支持”。
  • sing-box 支持者反驳：“配置写一次在手机电脑路由器都能用”，换成 Loon 是折腾成本。
  • 某群友抛出金句：“时间成本，折腾精力的成本……送给刘大爷就是稳定，稳定就是生产力，生产力就是不用 singbox，闭环”——这里的“刘大爷”指 Quantumult X 的作者，群友调侃与其折腾不如付费买稳定。
  • 也有人推荐 Surge“上车”，但核心观点是 Loon 在性价比、广告屏蔽、协议支持上胜出。

🔑 关键概念与技术解析

  1. VMP（VMProtect）加壳：一种软件保护技术，将代码虚拟化，使静态分析困难。群内有人求助“脱壳 vmp 软件”，回复称“除非是魔改版都有几乎一键脱”，说明现代社区已有成熟的自动化脱壳方案。
  2. Datalog：一种基于逻辑的声明式查询语言，常用于图数据库/知识库。群友讨论用它来做结构化笔记（状态机+依赖关系），并提及 datalevin 和 datahike 两个 Clojure 生态的 Datalog 实现。
  3. steel：Helix 编辑器的插件语言，基于 Scheme。群友认为它是 Helix 插件生态中“比较容易活下来”的那个，关键是“maintainer 给不给 steel 让路”——如果“把控制整个编辑器的能力交给 steel”，潜力巨大。
  4. True multi-threaded Elisp / neomacs：Emacs 的 Lisp（Elisp）虚拟机不支持并行，群友调侃吐槽，并提及 neomacs 作为 Emacs 的并发替代方案。
  5. Sub-Store：代理工具之间的订阅转换/节点解析中间件，群友提到 Loon/QX 支持 Sub-Store 即可解析订阅。
  6. SEMA 语言：一种新编程语言，无原生代码生成（性能堪忧），但语法可读性比 TypeScript 直观，且“编辑器支持有点逆天了”。群友总体态度是不看好。

💎 碎片知识与金句拾遗

  • “尼泊尔边境冰崩泥石流”新闻事件：群友转发并感叹“为啥要在这种山沟沟里建设什么口岸”，另一人解释是“和尼泊尔的交接处，我们以前的货物还通过这里去尼泊尔”，并补充“维护口岸有不到二百人，每天通过口岸的大概有 1500 人左右”。也有调侃“感觉整个喜马拉雅山脉都归我们中国才有办法治理泥石流”。
  • 13 岁女生开发 100+ apps 接单：群友评价“口气好狂，读书是为了找工作，那我为什么不直接开始”，另一人冷回“炒作，喜欢造神童”。
  • 旅行者一号内存修复：有人分享 NASA 修复旅行者一号的故事——内存坏了一块后“剩下的内存都是小而且分散的”，团队“把程序重写，利用分散的内存恢复了程序运行”。被群友用作“内存贵倒逼程序扣内存”的极端案例。
  • Neovim 的 setup 函数起源：群友科普，当年 neovim 从 vimscript 切到 Lua 时，“几乎一个版本周期里面所有插件都换成了 Lua”，但当时留下的坑——插件得调 setup 函数才能用——早已被 lazy 等替代，但“已经习惯 setup 了”成为集体习惯。有人感叹“甚至很多人不知道这个习惯怎么来的”。
  • Emacs 币圈大佬金句：“以前 emacs 圈的币圈大佬还说过投资都没有挖矿赚的多，为什么要投资”。
  • 腾讯会议吐槽：群友抱怨“一满 5 人限制会议 40 分钟”“上次开个会重开了两次”，另一人补充“商用的发热也严重，iPhone 16 以及 macOS m3 max 都会发热”。
  • AI 生成代码的比喻：“你就当它写的东西都是加过混淆的就行了”。
  • chat.openai.com 可以用：群友在讨论 token 流量耗尽后指出网页版可用，有人回应“网页版越来越好用了，会到历史会话里找信息”。
  • Tibo 的“重置”：有人转发 Tibo 的新帖“变老的一个好处是……20 年没有按下重置键了”，群友推测“上次的那个重置有可能不是 Tibo 按的”，计划“今天得狠狠蹬”——指骑车发电。
  • 景天 LaTeX 梗：有人分享 GitHub 项目 my-girlfriend-jingtian-latex，群友回复“孙割走心了”“这是什么梗？景甜”。

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

  1. steel 语言在 Helix 中的生态：群友对 Helix 插件体系寄予厚望，认为 steel 能否拿到控制编辑器的能力将决定其命运，值得追踪。
  2. Datalog 结构化笔记方案：群友尝试用 Datalog（datalevin/datahike）管理逆向笔记，需要多机同步，尚属探索阶段——如果你对结构化知识管理感兴趣，可以跟进这个方案。
  3. terminfo.dev 基准测试：网页和 npm 发布版本不一致（254 vs 111 项），测试公平性有争议，但这个工具本身是有价值的终端性能对比框架。
  4. 免费 API 服务 free.empero.org：德国实验室挂出的免费模型 API（Qwen3.8-Flash-Next），声称不限 token——这算是一个“白嫖”信号，值得测试其稳定性和真实性能。
  5. 英伟达收购 HuggingFace 的小道消息：群内只一句带过，但若属实将是 AI 基础设施领域的大事，值得持续关注。

以上整理自 2026-08-27 群聊记录，共 354 条消息。核心热点集中在 AI 对程序员价值的讨论与终端工具链的选型对比，专业度较高，值得长期关注。

观点延伸

中心判断：当天关于“AI 时代程序员还有没有价值”的争论，真正触及的不是 AI 能不能写代码，而是谁能把生成结果纳入一个可解释、可测试、可接手的系统。能运行只是演示成功；能够持续修改、定位回归并交给别人维护，才是工程产出。

1. 人的价值正在从“实现功能”转向“控制边界”

群里提到的 iOS 例子很典型：原生 tab 没有二级菜单，AI 在不知道实现路径时折腾了两天；另一个例子是只调整触发区域，却把原本正常的功能改坏，而且无法修复。这暴露出需求中大量未写出的约束：平台默认行为、状态转移、交互边界，以及哪些旧行为绝对不能动。

因此，人的核心能力不是亲手写完每一行，而是选择合适的表示方式，定义不变量，限制修改范围，并知道错误发生后该回滚哪一层。“让 AI 先抽象”也不是免死金牌；抽象必须落到现有行为、接口、测试和最小变更上。凡是涉及状态、交互触发或跨端差异的修改，都应要求变更说明、回归用例和可撤销节点，否则所谓成功只是把维护债务延期。

2. “代码像加过混淆”可以变成维护指标

这句群聊金句的锋利之处在于：代码未必不可读，却可能不可修改。评估 Agent 不应只看第一次生成是否通过，还要看第二次需求进来后，它能否在新上下文中定位影响面、少改文件、保住旧测试，并让其他人接手。

可以实际记录修复耗时、回归次数、变更文件数和人工重写比例。如果这些指标持续恶化，模型带来的就是腐化，而不是生产力。Emacs 的价值也不只是编辑器本身，而是让人继续掌握文本、命令、反馈和工作流的组合控制权。

3. 结构化笔记是 Agent 的长期控制面

晚上关于 Org、平铺目录、双链和 Datalog 的讨论，与前面的代码问题其实同构：目录方便人找文件，却未必表达依赖；平铺便于链接，却可能让 Agent 缺少结构。服务于逆向和持续开发的最小笔记单位，不应只是文章，而应包括实体、状态、依赖、证据和下一步动作。Datalog 可以作为查询层，但不应先于数据模型；多机同步、部署成本和查询语义差异，都必须通过实践验证。

可继续研究/实践

选一个小型 App 或逆向项目，让 Agent 连续工作两周，每次只接受小范围变更；用 Org 或 Datalog 记录假设、证据、状态与依赖，同时统计修复耗时、回归次数和重写比例。最后比较的不是“生成了多少代码”，而是“系统能否持续演化”。