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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：Emacs 中的交互式编译痛点与 C++ 缓冲问题

群友 zdn 提出了一个经典的开发环境问题：在 Emacs 的 compile 命令中运行 C++ 程序，使用 '\n' 作为换行符无法即时显示输出，必须刷新缓冲区（如使用 std::endl 或程序结束）才能在 *compilation* 缓冲中看到内容。

核心讨论点与解决方案：

• 问题根因：与 C/C++ 标准库的缓冲策略有关。当标准输出未连接到交互式终端（如 Emacs 的 compile 进程创建的管道）时，默认是全缓冲而非行缓冲，导致 '\n' 不会触发 flush。
• 语言层面的解决方案：
  • C++ 方式：手动设置流为无缓冲模式：std::cout.setf(std::ios::unitbuf);
  • C 方式：使用 std::setvbuf(stdout, nullptr, _IOLBF, 0); 显式设置为行缓冲。
  • C++23：群友建议直接更换为 std::println()，但其内部仍可能有缓冲，并非根本解决方案。
• Emacs 层面的探索：
  • zdn 的初衷是在 Emacs 层面彻底解决此问题，避免每次都要修改 C++ 代码。他怀疑问题在于 compile 使用了 start-process 创建伪终端（PTY）与进程通信，导致程序认为自己并非连接到一个真实的终端。
  • 他尝试了 C-u M-x compile，希望改变其行为，但未详细说明效果。这通常意味着 Emacs 的问题在于它模拟终端的方式，而程序的内置缓冲策略无法被轻易“欺骗”。最终 zdn 决定求助于 AI 扫描 compile 的源码，这是一次从工具使用深入到源码级问题排查的尝试。

探讨：多语言混排下的拼写检查策略 (jinx)

围绕 Emacs 的现代拼写检查包 jinx，群友们讨论了如何处理中英文混排的文档。

• 痛点：对中文进行拼写检查（Spell Check）既无必要，也因中文分词复杂性而性能低下。
• 解决方案：大多数用户选择在配置中完全禁用对中文字符的检查，方法是在 jinx-exclude-regexps 中添加匹配中文的正则表达式 "\\cc"。
  • 用户分享的配置片段：

    (add-to-list 'jinx-exclude-regexps '(t "\\cc"))

  这一方法简单粗暴，但极为有效，是讨论中公认的最佳实践。另有建议在中英文之间手动或自动添加空格来规避此问题。

前瞻：轻量化编辑器 Lem 的现状与挑战

讨论转向 Emacs 的一个现代替代品——Lem。

• 优势 (Pros)：使用 Common Lisp 编写，性能更好，天然多线程，更积极地拥抱 AI（内置 Copilot 等支持），开发团队更加开放。
• 劣势与当前状态 (Cons & Status)：
  • 平台兼容性：在 Windows 上的支持较差，用户反馈打包好的版本和 Nightly Build 都可能跑不起来，维护者建议使用 WSL。
  • 功能完备性：其 legit（Git 客户端）和 Org Mode 等功能是存在的，但远不如 Emacs 中的成熟和完整。有用户表示，若不重度依赖 Org Mode 和 magit，Lem 已可替代 Emacs，仅缺 winner-mode 和拼写检查等少数功能。
• 结论：群友普遍认为 Lem 是一个值得关注但需要“让子弹飞一会儿”的项目，目前还不是 Emacs 的完全替代品。

🔑 关键概念与技术解析

