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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：跨设备文件同步的“拼图式”方案

工作场景中 Win 与 iPhone 之间同步文件是痛点，群友围绕“不想在公司电脑上使用个人账号”这一核心约束展开讨论。候选方案中：

• Syncthing 是最大共识。有群友给出实际拓扑：Linux 电脑通过 syncthing 连入 macOS 生态，macBook 日记再经 iCloud 与 iOS（Beorg）同步，同时 iCloud 还连着工作用 Windows 电脑，最终形成一个覆盖 Linux / macOS / iOS / Windows 的完整同步网络。另一个加分点是 Syncthing 支持 external file versioning，可写脚本做历史备份。
• Dropbox 被认可为“同步体验最好的”，但免费版限设备且需要科学上网，有群友提到曾通过淘宝升级容量，但“免费版限制设备确实太不好了”。
• SMB 被提及但未深入，有人认为“也不失为一个好办法”。
• KDE Connect 在 iPhone 上因苹果后台限制基本残废。
• 一个亮点：苹果快捷指令可以 SSH 到主机执行命令并获取输出，为局域网内 iOS 与 PC 联动提供了轻量且无需安装第三方应用的思路。

专题二：Emacs 核心重大合入 —— Canvas 与 Windows IME patch

这是当天群内最兴奋的事件。两个 Emacs 上游 patch 相继合并：

1. Canvas 特性合并至 Emacs（commit d5f515e4a3350079330c2e80f3681d140d649c88，合并于讨论前约两小时）。有群友尝试 port emacs-reader 到 Canvas 后表示“渲染是真比 pdf-tools 流畅了”，但也发现了四个 bug，认为质量仍需打磨。Canvas 代码仅 1000 多行，被视为可能为 Emacs 内 PDF/图形渲染打开新解法。
2. zdn 的 Windows IME patch 合并（commit b7b23fce2a6b1c446074b709a9c39584340d713d）。该 patch 解决 Windows 下 Emacs 输入法闪烁问题，zdn 称“终于让 emacs 在 Windows 闪的输入法和 vim 持平了”。不过他也坦言 gvim 对 Windows 输入法的 TSF 支持更好，Emacs 仍会被嘲笑，主要原因是 w32fns.c 中相关事件代码有 3000+ 行，IME 的 TSF 部分需要 C++ 重写，非朝夕之功。

zdn 贡献的这段剧情值得记录：

“多年以后，你工位旁边使用gvim的同事看到你用emacs 邪魅一笑，哦 我知道你用的emacs，emacs在Windows上的输入法支持不好，当即，你的同事马上演示起来，按住Ctrl+滚轮缩放IME的preedit窗口，字体还能自适应缩放，你知道emacs做不到这点，你的同事也知道这一点，随后他说出了一句英文——can you emacs do that? i think so no!!!”

此外，zdn 还提到下一步计划修复 Windows 版 Emacs 无法调用内置 term 包的问题；他实现的 VSC/JetBrains 式内联渲染输入法 patch 因改动代码太多未被 Eli 合并。

专题三：Emacs 的文档阅读困境

讨论从 emacs-reader 的 Canvas port 展开，迅速演变成对 Emacs 阅读体验的全方位吐槽：

• PDF：pdf-tools 多列、非标格式处理不佳；emacs-reader 渲染流畅度提升明显，但 PR 尚未合并、存在多个 bug。有群友直言“在 emacs 里阅读 pdf 真的是找不自在”，临时查看尚可，记笔记和划线场景不适用。
• EPUB：nov.el 体感很差；EPUB 大量非法格式，边缘情况繁多，群友认为“epub 的渲染在 emacs 里可能比 pdf 更难”。
• Markdown：markdown-mode 高亮准确度低，markdown-ts-mode 样式少且无法内联预览图片，需要 grip-mode 或自定义。zdn 抱怨“我需要一个 markdown-modern”。
• 替代方案：群友推荐 Okular（KDE 杀手级应用），做笔记或页数多时体验好；也有人坚持用浏览器预览。另有群友因为“epub/pdf 体验太差”而开发了 chai，将各种格式统一转成 org，从而获得一致体验。

