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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：【Emacs 终端显示与输入法深度调试】

今日群内最硬核、持续最久的讨论围绕两个看似无关实则底层相通的问题：Telega/TUI 下的字符渲染 Bug 与 输入法 Preedit（预编辑）光标行为。两者都触达了 Emacs 显示引擎与窗口系统/终端协议交互的深水区。

1. Telega TUI 启动卡死与 Glyph Matrix Bug

• 现象：用户在 TUI（终端用户界面）环境下启动 telega 会导致 Emacs 无响应；或在 TUI 下 telega 界面渲染混乱。
• 根因定位：
  • 成员 Lucius_Chen 定位到问题与 Emacs 的 auto-composition-mode 相关。在终端中，Emacs 的 composition 机制在处理某些字符（如带 VARIATION SELECTOR 的 emoji ⚡️）时，虽算对了整体 glyph 宽度为 2，但在 TTY glyph matrix 内部只分配了 1 列的索引，导致坐标错乱，进而引发 telega 这类重度依赖精确对齐的程序崩溃或卡死。
  • 另一个潜在触发点是当 fill-column 设为无穷大时，Telega 的布局计算可能陷入长时间无响应。
• 解决方案：
  • 临时绕过：在 TUI 下禁用 auto-composition-mode。配置示例：(add-hook 'telega-root-mode-hook (lambda () (unless (display-graphic-p) (auto-composition-mode -1))))
  • 根本修复：成员正在尝试让 AI 辅助编写 C 层面的 Patch，期望能正确修复 glyph matrix 的索引分配问题。
• 兄弟问题：Emacs 的 Emoji 支持被群嘲“千疮百孔”：组合有问题，组合后宽度计算有问题，即使宽度对了渲染也可能有问题。尤其在 Pgtk（Wayland）和不同终端（Kitty/Ghostty）之间行为不一致。

2. 输入法 Preedit 候选框“跳动”之争与光标控制

• 核心争议：在 Linux 桌面（尤其是 Pgtk）下，使用系统输入法时，preedit（预编辑字符串）在 Emacs buffer 内渲染，导致候选框随着光标移动而“跳动”（跟随 preedit 插入的 overlay 位置实时变化）。部分用户（如 Lucius_Chen, 0WD0）认为这是严重的用户体验 Bug，因为眼睛需实时追踪候选框，而浏览器等主流应用是固定候选框不动的。
• 技术剖析：
  • zdn 指出，Windows 下默认不会跳，因为原生应用需特别处理合成字符串时的光标事件。他已在 Emacs 的 X11 后端实现了光标在 preedit 中左右移动以修改拼音的功能，并指出 Pgtk 后端疑似无此实现，导致光标不可见（但按键逻辑仍在）。
  • 讨论深入到 Wayland 的 zwp_input_method_v2 协议。有人认为候选框跟随光标是 Wayland 协议或特定组合（如 fcitx5 + 部分终端）的设计行为，可通过配置 PreeditCursorPositionAtBeginning=True 固定，但实践反馈该选项或某些场景下“没用”。
  • zdn 认为不跳动才是“细糠”，追求与浏览器体验一致。
• 解决方案/Workaround：
  • 针对 Pgtk 候选框跳动，0WD0 提供了一个 Elisp advice 临时修复，通过覆写 overlay 的 cursor 属性来抑制跳动感。
  • 部分用户选择使用 rime.el（Emacs 内置输入法框架）或干脆不看候选框，回避问题。
  • 这场讨论充分暴露了 Emacs 作为一个 GUI/TUI 混合应用，在处理现代输入法框架时的架构性尴尬。

🔑 关键概念与技术解析

• auto-composition-mode 与 glyph matrix: Emacs 的“自动组合模式”能将多个字符码点（如 ⚡ + VARIATION SELECTOR-16）作为一个复合 glyph 渲染。glyph matrix 是终端下管理字符显示位置的网格结构。当前 Bug 在于“字符组合宽度计算正确，但在底层矩阵中分配的空间不足”。
• tramp-rpc: 一个新兴的 Emacs 远程文件编辑优化方案。相比原生 tramp，它在远程主机上运行一个辅助进程，通过 RPC 通信，并内置了针对 magit 等重量级应用的优化（减少 Git 命令调用、缓存结果），极大提升远程操作流畅度。
• no-littering: 一个 Emacs 包，旨在将各插件散落在 user-emacs-directory 下的各种临时文件、缓存、历史记录，重新定向到 XDG_CONFIG_HOME、XDG_CACHE_HOME 等标准目录，保持主目录整洁。有成员反馈其仍有文件归类不当（如未放入 XDG_STATE_HOME）及 byte-compile warnings 等问题。
• pgtk-preedit-text: Pgtk 分支中的一个函数，用于在 Emacs buffer 内用 overlay 技术渲染输入法的预编辑字符串，是实现内联输入的关键，也是候选框“跳动”问题的根源。
• telega-bridge-bot: 用于桥接 Matrix 和 Telegram 的机器人。能让 Matrix 用户看到 Telegram 用户的正确头像，而非统一的 Bridge 头像，提升跨平台聊天体验。

💎 碎片知识与金句拾遗

• 远程工作流优化：“magit + tramp 的体验好糟糕啊”，多位成员强烈推荐用 tramp-rpc 替代，作者合 PR 积极，已在 lem 编辑器中实现远程 Terminal 支持。
• Emacs 包管理哲学：“我现在一般不整理 .emacs.d, 随便拉屎, 因为我都是用 init.el 加载另一个 .emacs.d 同级目录做我的配置文件目录”，也有人直接使用 --init-directory=XXX 启动隔离环境。
• All in Emacs 争论：“不要 all in Emacs 啊” vs “要 all in Emacs 啊”，有人在尝试将 Emacs 做成桌面 Launcher，并结合 gtk4-layer-shell 探索作为 Layer Shell 组件的可能性。
• 邮件富文本处理：mu4e 用户可配置 mm-discouraged-alternatives 为 '("text/html") 以优先显示纯文本版本；也有用户直接覆写 rendering 让 xwidget 接管 HTML 渲染。gnus 用户则享受默认纯文本的清爽。
• 打造舒适开发环境的细节：
  • 编译耗时：Emacs master (C 部分) 编译很快（得益于 Make 增量编译）；但 native-comp AOT 极为耗时，低压 CPU 全量编译可能需 50 分钟。
  • 时间管理：“这个电脑我每周升级要花两小时以上”。
  • 一个小坑：在 Windows 下使用 prettier | autocorrect 管道格式化 Markdown 时，可能因为 MSYS2 环境库的干扰，在输出中插入奇怪的版权声明头，移除相关 PATH 后恢复。
• 平台选择见解：“Windows 上的输入体验是最好的，还有各种商业输入法。我在两个系统反复横跳，间隔不过两天。” 同时，Win11 被直接评价为“最烂的”。
• 社区观察：Emacs 29 被普遍认为是分水岭，29 后版本明显更好用。Reddit 上也有文章感慨 Emacs 从 30 到 31 版本迭代速度之快。
• 一句有趣的表白：“他的 emacs 我覺得只配了一個主題”。

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

• 0WD0/emacs (gtk4 分支): 位于 https://github.com/0WD0/emacs/tree/gtk4，这是一个为 Pgtk 特调的、支持 GTK4 的 Emacs 分支，甚至实现了在 Dired 中拖拽文件到外部应用的功能。编译需加 --with-gtk4 参数，虽还有光标丢失等小 bug，但极具探索价值。
• zdn/fido-frame: 成员 zdn 正在打造的一个利用 child-frame 作为补全 UI 的包，可灵活调整宽度高度，意图提供一个比 minibuffer 和 posframe 更独立的交互模式，目前正在密集修改 patch。
• telega-bridge-bot: 位于 Telega 的 contrib 目录，用于在 Matrix 和 Telegram 桥接时，修复用户头像显示问题，前提是双方群组 ID 一致。
• 北山(bsvh)的 gnus 配置：https://github.com/brsvh/fleet 和 https://github.com/brsvh/emacs-bs。几乎魔改重写了 gnus 的 group/summary 界面，实现了炫酷的折叠效果和与 mu4e 风格一致的二次渲染，值得所有 Gnus 重度用户参考。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“Emacs 又有几个显示 bug”，而是：Emacs 的强大正在越来越依赖它能否把底层显示、输入、远程执行这些脏活做成可靠工程，而不是继续靠用户用 Elisp 在上层补洞。

1. All in Emacs 的边界，不在功能，而在协议正确性

群里一边讨论把 Emacs 做成 launcher、Matrix/Telegram/QQ/Slack/Discord 的统一入口，一边又在追 Telega TUI、emoji composition、Pgtk preedit、Dired drag-out 这些底层问题。这两条线其实是同一件事。

Emacs 不是缺“能不能做”的想象力。它的问题是：一旦你把聊天、输入法、桌面启动器、远程开发、邮件、补全 UI 都塞进来，Emacs 就不再只是编辑器，而是在扮演一个应用运行时。运行时的底线不是可配置，而是协议行为稳定：字符宽度、glyph matrix、preedit 光标、候选框定位、终端能力探测、Wayland/X11/Pgtk 差异，都不能靠“用户自己知道怎么绕”来成立。

所以“不要 all in Emacs”和“要 all in Emacs”并不是审美分歧，而是工程成熟度判断：如果底层协议抽象不稳，All in 会把每个边缘 bug 放大成日常摩擦；如果这些层被修实了，Emacs 的可塑性反而会成为桌面级集成的优势。

2. AI Agent 真正有价值的地方，是把“魔改”推进到可合并补丁

当天反复出现一个模式：有人定位 bug，有人临时 advice，有人让 AI 看 C patch，有人把 Doom 配置迁移学习成自己的配置，有人给外部项目连提 PR。这里的关键不是“让 LLM 帮我写配置”，而是社区正在把个人魔改变成工程反馈闭环。

临时禁用 auto-composition-mode、覆写 pgtk-preedit-text overlay、调 fill-column，这些都是止血；真正有价值的是继续追到 glyph matrix 为什么少记录一列、Pgtk preedit 为什么看不到光标、终端对 emoji 宽度为何不一致。AI Agent 如果只停在生成 workaround，就是放大配置债；如果能辅助读 C 层、跑复现、缩小 patch、写测试、向上游提交，才是在降低整个生态的维护成本。

3. “细糠”不是矫情，是生产力系统的验收标准

候选框跳不跳、emoji 宽度准不准、Magit over TRAMP 卡不卡，看起来都是小体验。但对重度用户来说，这些小体验决定一个系统能不能从“爱好者玩具”变成“每天八小时的工作台”。输入法候选框跳动之所以引发争论，是因为它暴露了一个朴素标准：用户的注意力不该被工具强迫追着 UI 跑。

这也解释了为什么 tramp-rpc 会被迅速推荐：它不是抽象上更优雅，而是直接减少 Git 请求、缓存结果，让远程 Magit 从“理念正确”回到“体感可用”。

可继续研究/实践

选一个高频痛点做成可验证工程闭环：例如 Pgtk preedit 候选框定位或 TTY emoji composition。最小目标不是再写一个配置片段，而是形成“复现用例 → 后端差异矩阵 → 最小 patch → 回归测试/截图证据 → 上游 issue/PR”的链路。Emacs 生态接下来真正的进步，不会来自更多配置模板，而会来自这些脏问题被一个个钉死。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题：笔记系统与工具哲学的碰撞 — Denote vs. 传统编辑器

今日讨论由一位群友的感慨引发：“不是成败论的问题，至少一开始上 denote ，不用 logseq 等迁移来迁移去”。这引出了关于笔记工具选择及其底层哲学的深入探讨。

• 设计美学与实用主义的权衡：群友 @matata 高度赞扬了 Denote 的设计，认为“把文件名作为 schema 是一个很精巧的设计吗？过滤和检索实际上是通过 sed 或者别的命令完成，底层很轻，但足够 solid，有一种工程的美学”。这种基于纯文本文件命名规则的方案，完全避开了对 SQLite 等数据库的依赖，赋予了用户极大的可移植性和工具控制权。
• AI 原生工作流的契合度：有群友指出，Denote 不依赖特定数据库的特性使得“让 AI 生成 denote 的文件，这好像也比较方便”，体现了这种轻量级方案在与现代 AI 工具集成时的灵活性。
• 不同工具的取舍：讨论也提及了 Logseq、Vicinae 等工具的不足。群友抱怨 Vicinae “剪贴板搜不了符号”且窗口尺寸“只能用长宽像素写死”，认为其在细节打磨上存在缺陷。这反映了社区对工具“开箱即用”体验和“精细化控制”的双重期待。

专题：AI 模型行情与“价格战”技术剖析

OpenAI 和 DeepSeek 的动作成为讨论的焦点，群友们以极客视角分析了商业策略与技术性能。

• OpenAI 降价的真实意图：GPT-5.6 Luna 降价 80%，Terra 降价 20%，而旗舰 Sol 价格不变。群友敏锐地指出，这是 “分流” 策略——“降价是为了分流，可能分流到其它两个模型后（旗舰 Sol 的）压力小了”，反而可能提升旗舰模型的稳定性与感知性能。有群友直言“我们不用sol以外的”，表明高要求场景下，成本并非首要考量。
• DeepSeek V4 的性能跃迁与市场定位：
  • Flash 版本的反超：V4 Flash 正式版跑分力压 GLM-5.2，接近 Opus 4.8 水平，被评价为“性价比很逆天”。
  • 冲击高端市场：群友预测即将发布的 V4 Pro 正式版可能对标 Sol Max 和 Opus 5，如果其性能真的“超过 k3”，将打破现有“DS做性价比，K3做高端”的市场格局。
  • 工具链整合：新版本开始支持 Codex，被看作是针对 Claude 此前限制性操作的回应。同时解决了早期不支持 流式输出 的问题，改善了在 gptel 等客户端下的体验。

专题：从 DAP 到 GUD — 调试工具的回归与反思

一场关于“调试器体验”的讨论揭示了部分开发者对“简单直接”的旧式工具的回归倾向。

• 现代工具的痛点：群友 @matata 明确表示“dape 和 dap-mode，不如老式的 gdb 和 lldb 工具直观”，并补充说其“查看数据做的不够好”。这反映了 DAP 协议虽然统一了接口，但某些实现（特别是数据可视化层面）无法满足开发者在复杂状态下的即时查看需求。
• CLI 原生工具的价值：当切换到C++等“开发相关CLI完成度很高的开发栈”时，一边用 gdb 的 p variable 直接打印，一边结合 lldb 的体验，带来了“幸福体验直线提升”的感觉。这种对即时性、简洁性的追求，是对过度封装和界面复杂化的一种反抗。
• 未满足的需求：即便偏爱 gdb，也有群友指出其“可惜没有保存上一次调试的需要查得的 variable”的不足，这为工具改进留下了明确的方向。

🔑 关键概念与技术解析

• GGUF (Georgi Gerganov Unified Format)：一种用于存储大型语言模型（LLM）的文件格式，由 llama.cpp 的作者创立，旨在统一和优化模型的存储与加载。群内有成员发现其设计者关注到了自己的项目，引发了小范围关注。
• Hermes Agent：一个自我进化的 AI 代理系统。被群友广泛用于排查系统问题，可以“在内网的机器间任意穿梭”并将诊断结论记录复用。它有从“直接写项目”到“调用 Codex 写代码”的多阶段工作流整合能力，被认为“主要是产品打磨的不错”，且与 DeepSeek 组合成本可控。
• DAP (Debug Adapter Protocol)：一个由微软发起的调试协议，旨在让编辑器（如 VS Code、Emacs）通过一个通用适配器与不同语言的调试器通信。dape 和 dap-mode 都是 Emacs 上基于此协议的调试前端。
• Codex：此处指代 OpenAI 的编程助手终端工具。其自动化程度正在提高，会自动调用副模型（如 spark-3）执行 CLI 命令。
• Starling：一个被描述为“纯血 ai”的项目，群友分享了其链接 (starling.build)，可能是一个新兴的 AI 原生开发或构建平台。
• Scoop & Shim 机制：Scoop 是 Windows 的命令行包管理器。其 shim 机制用于创建命令的代理，但被发现并不包含 Git 自带的 MSYS2 工具（如 xargs），导致特定场景下的兼容性问题。

💎 碎片知识与金句拾遗

• AI 未来愿景：“我比较希望快点进步视觉，这样我在想是不是可以写个代肝的游戏助手替我玩游戏。” — 群友对 AI 多模态能力应用的务实幻想。
• 机构行为哲学：“如果在原来的点上拉盘是很难拉上去的，那些带杠杆的人会边拉边跑”，“机构乘机捡带血的筹码”。— 群友对金融市场“清理杠杆后拉升”模式的精辟总结。
• AI 模型成本观：“(DS V4 生成 CSGO) 仅花费9毛钱？”的惊叹, 与“我们不用 sol 以外的”形成鲜明对比，体现了开发者对成本与质量的精确权衡。
• 电动汽车的使用成本辩证：“电车只是缓解了政府的能源焦虑，对消费者来说，这玩意使用成本不低，也不省钱。” — 从宏观政策与个人钱包角度的深刻洞察。
• 城市生活观察：“禁两个轮（电驴/摩托）的城市注定是少人的, 没有烟火气的。” — 从交通工具政策上升到人文关怀的评论，将珠海与中山的对比具象化。
• 开发体验谈：“别说，一旦开始写 cpp 这种开发相关 CLI 完成度很高的开发栈，幸福体验直线提升。” — 强调了流畅的工具链对开发者情绪价值的重要性。
• 手动挡汽车的怀旧与实用主义：“你3000块买不到2手电车，但是手动档油车就可以。” — 从经济视角为即将消亡的技术提供了有力的存在论据。
• 微软的“逆天”操作：“微软向用户推送不可卸载的OneDrive Photos应用还是基于WebView开发的”，群友冷嘲“你软还是你软”，凸显了对其推广策略和臃肿客户端的不满。
• Codeberg 的困境：多位群友抱怨 Codeberg 经常 504 无法访问，有人直言“关门算了”，也有人解释“没钱啊……纯公益的吧”。这体现了社区对开源基础设施可持续性的担忧。
• 金句：“代码界的帕累托最优”（评论 Denote 的简洁设计）、“我有次下班，被连环闯红灯电驴挡住” 的无奈幽默。

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

• Hermes Agent + DeepSeek 工作流：内部深度探索用 Hermes 作为 Supervised AI Agent 进行网络内系统诊断与知识库自动化的实践，并验证其“自我进化”和“复用结论”的具体效果。
• DeepSeek V4 Pro 正式版潜力：对标 Sol Max/Opus 5，测试其在复杂代码生成、长篇技术报告阅读（“拿来尽情读财报”）等场景下，是否真正具备“高端性价比”。
• Denote 生态与现代 CLI 融合：探索围绕 denote 文件命名规范构建一套更自动化的 AI-Prompt 工作流（如自动标题、标签、链接），以及如何用 sed、awk 等工具为其构建极其实用、优雅的检索仪表板。
• GGUF 格式作者的 niri Fork 动态：关注 GGUF 格式设计者 fork 群友 niri (一个窗口管理器) 的原因和后续改动，这可能是新功能特性或特定优化方向的信号。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“Denote 好不好用”，而是一个更硬的工程判断：越是 AI Agent 时代，越要把个人知识系统做成可被普通工具读写、可被人类审计、可被脚本批处理的低耦合结构。

1. Denote 的价值不在“复古”，而在把状态外露

群里说 Denote “把文件名作为 schema”，这句话很关键。很多笔记系统把结构藏进数据库、索引、应用内部状态里，短期体验更顺，但长期代价是迁移、同步、自动化都要依赖原工具。Denote 的文件名 schema 看起来土，实际是把元数据暴露到最稳定的接口：文件系统。

这对 AI 工作流尤其重要。AI 生成一个 Denote 文件，不需要理解 Logseq 的块模型、数据库 schema 或插件状态，只要按命名规范写一个文本文件。之后 sed、find、rg、Emacs Lisp、脚本、Agent 都能接手。这不是“简单”，这是可组合性。

2. Agent 不是替代编辑器，而是放大工程边界

当天关于 Hermes 的讨论也指向同一个判断：Agent 真正强的地方，不是“帮我写几行代码”，而是跨机器排障、记录结论、复用经验。也就是说，Agent 的生产力来自它能操作一个外部化、可验证的环境。

如果知识系统、调试流程、项目结构都被封在 GUI 或私有状态里，Agent 只能变成昂贵的鼠标宏；如果所有关键状态都能用文件、命令、日志、测试暴露出来，Agent 才能变成工程同事。Denote、gdb/lldb、Hermes 这几段讨论其实是一条线：好工具不是界面最现代，而是控制面最清楚。

3. DAP 之争的本质也是“抽象有没有遮住观察”

群友说 dape / dap-mode 查看数据不够好，老式 gdb p variable 更直接，这不是怀旧。调试的第一性原理是观察状态。任何抽象层只要让“看到变量、复现路径、保存观察点”变慢，就会被熟练工程师绕开。

所以 DAP 的改进方向不该只是更漂亮的 UI，而是把高频观察动作做成可持久、可脚本化、可复用的对象：上次查过哪些变量、哪些表达式在某个断点总要看、哪些状态组合意味着 bug 接近复现。这里反而很适合和 Emacs、文本日志、Agent 结合。

可继续实践的方向

可以做一个小实验：用 Denote 管理调试与排障笔记，每次 gdb/lldb/Hermes 排查后生成一条结构化记录，文件名承载时间、项目、故障类型，正文保存命令、变量观察、结论和复现条件。验证标准很简单：下次相似问题出现时，能否用 rg/Emacs/Agent 在一分钟内找回可执行经验。这个实验比换一个更炫的笔记 App 更有工程含金量。