• std::setvbuf (C/C++ 缓冲控制)：一个 C 运行时库函数，用于显式控制文件流的缓冲类型（全缓冲、行缓冲、无缓冲）。在本讨论中，用于解决 Emacs compile 进程下 C++ 程序输出的刷新问题。
• jinx：Emacs 的一个新生代拼写检查前端，设计上比 flyspell 等老牌方案更现代、性能更好。其底层默认使用 enchant 后端。
• Lem：一个用 Common Lisp 编写的编辑器，其设计理念、键绑定和操作模式（如 mode）高度仿照 Emacs，旨在于提供类似体验的同时，获得更好的性能和更现代化的语言特性（如命名空间、多线程）。不应被视为 Emacs 的分支或克隆。
• MSVC ABI 稳定性：zdn 提到的一个观点，即 Windows 平台上微软的 C++ 编译器（MSVC）的应用程序二进制接口（ABI）异常稳定，只要是用 MSVC 编译的库，在跨版本链接时极少出现 ABI 不兼容而导致的崩溃问题，这与 MinGW 等环境形成鲜明对比。
• goto-address-mode：一个 Emacs 内置的次要模式，它能将缓冲区内的 URL 和电子邮件地址转换为可点击的链接。zdn 在测试中发现其在 C++ 模式下会误将 info:xxx 格式的代码（如 INPUT_KEY_INFO::~INPUT_KEY_INFO()）解析为 HTTP 链接，这被判断为其正则匹配规则存在缺陷。
• 形码输入法（虎码/五笔/宇浩/仓颉）：一种基于汉字字形结构的输入法，与拼音不同。群内提及虎码、86版五笔、宇浩和仓颉等多种方案，讨论了在 AI 时代形码“一字一空格”的击键成本和学习成本。

💎 碎片知识与金句拾遗

• “win11的ui藏着win10，win10的ui藏着win7，win7的ui藏着xp” —— 群友对 Windows 用户界面多重历史遗留问题的一种生动调侃，揭示了其深厚的“向下兼容”导致的屎山代码。
• “gnu项目还有个目的是开源学习精神吧”，“gnu反正说是捍卫人类手工” —— 探讨了 GNU 项目部分成员对 AI 持保守态度的哲学根源，认为其核心在精神传承而非开发效率。
• “说真的，人写的代码不也是bug满天飞么” —— 对“AI 代码质量不高”这一批评的有力反驳，指出在没有良好工程规范的情况下，人类产出“屎山”的概率同样很高。
• “他们拥抱ai，不像Emacs开发组” —— 直观对比了 Lem 和 Emacs 两代编辑器社区对新兴技术的态度差异。
• C++23 std::println：群友顺带提及的一个 C++23 新特性，旨在让打印文本变得更便捷，但在此场景下仍可能受限于 I/O 机制。
• Colorful-mode：zdn 分享了 https://emacs-china.org/t/colorful-mode/31819，这是一个为 Emacs 提供更丰富色彩支持的模式。
• indent-bars：Aiser 推荐了一个能在 Emacs 中显示缩进线的插件 indent-bars，并确认其在 Windows 上也可用，视觉体验不错。
• Magit 性能优化经验：zdn 分享了他通过 AI 分析 Magit 源码，修改并禁用在打开时自动对比文件内容的功能，从而大幅提升启动速度的骚操作，并提供了其配置链接 https://github.com/zHaOdANiuu/.emacs.d/blob/main/lisp/init-vc.el。
• pizauth (OAuth2 工具)：用于在 Linux 等系统中获取 Gmail 的 OAuth2 Token，以配合 Emacs 的 smtpmail 等工具在不使用应用专用密码的情况下发送邮件。详细的配置代码片段被分享了出来。

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