---

🔑 关键概念与技术解析

• Syncthing：开源、去中心化的 P2P 文件同步工具，支持多平台（含 iOS 版），支持自定义版本策略与外部脚本。
• Setup.el：Emacs 配置管理库，用宏方式组织配置。作者已不活跃，且倾向于原生写法，讨论中多人最终放弃它回到 use-package 或原生 package.el。
• Elpaca：新一代 Emacs 包管理器，常与 setup.el 搭配使用。
• Canvas (Emacs)：Emacs 新合并的绘图特性，支持在 Emacs 内进行像素级图形绘制，被寄望于改善 PDF 渲染、图形预览等场景。
• TSF (Text Services Framework)：Windows 的现代文本服务框架，gvim 等编辑器借此获得更好的输入法支持；Emacs 目前 IME 支持较弱。
• IME (Input Method Editor)：输入法编辑器。Windows 上 Emacs 长期以来存在 IME preedit 窗口闪烁、状态更新等问题。
• emacs-reader：Emacs 的 PDF 阅读器，较 pdf-tools 渲染更流畅，但成熟度不足。
• beacon：Emacs 光标定位高亮插件，在滚动或切换窗口时闪烁光标位置。
• KDE Connect：跨设备协同工具，安卓/桌面端体验较好，但 iOS 端因系统后台限制功能受限。
• okular：KDE 的文档查看器，支持 PDF、EPUB 等格式，被多位群友视为桌面端阅读器的优秀选择。
• nvim-orgmode / neorg：Neovim 社区的 org-mode 实现，其中 nvim-orgmode 有近 4K stars，其 Autocompletion 被认为完成得很好。
• chai：群友自研工具，将 PDF/EPUB 等格式统一转换为 org，改善在 Emacs 中的阅读体验。
• meow / evil：Emacs 中的 Vim 风格键位模拟，meow 是较新的轻量选择。
• Gnus：Emacs 内置的邮件/新闻组客户端，配置复杂，有群友借助 AI 将配置瘦身至 2000 行。

---

💎 碎片知识与金句拾遗

• AI 配置瘦身：zdn 把拷贝来的 Gnus 配置交给 AI 重写，代码行数骤减至 2000 行——“我让ai重写了一遍以后 代码行数只有2000行了”。
• Canvas patch 的轻量程度：“添加 Canvas 特性的代码，只有 1000 多行”，对 Emacs 这种体量的项目而言非常克制。
• Windows IME 的工程复杂度：zdn 指出 w32fns.c 有 1.2 万行代码，其中相关事件代码 3000+；Emacs 在 Windows 上的输入法事件只处理了 IME 开始和结束事件，像小狼毫（类似输入法）的状态更新 API 可能自己单独实现，事件循环里没有处理。
• Linux 的 face 渲染问题：下划线、波浪线在 Windows 上只有 1px，且不随字体缩放缩放；Linux 上 underline-style: wave 也不会跟随缩放变粗。zdn 曾想重新绘制这些 face。
• Emacs 用户的原话：“setup 搞不明白，放弃。还是用内置的use-package”；“其实熟悉了之后原生写更清楚”。
• Emacs 阅读器 bug：“我到现在为止已经发现了四个bug了，感觉质量堪忧”。
• KDE 黑粉语录：“我是kde黑，死也不用的那种”“因为我觉得他带偏了一群人的审美”“他的很多设计过度的深，有时候找个菜单要翻好多层，这个比windows还可恶”。Dolphin 的功能被绑定到 KDE 门户后有人弃用。
• Org 官网的 AI 图：κόσμος 调侃：“浓眉大眼的Org也用上AI图了（？”——指 Org 官方或相关站点开始使用 AI 生成图片。
• Neovim 的 Markdown 渲染参考：markview.nvim（OXY2DEV）和 render-markdown.nvim（MeanderingProgrammer）被推荐为 nvim 上的现代 Markdown 渲染参考。
• 苹果快捷指令的妙用：快捷指令可以 SSH 连接电脑执行命令并获取输出，iOS 端无需安装额外同步工具即可实现轻量联动。
• Beacon 评估：被问及是否用过后，有人表示“我那天也看到这个了，不过我觉得用处不太大吧？”评价偏中性。
• 关于未来工位的调侃：“多年以后，还有没有工位都不知道了”“多年以后 vsc 都没有人继续用了，唯独 emacs 这个坚持古法编程的古老编辑器还遗留着”。

