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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：Windows 下 Emacs TUI 中文显示乱码——一场未竟的排查

本次讨论最核心的话题，是 Windows 上 Emacs master 版在 TUI（终端界面）下中文显示异常，而 vim 显示正常。群友进行了多轮排查，但尚未得出结论。

• 症状与初判：有人怀疑是字体文件丢失（"掉盤了吧, 字體文件沒有了"），也有人猜测是字体设置问题。但随后有人指出自己的 Emacs 31 也存在同样问题，说明可能并非 Emacs 版本所致，而是环境或权限层面的问题。
• 排查手段：尝试使用 describe-char 查看字符属性，发现 charset 为 chinese-gbk；有人提醒选择 buffer 的 coding system（但随即自我纠正：那是 charset 不是 encoding）；也有人建议用 set-fontset-font 试验，但发现提问者用的是 TUI，此方案大概率无效。
• 关键线索：GUI 下显示正常，仅 TUI 异常。有人提到 Windows 的 "Beta: Use Unicode UTF-8 for worldwide language" 设置，但被回应"不需要开那个"。提问者还透露，自己为 Emacs 实现的中文输入法支持中，输入的中文会变成 Unicode 转义——这暗示终端编码处理可能存在更深层的断裂。
• 结论：排查陷入僵局，提问者表示"后面研究一下看看吧"。整个讨论呈现出一个典型的疑难杂症排查过程：从表象到细节，从字体到编码，再到系统设置，最终悬而未决。

次要话题：ghostel 终端包与 LLM code 的争议

κόσμος 在讨论中顺带评价了 ghostel 终端包："LLM 味还是挺重的"，存在一些无法理解的行为，但目前人类写的终端包没有比它更好的。他还批评了作者将 send-key 绑定到 C-c C-q 而忽视 C-q quoted-insert 隐喻的做法。随后话题延伸到对 LLM 代码的必然性："这个时代已经没法避开 llm code 了"，并直言"坚持用纯人工旧版的话就等着被骇穿吧"。这反映了开发者对 AI 辅助编程又爱又恨的复杂心态。

---

🔑 关键概念与技术解析

• chinese-gbk charset：describe-char 输出中的字符集标识。GBK 是中文编码标准，此处显示 chinese-gbk 意味着 Emacs 识别该字符为 GBK 编码的中文。但正如群友指出，这是 charset 而非 encoding，二者在 Emacs 的编码体系中有本质区别——charset 决定字符集，encoding 决定字节存储方式，排查时需要区分。
• TUI vs GUI：Terminal User Interface 与 Graphical User Interface。此处 TUI 指 Emacs 运行在终端模拟器中（而非原生 GUI 窗口），其字体渲染依赖终端自身能力，而非 Emacs 内部字体引擎，因此排查路径完全不同。
• Unicode UTF-8 for worldwide language（Beta）：Windows 系统设置中允许将系统区域代码页切换为 UTF-8 的选项。默认情况下 Windows 使用本地语言代码页（如中文系统用 GBK/CP936），这可能导致跨平台编码表现不一致。
• Face patch（emacs-devel）：17:29 提到的 emacs-devel 邮件列表 patch，旨在改善 Emacs face 的显示体验。群友试用后评价"遥遥领先"，并请求 Linux 用户测试 X 相关部分。这属于 Emacs 内核渲染层的改进，对终端用户和 GUI 用户都有感知影响。

---

💎 碎片知识与金句拾遗

• "掉盤了吧, 字體文件沒有了"——对 Windows 字体问题的一种直觉性猜测，简洁而形象。
• "选下buffer coding system... 哦不对，那是charset不是encoding"——一位群友在排查中自我纠正，体现了编码体系辨析的严谨性，也暴露了 Emacs 编码概念的复杂性。
• "这个时代已经没法避开 llm code 了... 坚持用纯人工旧版的话就等着被骇穿吧"——κόσμος 对 LLM 代码的实用主义态度，略带讽刺但极具现实感。
• "一觉醒来天塌了"——提问者在排查无果后的一句感叹，精准描述了配置环境突变的开发者日常。
• "不仅是TUI，还是Windows"——κόσμος 对问题复杂度的一句调侃，点出了终端界面 + 微软平台的双重不确定性。
• "我想随便试一下我给emacs实现的中文输入法支持 发现输入的中文是unicode转义"——提问者无意间透露了一个自研项目：为 Emacs 实现的中文输入法。这一线索值得关注，可能与其 TUI 乱码问题存在直接关联。