1. Lem 在 Windows 下的构建与调试：虽然官方支持不佳，但社区有尝试修复的 PR (lem-project/lem#2261)，这是一个在 Windows 上获得高性能 Common Lisp 编辑器体验的潜力点。
2. 基于 libgit2 的 Emacs Git 客户端：讨论中数次提及，为了解决 magit 跨平台（特别是 Windows）性能的根本性方案是将 Git 操作从调用进程迁移到使用 libgit2 库。Zed 编辑器的实现效果被引为正面案例。这是一个可以改变 Emacs Git 体验的深远方向。
3. goto-address-mode 的正则表达式缺陷：zdn 发现的在 C++ 代码中将 info:xxx 误识别为链接的 Bug，是一个不错的、低门槛的 Emacs 贡献机会，可以尝试修复其匹配规则。
4. Emacs pdump 技术的前景：群聊中被重新提起的 pdump 技术，旨在通过转储 Emacs 运行时状态来显著加速启动，有人提问“现在还有人在折腾吗”，表明这个技术虽有潜力但可能未达预期或已不是当前焦点。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是某个包怎么配，而是一个更硬的判断：Emacs 的很多“慢”和“怪”，已经不是调参问题，而是边界建模问题。谁在模拟终端、谁在调用进程、谁在维护兼容性、谁在决定工具链边界，这些问题不解决，用户只能在配置层不断打补丁。

1. compile 的缓冲问题，本质是“工具边界泄漏”

std::cout << '\n' 在终端里像行缓冲，在 compile 里却要等 flush 或进程结束，这不是 C++ 新旧语法能解决的。群里提到 std::println() 无效、std::cout.setf(std::ios::unitbuf) 有效，说明问题不在“打印 API 是否现代”，而在程序观察到的运行环境变了：终端、管道、PTY、Emacs process filter，每一层都可能改变缓冲策略。

工程上这类问题最危险，因为用户以为自己在调 Emacs，实际上已经跨到了 C/C++ runtime、OS I/O、Emacs process 模型三层。可验证的判断是：如果不改被运行程序，只想在 Emacs 层解决，就必须验证 compile 到底是否分配 PTY、子进程看到的 stdout 是否是 tty、以及不同平台下 Emacs process backend 的行为差异。否则“换 println”只是语法层安慰剂。

2. Magit 在 Windows 慢，暴露的是“进程调用型架构”的上限

Magit 打开时多次调用 git、Windows 上每个后台命令都是独立 process、没有共享上下文，这些聊天里的观察，比“Windows 卡”更有信息量。它指向一个结构性约束：当交互式 UI 建在大量短生命周期 CLI 调用之上，Unix 上还能靠 fork/exec 成本和文件系统模型撑住，Windows 上就会被进程启动成本放大。

所以 libgit2 不是“优化技巧”，而是架构边界重画：把 Git 从外部命令变成进程内库调用。代价也明确：Magit 多年积累的行为、边角语义、兼容 Git CLI 的能力，不会免费迁移。工程判断很简单：如果目标是“打开快一点”，可以像群友那样禁用昂贵 diff；如果目标是“Windows 上体验根治”，就绕不开后端模型重写。

3. Lem 的张力不在“能不能替代 Emacs”，而在“是否敢重新分层”

Lem 被讨论为 Common Lisp、多线程、内置 Copilot/Claude Code、速度快；同时 Org、legit、Windows 包等还不成熟。这说明它真正的价值不是立刻替代 Emacs，而是给出一个反事实实验：如果今天重新做一个 Emacs-like 系统，哪些历史包袱可以不背？

但这也提醒我们，编辑器不是内核快就赢。Emacs 的护城河是 Org、Magit、Dired、生态协议和用户私有工作流。Lem 的可验证路径不是喊“现代”，而是挑几个高摩擦场景打穿：Windows Git 操作、AI Agent 集成、LSP 多线程响应、Org-like 知识系统互操作。打穿一个，才算真正证明新分层有意义。

可继续实践的方向

选一个小而硬的切口做实验：用同一个 C++ 程序分别在终端、compile、C-u M-x compile、自定义 PTY process 中运行，记录 isatty(stdout)、刷新时机和 Emacs 版本/平台差异。这个实验比继续争论“是不是 bug”更有价值：它能把感觉问题变成可复现的边界说明，也可能直接产出一份高质量 Emacs bug report。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题：算力焦虑与 AI 编程工具链博弈

今日群聊的核心矛盾集中在开发者对 AI 工具额度的焦虑以及对多模型组合方案的探索上。

• 额度焦虑与黑产生态：大量成员频繁抱怨 ChatGPT/Codex 的“重置”(reset) 未能按时到来，导致无法进行开发（所谓“没有 vibe coding 像戒毒”）。这种焦虑催生了对各种灰色渠道的讨论，如“玻利维亚低价区订阅”（因汇率导致 Plus 仅需 85 元）和“黑商渠道”，但迅速指出玻利维亚 Google 支付已被封禁，黑产市场变化极快。
• 工具链容错与流派分流：群内形成了明显的工具选择分化：
  • Cursor/AMP 流派：多模型用户倾向于使用 Cursor 或 AMP，看重其在 Grok 和 Composer 上的“独立池子”，但吐槽 Cursor 20 刀订阅中其他模型按 API 计价极易耗尽。
  • 网页 + CLI 流派：有成员提出用 网页版 ChatGPT Pro 做项目 Review（猛夸其解读压缩包速度快且可靠），再用 Codex 负责开发的配合模式，认为这是在当前限制下的最优解。
  • 逆向工程特化：多位成员指出 Grok 在执行逆向工程任务上比 Sonnet 好用，但在写代码的稳定性上（如处理括号）仍有上下限波动。
• 国内模型信任度：针对“为何国内说赶超但程序员仍用 Claude”的嘲讽，群内观点一针见血——程序员是真正拿 AI 产出干活的人群，国内模型的不稳定性是主要短板，且 K3 的算力规模与 OpenAI 差距惊人，200 元档订阅额度严重不足。

🔑 关键概念与技术解析

• Neomacs：在 Emacs 社区被寄予厚望的新世代编辑器/配置框架，基于 Rust 开发，目标是实现 WebAssembly 级别的网页嵌入，并在视觉上做到比 Neovim 更酷炫。
• Telega：Emacs 下的 Telegram 客户端。今日群内有大量实时的配置解惑与体验分享，被评价为界面体验甚至超越原生 Telegram 客户端。关键配置在于利用 cape 和 corfu 实现联系人补全。
• Hunk：一种新的 AI 代码审查与交互概念。通过在 AI diff 上直接维护 Session 并写 Comment，允许 Agent 通过 Skill 读取这些 Comment，从而实现对代码修改的细粒度控制。
• AMP：由 Sourcegraph 团队推出的 AI 编程工具（群内有成员是先知道 AMP 才知道 Sourcegraph 的），特点是组合使用不同模型来增强解决问题的能力，近期推出了好友间额度赠送功能。
• 霞鹜文楷 (LXGW WenKai)：因某条推文引发群友惊奇的字体项目，名字取自“落霞与孤鹜齐飞”。

💎 碎片知识与金句拾遗

• 邓煜的优雅：群友引用邓煜的鼠标充电方式，调侃为"Only Apple can do"，暗示其为一种极致的极客审美。
• 儿童编程教育：凌晨消息提到 B 站有极强的小学生在玩 Emacs，群友调侃“少年强则 Emacs 强”，并建议让他学 Rust 开发 Neomacs。
• Telega 操作速记：C-c C-a 发文字外内容，C-c C-f 发文件，C-c C-v 粘贴图片。选文本按 r 引用。@@ 补全管理员。高亮 Telega 将收发端口转移到了 Emacs，理论上可实现通过 Emacs 控制电脑 Agent Bot。
• 冷酷商业观察：

  “reset 是不可能一直持续的，这种用钱烧流量的方式，总会停的，你看现在 tibo 就不提重置这件事了。” “Cursor 真是个坑货呀，订阅每月 20 刀，居然只能用 Grok 跟 Composer。其他模型都是按 API 定价的，一下子就用光了。”

• ChatGPT 服务中断：晚间出现大规模 503 错误，群内一度怀疑自己的号被封，不久后陆续恢复，但没有补偿重置额度。
• Lem 编辑器劝退：在 Windows 下安装 Lem 失败，被指出其 Makefile 依赖的 qlot 加入了 Windows 无法使用的特性，建议直接使用 WSL2 别浪费时间。

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

• Neomacs 的 WebAssembly 方案：尝试将真实的 Neomacs 编辑器直接嵌入网页，这将彻底改变在线文档与编辑的交互方式。
• Hunk 工作流：尝试建立本地 Agent Session 与 Diff Comment 的双窗口交互逻辑，探索比传统 Chat 更精准的 AI Review 路径。
• Haiku OS 及其生态：聊天中提到的 Half-Life 2 移植展现了 Haiku（BeOS 继任者）的潜在生命力，其与 ARM64/RISC-V 的结合值得关注。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的，不是“哪个模型更便宜”，而是一个更冷的判断：AI 编程工具正在从“模型崇拜”进入“额度、交互面、可控性”的工程化阶段。谁还把问题理解成“Claude / Codex / Grok 谁最强”，谁就已经慢半拍了。

1. 真正稀缺的不是模型，而是稳定可用的工作流

群里反复等 reset、找低价区、讨论黑商、抱怨 503，本质上说明一件事：当 AI 成为生产力工具后，“额度是否可预测”已经和“模型是否聪明”同等重要。

开发者不是在买聊天体验，而是在买连续工作的确定性。今天有人说“没有 vibe coding 像戒毒”，听起来像玩笑，其实很准确：如果你的开发节奏建立在一个随时断粮的外部额度池上，那这不是工作流，而是成瘾式调度。

所以“网页版 ChatGPT Pro 做 Review，Codex 做开发”的分工，比单纯押注某个 CLI 更成熟。它承认了不同入口的能力边界：网页端适合吞压缩包、快速理解全局；CLI 适合落地改代码、跑测试、迭代补丁。可验证的工程判断是：一个 AI 工具链是否靠谱，不看峰值智商，看它在额度耗尽、服务中断、上下文膨胀时，是否还能降级运行。

2. Hunk 这类交互，比“更强模型”更接近下一阶段

群里对 Hunk 的讨论其实比价格战更有含金量：在 AI diff 上直接 comment，让 agent 通过 session / skill 读取这些 comment，这不是 UI 小改，而是在重建人类控制 agent 的粒度。

传统 chat 最大的问题是控制信号太粗：你只能说“这里不对”“改得保守点”，然后模型在整个上下文里猜。Diff comment 则把意图钉在具体 hunk 上，把“反馈”从自然语言瀑布流变成代码结构的一部分。

这和 Emacs 的精神很接近：不是追求一个漂亮入口，而是把编辑、审查、补全、消息收发都变成可组合的 buffer / command / hook。晚上 telega 的讨论也呼应了这一点：Telegram 只是收发器，真正有价值的是把通信端口接进 Emacs 后，能否形成可编程控制面。

3. 国内模型争议的关键不是爱国或合规，而是波动成本

“程序员真的用 AI 干活”这句话非常狠。干活的人不会长期为叙事买单，只会为稳定产出付费。群里对 Kimi、DeepSeek、Grok 的态度都不是意识形态式的，而是非常工程化：额度够不够、括号会不会丢、逆向能不能跑、服务会不会炸。

这给所有模型产品一个简单评测标准：不要只公布 benchmark，要公布长任务稳定性、失败恢复能力、额度耗尽后的降级行为。程序员关心的不是一次回答有多惊艳，而是十轮修改后项目还能不能编译。

可继续实践

可以把今天的讨论落成一个小实验：设计一套“AI 编程工具链容错测试”。同一个真实项目，分别用“网页 Review + CLI 开发”“Cursor/AMP 多模型”“单一 Codex/Grok”三种方式跑 3 小时，记录：有效修改次数、人工回滚次数、额度消耗、服务中断影响、测试通过率。别再争谁更聪明，直接测谁更能交付。