---

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

• Emacs Canvas 特性：刚合入 upstream，当前仅 1000 多行代码。其与 emacs-reader 等项目的结合可能重塑 Emacs 的图形/文档渲染能力，值得持续关注后续 patch 与生态适配。
• emacs-reader 的 Canvas port：已有初步测试，渲染流畅度优于 pdf-tools，但仍有多个 bug 待修。若 PR 成熟并入，可能成为 Emacs 端 PDF 阅读的新选项。
• Windows Emacs 输入法改进：zdn 的 IME patch 已合并，但其后续计划（修复内置 term、TSF 支持）值得跟踪追踪。Windows 平台 Emacs 用户可直接受益。
• nvim-orgmode：近 4K stars，Autocompletion 完成度被群友认可。可作为 Emacs org-mode 外部视角的参照，尤其是补全体验。
• chai：将 PDF/EPUB 等多种格式统一转为 org 的思路，解决了 Emacs 内阅读体验差异的问题，适合关注其实用性与边界。
• Syncthing external file versioning：官方支持外部脚本做版本控制，结合自建脚本可实现接近 Dropbox 的历史版本能力，适合关注数据安全的自托孤用户。
• setup.el / elpaca 的替代配置方案：虽然讨论中多人回归原生写法，但 Elpaca 与原生 package.el 的混合用法仍有参考价值，zdn 的配置仓库 github.com/zHaOdANiuu/.emacs.d 可作为范本。

🧠 Hermes GPT-5.5 观点延伸

中心判断： Canvas 的 1000 行合入，与同一天被反复吐槽的"在 Emacs 里读 PDF/EPUB 是找不自在"，其实是两件事——渲染能力在变强，但阅读困境的瓶颈从来不在渲染。Emacs 刚拿到的是"能画"，用户要的却是"能读"。能力增强不等于体验改善，今天这两条线放在一起，恰恰把这个错位摆到了台面上。

一、1000 行是优点，也是天花板。 Canvas 能合入，是因为它做了一件干净事：提供像素级绘制原语，不碰具体格式。但阅读的难全在脏的部分——多列排版、非法 EPUB、环绕、复制语义、边缘情况，这些不占渲染，占解析与重排。emacs-reader 的 Canvas port 先"比 pdf-tools 流畅"、接着"已经发现四个 bug"，顺序本身就是证据：渲染层快了，格式层该翻的车一个没少。Canvas 给的是画布，不是文档引擎，别把它当后者用。

二、"我需要一个 markdown-modern"，本质上是要一个不脏的格式。 zdn 这句话的对照物很说明问题——nvim 有 markview.nvim 和 render-markdown.nvim，因为"nvim 社区没有 org，可以集中精力"；而 Emacs 这边"org 太自由，很多边缘情况，做预览处理做到心累"。同一个格式，一边能集中火力做渲染，一边被自己的自由拖垮。chai 把 PDF/EPUB 全转成 org，成立的原因正是"转译即统一"：把"N 个格式 × 边缘情况"的乘法，降成"1 个渲染器 + N 个转换器"的加法。这是对的方向，代价是把格式复杂度挪到转换侧——错误会在转换时静默固化，所以转换器必须可审、可回滚，而不是一次性的管道。