---

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

• Emacs-devel Face patch：17:29 提到的 https://lists.gnu.org/archive/html/emacs-devel/2026-10/msg00116.html。该 patch 被认为显著改善 face 显示体验，且需要测试 X 部分。对于关注 Emacs 渲染内核的开发者，这是一个值得跟踪的提案。
• ghostel 终端包：κόσμος 虽批评其 LLM 味重，但承认它是当前人类写的终端包中的最佳选择。其 send-key 绑定到 C-c C-q 的设计决策也引发了对 keybinding 隐喻的讨论。可作为终端工具选型参考。
• 中文输入法支持实现：提问者提到"我给 emacs 实现的中文输入法支持"——这是一个自研项目，若与 TUI 乱码问题交叉，可能揭示 Windows 终端编码处理的独特机制，值得后续关注。

观点延伸

这场排查最值得咀嚼的，不是“Windows 上的 Emacs 又坏了”，而是一个更具体的工程判断：当问题只出现在 TUI、GUI 正常，且 Vim 也正常时，继续围绕 Emacs 字体配置打转，往往是在错误的抽象层里排查。TUI 的显示链路至少经过 Emacs、终端模拟器、Windows 控制台与系统编码环境；describe-char 看到 chinese-gbk，只能说明 Emacs 对字符属性的判断，不能证明字节编码、终端输入输出和最终渲染之间没有断裂。把 charset、encoding、font 三者混为一谈，正是这类问题迟迟无法收敛的原因。

• 先划边界，再谈修复。 GUI 正常意味着 Emacs 的字符内部表示和图形渲染路径大概率没有整体失效；TUI 异常则应优先建立最小对照矩阵：同一份文本分别在 Emacs TUI、普通终端、Vim 中测试，再更换终端、Emacs 版本和启动配置。若自研中文输入法输入后出现 Unicode 转义，还要把“输入链路异常”和“显示链路异常”拆开验证，不能因为它们都表现为中文问题，就默认是同一个根因。

• “我的 Emacs 31 也有问题”是重要证据，但不是结论。 它削弱了“最新 master 引入回归”的假设，却不能直接推出“肯定是权限问题”或“肯定不是 Emacs”。跨版本复现更像是在提示：共享的外部变量可能更值得检查，例如终端类型、启动环境、系统区域设置或输入法适配层。工程上，版本交叉测试的价值不在于马上找到答案，而在于排除错误归因。

• LLM code 的争论其实指向另一种质量标准。 “无法避免”不等于“无需理解”。ghostel 被认为有明显的 LLM 味，却仍被评价为当前较好的选择，说明实际选型看的是可用性、替代品质量和风险边界，而不是代码是否纯人工。真正成熟的 AI 辅助开发，不是拒绝生成代码，也不是接受所有生成结果，而是要求行为可解释、关键路径可测试、异常能够回滚；send-key 与 C-q 隐喻的争议，恰好说明接口设计中的语义一致性不能靠功能跑通来替代。

可继续研究的方向，是把这次问题整理成一份最小可复现实验：固定文本、输入方式、终端、Emacs 构建和环境变量，分别记录字符属性、编码转换和终端输出。这样无论最终归因于 Windows、TUI、输入法还是 Emacs，本次“疑难杂症”都能沉淀为下一次可自动验证的回归测试。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题：JetBrains 财报风波 —— 如何解读"亏损"背后的真实情况

群内围绕 JetBrains 财报信息展开了较为深入的讨论，核心关注点在于：JetBrains 的"亏损"是否真的意味着其经营已受 AI 编程工具（如 Cursor、Claude Code）冲击而陷入困境。

关键信息梳理：