三、IME 那条线：差距越接近重写级，就越不再是技术问题。 zdn 的 patch 让 Emacs 输入法"和 vim 持平"，但真要和 gvim 的 TSF 对齐，得重写 w32fns.c 里 3000+ 行事件代码；他的内联渲染 patch 被 Eli 以"改的代码太多"拒掉。"改得太多"这个拒绝理由，本质是维护者对合并的克制——它把 Emacs 的 Windows IME 从"可修的 bug"推成了"一段身份叙事"。于是留下了那个"can you emacs do that"的段子：当剩余差距的修复成本逼近重写、收益却只覆盖小众场景，技术债就会结晶成文化梗。承认这一点比继续宣称"会追平"更诚实。

可继续实践： 用 Canvas 重绘下划线/波浪线 face——这是 zdn 点名的明确缺口（Windows 上 1px、不随缩放），目标是先回答一个更小的问题：Canvas 原语能不能在"随 font 缩放同步变粗"这件事上给出干净结果。这是半天能跑完的最小闭环，比空谈"Canvas 重塑渲染"便宜得多。另一路：给 chai 的转换流水线统计"非法格式在真实 EPUB 样本里的占比"，量化"统一转 org"到底吃掉了多少复杂度——若占比稳定偏高，说明押注统一转译优于逐格式打磨渲染器；若占比低，则说明真正该补的是渲染侧，而非再写一个转换器。两个实验都不需要哲学争论，一个周末出结论。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

1. AI 成本上涨、量化部署与“智商倒退”焦虑

当天群内对 DeepSeek 涨价反应最激烈。有消息称“deepseek涨价10倍”，立刻有人质疑：“不是说涨2到3倍吗？感觉10倍那一点竞争力都没有了”。随后补充细节：原先 flash 输入价格约 1 元、pro 约 3 元，而“pro高峰缓存命中直接12倍了”，被形容为“超级加倍”；flash 相对还能接受。对创始人的调侃也从“梁圣”变成“老梁”“梁叔”，甚至有人自称“ds一生之黑”。

讨论很快延伸到主观体验：“为什么年初的时候我感觉到的ai智商没有什么这么低的”。有群友猜测“普遍缺卡吧”“都开始部署猛猛量化过的版本了”，即算力紧张促使厂商上线更激进的量化模型，可能牺牲模型质量。另一条技术线索是 OpenAI 的 sol/luna 模型卡标注 1,050,000 token 上下文，但 Codex API 实际限制为 372,000，官方 harness 又采用 272,000，原因是 usage calibration 发现超过该阈值时输入缓存会导致用量超预期。这揭示了模型能力、API 限制与成本控制之间的张力。

针对 AI 读代码的局限，有群友指出“大部分大模型流口水，是因为它们只看到非常局部”，并建议“用类似 ast-grep 这种工具，可以帮助 llm 更好地读代码”，而不是“有源码不看用 objump 看汇编”。

2. SuperGrok Heavy + Cursor Ultra：会员捆绑羊毛经济学

群内两次讨论马斯克的 SuperGrok Heavy。先是有人感叹印度区薅到该套餐的朋友“赚大发了”：300 美元可得 Grok、X Premium+、Cursor Ultra 三家会员，且 Cursor Ultra 还含约 400 美元第三方模型额度。晚间有人给出详细薅羊毛步骤：通过定向链接 5 折开通 SuperGrok（$15/月）、33 折开通 SuperGrok Heavy（$99/月，首步可抵扣），再领取 Cursor Ultra，长期免费使用大量 Grok/Composer 用量。群内判断“supergrok 是超值的套餐了”。

3. Emacs 生态：telega/tdlib、corfu 补全与上游贡献

telega 相关讨论较分散但信息量大。Arch 用户提到 AUR 有 telegram-tdlib，“我一直都用的这个”，并指出 Arch Cn 源里有编译好的 tdlib-td 包，“给 telega 编译 server 完全够用了”。Windows 用户则抱怨“两个 Windows 设备跑 emacs，每个都要单独编译就很麻烦”。有人报告“我给解决了telega疯狂报错的问题了”，但“按照维护者说的不管用”，说明官方建议在特定环境下失效。

补全方面，有人询问“telega 可以使用 corfu 补全吗？不想安装那个 company”，得到肯定答复并分享配置：LuciusChen/.emacs.d 的 init-social.el#L175。另有一位群友的 patch 被合并进 emacs-mirror/emacs（commit b7b23fce…），属于当天值得记录的贡献。

4. 文化热点：《牛来》被强制下线与舆论反弹

电影《牛来》成为群内非技术热点。白天有人问“好看么”，得到的评价是“超级难看”。晚间网传该片被通知强制停止排片、下线，预测票房 1800 万或泡汤。群内反应两极：“牛来不了了😁”“玩不起啊，敢给人家龙标，还不敢让人看了”。另有群友转发小红书版权方联系链接，并评论“小红书集美太坏了，想喂外国人吃屎”，随后有人补一句“法国人虽然是喜欢整抽象，但人家是精致的抽象”，指向某种文化输出中的误导现象。

🔑 关键概念与技术解析

• tdlib / telegram-tdlib：Telegram 官方跨平台客户端库，telega 等 Emacs Telegram 客户端依赖它建立连接。AUR 或 Arch CN 源提供预编译包，可免去手动编译。
• telega：Emacs 的全功能 Telegram 客户端，基于 TDLib server 运行。
• transient：Emacs 的交互式菜单/命令 UI 库，Magit 等大量包基于它构建快捷键界面。
• corfu：Emacs 轻量级补全前端，可作为 company 的替代，直接配合 completion-at-point-functions 使用。
• ast-grep：基于 AST 的代码搜索与重构工具，可帮助 LLM 提取结构化代码片段，避免“只看到局部”的理解偏差。
• Codex API context window：OpenAI 部分模型卡标注 1,050,000 token 上下文，但 Codex API 限制为 372,000，官方 harness 进一步降至 272,000，以控制输入缓存带来的超额用量。
• SuperGrok Heavy / Cursor Ultra：X 的高级捆绑订阅，包含 Grok、X Premium+、Cursor Ultra；后者提供第三方模型 API 额度。通过定向链接可低价订阅。
• 量化模型（quantized model）：降低权重精度以减少算力/显存消耗，但可能降低模型表现；群内用“猛猛量化”解释 AI 主观变笨现象。
• top-rss-list / anyfeeder：优质 RSS 源列表项目，可用于订阅人民日报等源。

💎 碎片知识与金句拾遗

• “不插电，xcode ChatGPT Figma 等就只能用两小时”——移动场景下重型开发/设计工具续航尴尬。
• “Arch Cn源里有编译好的tdlib-td包，给telega 编译server 完全够用了”——Arch 用户可绕过手动编译。
• “给 disco 搞了一堆括号类型”——上下文不明，疑似给 Discord 相关配置添加括号类型。
• “我是ds一生之黑”“梁圣变老梁了”“梁叔”——DeepSeek 涨价后的群内调侃。
• “pro高峰缓存命中直接12倍了”“那flash还可以？”“pro是超级加倍了”——DeepSeek 调价细节，pro 缓存命中成本暴涨。
• “普遍缺卡吧”“都开始部署猛猛量化过的版本了”——对 AI 主观感受变笨的两个猜测。
• “有源码不看用objump看汇编”“用类似 ast-grep 这种工具，可以帮助 llm 更好地读代码”“大部分大模型流口水，是因为它们只看到非常局部”——AI 代码理解局限及工具改进思路。
• “让ai抠细节太麻烦了”“尤其是让没有视觉的ai扣界面细节”——AI 在 UI/细节类任务上表现不佳。
• “我的patch好像被合并了” + emacs-mirror commit b7b23fce2a6b1c446074b709a9c39584340d713d——群友贡献进入 Emacs 上游。
• B站安卓版“...”菜单缺“标记点分享”按钮，用户想保存视频时间点链接，可能需更新客户端或寻找入口。
• “在ds 涨价前夕狠狠蹬了一次，让它给我美化美化mu4e 和elfeed🐸”——涨价前抓紧利用 DeepSeek 美化 Emacs 邮件和 RSS 界面。
• V2EX 站长 Livid 分享自己搭建的 Harness（推文链接），被群友视为“完全是一个 AI Cloud OS”。
• “牛来不了了😁”“玩不起啊，敢给人家龙标，还不敢让人看了”——《牛来》下线后的群内反应。
• AI/算力行业数据：Anthropic 二季度营收同比增 13 倍达 115 亿美元，预计 2028 年收入 1900 亿-2000 亿美元；腾讯二季度预付超 510 亿元算力采购定金。

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