• 财报主体澄清：亏损的是捷克子公司 JetBrains s.r.o.，而非集团整体。母公司是荷兰的 JetBrains N.V.，集团合并财报并未亏损。
• 亏损原因拆解：营业利润同比下降约 63%，净亏损约 3.15 亿捷克克朗；但财报披露当年汇兑损失约 15.16 亿克朗，主要受捷克克朗升值影响——这是汇率因素，不完全是经营恶化。
• 不同口径对比：集团口径下收入同比增长 25.69%，Q4 AI 活跃付费用户达六位数、同比增长 240%。两个口径统计方式不同，不能直接比较。
• 群友结论：盈利能力确实承压，但"无法证明已因 AI 冲击陷入经营困境"。对于"捷克子公司就是母公司"的疑问，信息提供者明确表示不是。

痛点：财报解读的难度在于口径不一致，容易以偏概全。投资者/开发者需要区分"某子公司亏损"与"集团整体经营状况"的区别。

---

专题：Adobe 的"开源仿品"与商业模式困境

围绕 PhotoCraft（开源 Rust 版 Photoshop）的讨论扩展到了 Adobe 的商业模式与未来生存能力。

观点交锋：

• 开源仿品会"干死" Adobe 吗？ 有群友问"会被干死么"，随后有人说"干的死"、"干不死"。最终澄清：从法律角度，PhotoCraft 是 clean-room 实现，并未直接侵犯 Adobe 版权，因此难以通过法律手段阻止。
• 为什么 Adobe 令人生怨：群友指出 Adobe 不只是昂贵，订阅取消机制刻意做得极难，曾被起诉并交了和解金（但未认错）。人们对 Adobe 极度不满，仿品越来越多是市场情绪的真实反映。
• 核心判断：有人称 Adobe"盈利模式看上去非常健康，实际上离死不远了"，但群友也指出 PR + AE 的组合仍在"拯救他"——也就是说，Adobe 的生命线在于视频剪辑与特效工具的壁垒，而非图像编辑本身。
• PhotoCraft 初步印象：macOS 版仅约 68MB（universal 版，单文件约 34MB），官方版 1GB+；安装包体积比 Logseq 都小。但"没有偏好设置入口"，目前还缺配置项。

痛点：大型商业软件对"取消订阅"的刻意阻碍已成行业敏感话题，开源替代品以轻量、可自托管方式切入，构成了对现有商业模式的直接挑战。

---

🔑 关键概念与技术解析

1. MCP 治理工具：用于管理 MCP（Model Context Protocol，模型上下文协议）服务器、连接、权限与 token 的中间层工具。群友提到候选包括 Executor、magpie、Composio、Pipedream、open-connector（含 token 管理）。群内暂无进一步推荐，仅表示"mcp 不多，没用 mcp 治理工具"。

2. Herdr 作为 subagent 的调度：有人提到"直接让模型自己调 herdr 来当 subagent"——即把 herdr 当作模型可调用的子代理执行工具。这符合"模型自主编排工具"的新兴范式，强调返璞归真、直接让模型掌控流程。

3. Windows 窗口自绘制（Custom Frame）：指不使用系统标准标题栏/边框，而是自行绘制窗口。相关参考：微软文档《Custom Window Frame》——用于实现自绘窗口的官方指导。有人感叹"自绘制窗口"很帅，也有人分享"一直这么干，非常好用"。

4. PhotoCraft：开源、clean-room 重新实现 Adobe Photoshop 的纯 Rust 项目（GitHub: storytold/photocraft）。核心价值在于轻量（约 68MB），且 Linux 版本也已出现。群友称"美中不足，没有偏好设置入口"。

5. neomacs + WASM boot 动画：某群友为 neomacs（一个非官方 Emacs 变体或类似项目）的 WebAssembly 版本添加了启动动画，并在其 GitHub Pages 上提供体验。

---

💎 碎片知识与金句拾遗