• Emacs 上游 patch：commit b7b23fce2a6b1c446074b709a9c39584340d713d 被合并，可查看具体功能与影响。
• top-rss-list 项目：优质 RSS 订阅源列表，可进一步整合为个人阅读器源。
• ast-grep + LLM 读代码：探索用 AST 工具预处理代码，提升大模型对全局结构的理解，可能缓解“只看到局部”的问题。
• Livid 的 Harness / AI Cloud OS：个人 AI 编排层思路，值得持续关注其实现方式与开源可能性。
• Codex API 上下文限制与输入缓存成本：官方模型卡与 API 限制的差异、272k 阈值背后的 usage calibration，可研究 API 定价与长上下文经济性。
• SuperGrok Heavy + Cursor Ultra 捆绑：短期羊毛诱人，需验证折扣持续性和 $400 API 额度实际到账/使用限制。

🧠 Hermes GPT-5.5 观点延伸

中心判断：当天最有张力的不是"DeepSeek 涨价"，而是涨价与"AI 变笨"同时发生。 群友把两件事连起来的直觉——"普遍缺卡吧""猛猛量化"——其实是一个可检验的假说：算力紧缺正从"排队限流"转成"定价、质量、上下文"三个维度的隐性回传。市场侧数据（腾讯预付 510 亿锁 GPU 产能）确认缺卡不是错觉；群聊里三条技术证据指向同一方向，且每条都能自己动手验证。

一、12 倍缓存命中涨价，是对上下文重度工作流的定向征税。 pro 高峰缓存命中直接 12 倍，flash 相对还能接受——这个结构本身就在表态：长上下文、反复命中的 agent 用法，是平台最想砍的成本大头。可验证的做法很直接：拉自己真实工作负载的账单，看缓存命中 token 的占比；占比高，对策就不是换供应商，而是改喂法——固定前缀、把"全量塞仓库"改成"检索后喂"。群友"涨价前夕狠狠蹬一次"让 DeepSeek 美化 mu4e/elfeed 的行为，本质是涨价预期下的库存前置，说明用户行为已经开始自适应。

二、"变笨"有两个假说，验证路径不同。 供给端假说：缺卡 → 线上部署更激进的量化版本。使用端假说：模型"只看到非常局部"就流口水，是上下文工程失效，不是权重退化。两者不互斥，但分别对应两个动作：前者拿一个固定 mini eval（比如 20 道 Emacs Lisp 代码理解题）定期打同一个 API，观察行为漂移；后者照群里说的用 ast-grep 先做 AST 切片再喂，看同一批任务错误率是否下降。哪个假说被数据支持，就决定你该换供应商还是该换喂法——这是把群聊情绪变成可判赔事实的唯一路径。

三、Codex 的 372k→272k 校准，是"长上下文是负债"的官方注脚。 模型卡写 105 万，API 限 372k，官方 harness 自己降到 272k，理由是超过该阈值后输入缓存让用量失控。三个数字钉死三层现实：营销数字 ≠ 工程限制 ≠ 经济可行性。推论：一切"往大上下文里塞全量资料"的工作流，都在跟平台的缓存成本对撞；涨价只是这场对撞显形的一种方式。这也顺带解释了群里的另一句抱怨——"让没有视觉的 AI 抠界面细节太麻烦"：细节类任务的天生解法是喂更多上下文，而上下文正是当下最贵的资源，二者方向相反。

可继续的方向： 建一个个人 mini eval（50 道以内，覆盖代码理解、UI 细节、长文总结三类任务），定期打当前 API。有这条基线在手，"AI 变笨了"才从群聊情绪变成可观测的趋势线，换模型还是换喂法也才有依据。