• 某群友提到"发现直接让模型自己调 herdr 来当 subagent 还挺不错的，返璞归真"——强调让模型自行编排子代理，简化开发者的干预。
• 对 JetBrains 的观察："盈利能力确实明显承压，但目前不确定以证明 JetBrains 已因 AI 冲击陷入经营困境。" —— 这句话提醒大家不要过度解读单一数据源。
• 关于 Adobe："adobe看上去盈利模式非常健康，实际上离死不远了" + "还在拯救他的是 pr+ae 的组合" —— 简洁有力地指出了 Adobe 的脆弱点与护城河。
• 关于 PhotoCraft 体积："macOS 才 68MB，而且还是 universal 版，一个文件大小才 34M 左右。官方 1GB 以上" —— 巨大体积差距令人震惊。
• 某群友分享了一个 B 站视频链接，引发"卧槽""兄弟你搞基吗"等互动，属于群内社交性质，不纳入知识整理。
• 关于 MCP 治理工具的提问，当天未获得实质推荐，可推测该话题尚未沉淀成熟结论。

---

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

1. MCP 治理工具选型：Executor、magpie、Composio、Pipedream、open-connector（含 token 管理）这五者各有什么适用场景？尤其是"含 token 管理"的 open-connector，值得进一步调研。
2. 模型自主调用 herdr 作为 subagent：这种"模型自行编排子代理"的实践是否有更成熟的模式？值得跟踪。
3. PhotoCraft（Rust 实现的 Photoshop 替代）：该项目尚缺偏好设置入口，其 API 稳定性和后续发展值得关注，尤其在 Linux 生态中的表现。
4. neomacs WASM 版：给 WASM 版加入 boot 动画的实践，可作为 Emacs/文本编辑器 web 化趋势的参考案例。

观点延伸

当天最值得咀嚼的，不是“JetBrains 会不会被 AI 杀死”或“PhotoCraft 能不能干掉 Adobe”，而是一个更普遍的判断问题：当软件形态和商业模式都在变化时，我们究竟应该观察什么，才能区分短期噪音、局部受损与真正的结构性衰退？

1. 不要把单一指标当成公司的命运

JetBrains 讨论里最关键的不是“子公司亏损”这个结论，而是群友被迫回到财报口径、法人边界和汇兑损失上。工程判断也一样：一个工具的下载量、模型调用量、用户增长，不能直接等价于长期价值；一个项目的报错、额度耗尽或某次体验变差，也不能直接证明系统整体失效。

更可靠的判断方式，是先问三个问题：这个数字对应哪一层对象？它是经营结果、会计结果，还是偶发因素？不同来源的统计口径是否真的可比？这套习惯对 AI 编程工具尤其重要。用户增长可能来自试用补贴，调用量可能来自低价值自动化，收入增长也可能掩盖单位经济恶化。真正值得跟踪的是：用户是否持续把它纳入工作流，任务完成质量是否提高，人工复核成本是否下降，以及组织是否因此改变了工具链。

2. 开源替代品真正攻击的，往往不是功能，而是关系

PhotoCraft 的冲击力不只来自“用 Rust 重写 Photoshop”或安装包很小，而来自它重新定义了用户与软件的关系：下载一个相对轻量的程序，不被订阅绑定，不必接受复杂的取消流程，也不必为了少数高级功能承受整套商业套件的重量。

这并不意味着 Adobe 会立刻消失。群里提到的 PR 与 AE，恰好说明成熟软件的护城河通常不在单个功能，而在工作流兼容、行业标准、团队协作、插件生态和用户迁移成本。开源项目要真正构成替代，不能只证明“能打开、能编辑”，还要建立稳定的配置、文件兼容、自动化接口和可预期的发布节奏。反过来，商业软件即使功能领先，也不能无限透支用户信任。取消订阅困难这类摩擦，最终会转化为迁移意愿，给替代品留下入口。

可继续研究/实践

可以做一个小型对照实验：分别选 JetBrains、Adobe 与 PhotoCraft，记录“功能覆盖、工作流兼容、数据可迁移性、自动化能力、订阅约束、人工维护成本”六项指标。不要先问谁会赢，先观察一个替代品是否已经足以让用户在某个具体环节不再回到原工具。真正的替代，通常不是一次性颠覆，而是从一个可独立闭环的工作环节开始。