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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：Emacs 性能与配置的“黑魔法”

群聊中弥漫着一种“调试与优化是日常”的氛围。核心痛点集中在几个看似微小但影响巨大的配置细节上。

• 动态 org-agenda-files：有成员分享了通过 rg（ripgrep）动态筛选 agenda 文件而非全量加载的优化方案，有效解决了“文件多导致慢”的问题。这体现了 Emacs 用户对“按需加载”性能哲学的极致追求。

• 窗口与主题的尺寸“幽灵”：加载主题或设置字体时，Emacsclient 窗口意外缩小的 bug 引发了热烈讨论。最终解决方案是：在 daemon 模式下，必须使用 after-make-frame-functions 钩子来设置字体，否则 client 每次加载配置都会导致窗口尺寸重置。这揭示了 Emacs 图形界面（GUI）与终端（Terminal/Client）模式下配置生效时机的深刻差异。

• 输入法 (IM) 与 Emacs 的“战争”：特别是在 Wayland 环境下，候选框跳动（preedit 问题）是一个经典痛点。解决方案涉及对 pgtk-preedit-text 函数的 advice 或关闭输入法内的 inline preedit 配置。这暴露了 GTK/Wayland 环境下 Emacs 与输入法框架（fcitx5、Squirrel 等）的复杂交互，需要用户具备底层图形协议的知识。

专题二：Emacs LSP 生态的“选择与信仰”

关于语言服务器协议的讨论几乎是压倒性的，呈现出一边倒的态势：

• Eglot vs. lsp-mode vs. lsp-bridge: 绝大多数人选择了 Eglot。核心观点是 Eglot 设计哲学更简洁、够用、不臃肿，且鼓励将通用功能（如项目文件监控）剥离出去，避免像 lsp-mode 那样集成过多、功能过剩。这反映了 Emacs 社区“瑞士军刀 vs. 单一用途利器”的长期争论，而近期趋势明显偏向后者。

• 关键 Trick：eglot-watch-files-outside-project-root 默认值被设置为 t 是一个常见的陷阱，会导致在大型项目结构下无谓地扫描外部文件，造成性能瓶颈。

专题三：Emacs 的“灵魂”之争：Elisp 与性能、未来与复古

这是本次聊天中思想碰撞最激烈的话题，跨越了技术细节，触及了 Emacs 存在的根本。

• “Emacs 改用 Lua”的谣言：一个来自第三方群的传言迅速被证伪。社区成员普遍认为这不可能，因为 Emacs 本身就是 Elisp 的解释器，连宏都没有的 Lua 无法承载编辑器神器的哲学（“editor of macros”）。

• 性能瓶颈在哪里？ 争论焦点在于 Elisp 本身是否慢。共识是：Elisp 不是瓶颈（特别是在引入 native compile 和 igc 后），真正的瓶颈在于 单线程、同步 I/O 和 GUI 渲染。全异步 I/O 和多线程修复才是未来 Emacs 需要解决的根本问题。

• Buffer 的“远见”：一个有趣的辩论：Buffer 设计是高司令（Gosling）的远见，还是 RMS 从 TECO 继承并改造的结果？文档引证是后者（Stallman 修改 TECO 以支持大 Buffer）。这体现了 Emacs 用户不仅用工具，还研究其历史演进的硬核特质。

• GPU 加速的必要性：对于纯键盘操作的 Emacs（特别是用 child-frame 的场景），GPU 加速目前看起来“没什么用”，但当涉及图表、灵活布局（grid/flex）时，性能短板就会暴露。目前的方案是“改 webview”，暗示了 Emacs UI 架构的革命性转向可能。

---

🔑 关键概念与技术解析

• org-agenda-files：Emacs 组织模式（Org-mode）的任务管理核心，定义了哪些文件应该被纳入日程视图。
• pgtk-win / pgtk-preedit-text：Emacs 在纯 GTK 后端（通常用于 Wayland 环境）下的窗口系统。pgtk-preedit-text 函数负责处理输入法候选框的预编辑显示。群内给出的 advice 代码就是 hack 这个函数的行为来修复滚动跳动。
• inline_preedit：输入法框架（如 fcitx5）的配置选项，用于控制候选词是内联显示在光标处，还是显示在独立的悬浮框/候选项中。关闭它通常能解决 Emacs 中的跳动问题。
• lsp-bridge：一个较新、追求极速的 LSP 客户端，基于 Python 异步处理，但在本次讨论中并未获得主流认可。
• child-frame：Emacs 中的浮动子窗口，常被用来实现弹出菜单、补全框等功能，性能较差是已知痛点。
• Squirrel (鼠须管)：macOS 平台上的一个开源、高度可配置的中文输入法。它是输入法框架，不是 Emacs 问题。
• frame-inhibit-implied-resize：一个 Emacs 配置变量，用于阻止框架在改变字体或加载主题时自动调整大小，是解决窗口缩小问题的另一思路。
• Guile Emacs：一个历史悠久的、试图将 Emacs 的内核语言从 Elisp 替换为 Scheme（Guile）的项目，被社区戏称为“棺材里仰卧起坐”，暗示其多次启动又停滞的艰难历程。
• Schemacs：另一个基于 Chez Scheme 的 Emacs 重实现项目，被评价为“实现太简单了，肯定不行”。
• BigBlue Terminal：一个仿老式终端显示效果的等宽字体，迷你的点阵风格，在群内被正面评价为“清晰可读”，区别于一些现代但更模糊的矢量字体。

---

💎 碎片知识与金句拾遗

• “Eeeeeeeeeeeeeeeeeeeeeglot” —— 群友用满屏的 e 来回应“你用什么 LSP”的问题，既调侃又表达了对 Eglot 的绝对忠诚。
• “ELisp 只要有 native compile 和 igc 之后性能已经很好了。” —— 指出 Elisp 的性能进化，不再是从前的缓慢脚本语言。
• “Emacs 在 AI 时代感觉有戏，毕竟有个好的屏幕缓冲区支撑全文本，创始人太有远见了... / RMS 偷的好 / 还得是高司令高瞻远瞩” —— 对 Buffer 设计在 AI 时代的价值评价，以及开发者之间的历史梗调侃。
• “日本古老的东西多，毕竟大范围用传真机。” —— 幽默地解释了为何日本开发者至今还在贡献古老的 ftp 上的 Emacs 插件。
• “这不打字机的字体吗？” / “BigBlue Terminal 是个假点阵，可以缩放的。” —— 对一款仿老式终端字体的具体讨论，说明“古典”字体在现代技术下依然有应用价值。

---

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

1. 深入 Emacs 在 Wayland 下的输入法调试：

   • 研究路径：仔细阅读 pgtk-preedit-text 的源码，理解其返回值对 overlay 'before-string 的影响。探索 fcitx5 的 inline_preedit 配置与 Emacs 的 preedit 概念之间的对应关系。如果使用的是 macOS 的 Squirrel，如何实现类似的效果？这位群友最终是怎么解决的？
   • 研究价值：这是一个经典的“跨框架（输入法框架 vs. 编辑器框架）疑难杂症”，掌握这项技能是成为 Emacs 高级用户的关键一步。

2. 理解并实践 Eglot 的精简哲学：

   • 研究路径：对比 eglot 和 lsp-mode 的项目结构、依赖关系与核心功能。重点看 eglot 如何处理项目根目录、工作区目录、文件监控（eglot-watch-files-outside-project-root 的具体作用）。尝试只用 eglot + 独立的项目浏览/查找/补全工具（如 consult, cape 等）来搭建一个纯正的“单一用途利器”开发环境。
   • 研究价值：这能深刻理解现代 LSP 架构的边界与模块化。学会在 Emacs 中构建“够用就好”的高效工作流。

3. 追踪 Emacs 异步 I/O 与 GUI 重构的进展：

   • 研究路径：订阅 Emacs 开发邮件列表（emacs-devel）和红迪的 r/emacs。关注 igc（增量垃圾回收）、native compile、以及 child-frame 性能改进的相关讨论。研究 lem（一个基于 webview 的 Emacs 类编辑器）的实现，思考其架构对“Emacs 未来”的启示。关注任何关于多线程/非阻塞 IO 的官方提案。
   • 研究价值：这是 Emacs 当前最核心的瓶颈和未来最大的机遇。掌握其动态，能让你在社区讨论中更有底气，也能提前为即将到来的大版本更新做准备。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：代理工具的性能与架构之争（Mihomo vs Sing-box vs 自造轮子）

这是贯穿全天的核心技术话题。群友对两款主流代理客户端进行了激烈的优缺点对比，并催生了自建项目的想法。

• 核心痛点： Mihomo（原Clash Meta） 的性能瓶颈。多位群友反馈其存在高内存占用（“开机能吃掉18G内存”）、启动卡顿、频繁 out of memory 甚至 crash 的问题。有群友指出，其性能问题根源在于核心匹配算法的粗糙——例如 DomainKeyword 匹配采用 strings.Contains 进行逐行扫描，在高频请求场景下效率极低。
• 解决方案对比：
  • Sing-box： 被普遍认为是替代方案。用户评价“启动快”，dns bug 反馈后两小时即修复，配置虽有过改动但相对可靠。虽然部分用户表示“sing-box也不咋的”，但整体接受度高于 Mihomo。
  • Rust 封装（mihomo-rs）： 有人尝试用 Rust 封装 Mihomo，但立即被群内大佬定性为“在调用层包一下rust，也是好不起来的”，因底层核心是糙的，表层优化无法解决根本问题。
• 自造轮子（Flux）： 一位群友决定自行开发名为 flux（或 fluxway）的替代工具。核心思路是：
  1. 算法优化： 放弃低效的逐行扫描，针对高频匹配（如 DOMAIN, DOMAIN-SUFFIX）设计更优的数据结构与算法。
  2. 配置模型： “用一个大c函数if else switch”——将配置编译为原生代码，类似于 re2c 或 suckless 的哲学，通过重新编译来更新规则，避免运行时解析的开销。
  3. 网络栈重写： 认为现有网络栈“也不咋地”，计划在用户态实现更高效的网络栈。

专题二：Anthropic 的定价试探与社区反弹

群友对 Claude Code 的定价策略变化高度敏感，并表现出强烈的不信任感。

• 事件： Anthropic 帮助文档显示，Pro 订阅用户若要使用 Opus 系列模型，需额外付费（extra usage）。随后不久，该文档似乎被“改回来了”。
• 群友反应： 负面情绪集中爆发。关键词包括“蠢货”、“试探底线”、“把用户改没了”。群友讽刺怀疑官方是在“用AI改文档”来测试用户反应。这种“先发布，看反应再撤回”的策略引发了强烈的被愚弄感。结论是：“世界离了谁都照样转”，暗示 Anhtropic 可能会失去核心技术用户。

专题三：【极客育儿经】程序员的多线程育儿思考

群聊后半部分意外转为一场高质量的“极客育儿”头脑风暴。主要由几位已为人父的群友主导，话题从Windows升级带来的不满自然过渡到家庭生活的挑战。

• 核心矛盾： 平衡、分工与执行一致性。
  • 观念冲突： 两代人（夫妻之间、与父母之间）关于喂养量、作息时间、教育方式（如是否追着喂饭）的认知差异。这被视为分布式系统中典型的“共识问题”。
  • 角色分工： 一位群友的妻子坚持“生了就该男的养”，导致他承担了绝大多数育儿工作（换尿布、夜奶等）。另一位群友的妻子则更像“小孩子”，家庭琐事和育儿压力主要由他承担。讨论触及了“婚姻是资产重组，真正开始于有孩子”这一深刻社会观察。
• 工程化育儿经验：
  • 习惯培养的自动化（条件反射）： 一位“人肉训练师”展示了如何对15个月大的宝宝进行良好习惯的“编程”：坐餐椅才会被投喂、拉被子才能睡觉、出门要拿水杯。强调“3-5岁是习惯‘编译’窗口期，等记忆清晰了，习惯已经是‘内核’了”。
  • 错误处理： 对于小孩的无理哭闹（坐地打滚），采取“条件反射”策略：哭不理、哭得比他更大声、或者“你也哭”。这被一些群友认为是防止“bug escalation”的有效手段。
• 对比与反思： 年轻一代（20岁群友）对此感到恐惧（“梦到娶了老婆生孩子，被吓醒了”），觉得“养自己都养不活”。这形成了鲜明的代际差异和观念碰撞。

🔑 关键概念与技术解析

• Mihomo / Clash Meta： 一个开源的、基于规则的代理客户端，曾是Clash社区的主流分叉。因其强大的规则匹配引擎和广泛的社区规则支持而广受欢迎，但近期因性能和稳定性问题受到群友批评。
• Sing-box： 一个普遍认为架构更优、性能更稳定的代理核心，用Go编写。被多位群友视为Mihomo的替代品。
• suckless： 一个专注于编写简洁、高效、遵循“Keep It Simple, Stupid”哲学软件的社区和软件集合。其标志性软件包括 dwm、st、dmenu 等。群友提及用它来比喻将配置编译进二进制文件的思路。
• re2c： 一个用于生成快速词法分析器的工具。它允许将正则表达式编译成高效的确定性有限状态自动机（DFA），从而在运行时获得比传统的正则引擎高得多的性能。群友用它来类比将代理规则预编译成高性能C代码的思路。
• 远视储备： 儿童在生长发育过程中，眼睛存在一定程度的生理性远视，这便是“远视储备”。过早的近距离用眼（如看手机、宅家）会过早消耗掉这部分储备，导致近视风险急剧增加。这不是指视力本身，而是指眼睛抗近视的“buffer”。
• hyprland 配置改为 lua： Hyprland 是 Wayland 上一个极为流行的动态平铺窗口管理器。其配置语言从传统的 hyprland.conf（类似 Vim 或 i3 的格式）迁移到使用 Lua 脚本语言，意为用户可以编写更复杂的、逻辑驱动的配置，而不仅仅是静态的键值对。
• .icu 顶级域名 DNS 污染/恢复： .icu 是一个流行的顶级域名。事件指中国大陆因为“996.icu”等政治敏感原因，GFW（防火长城）曾一度对该后缀进行全域的 DNS 劫持/污染，导致国内无法访问。后恢复，用户需清理本地DNS缓存。

💎 碎片知识与金句拾遗

• 关于Windows： “这系统一开，能吃掉我18G内存。” “我efi留了双系统，现在我开都不想开。” “用上hyprland或者niri顺手很多。”
• 关于Linux桌面： “一鲸落万物生。”（指Wayland取代X11） “Wayland生态感觉缺乏灵性。” “Linux上缺乏UX/UI约束，没有约束，就拉低了下限。” “Linux上不应该有ui ux设计约束，那样就不自由了。” （产生激烈讨论的分水岭观点）
• 关于Claude Code的定价： “多改几次，把用户改没了，就好好跟它的企业客户玩去吧，世界离了谁都照样转。”
• 关于硬件/桌面生态： “st steam machine 2025规格，只有2.6kg，PS5是4.5。” 群内推荐笔电：ThinkPad X1 Carbon 2026（64+2T配置约25499元）和 Framework 13。
• 小米开发生态： 群友发现并分享了“小米Token Plan”，提供 700,000,000（7亿） token的免费额度。链接：https://100t.xiaomimimo.com/，群友表示申请后约1分钟即通过，引发了一波“薅羊毛”潮。
• 关于内向与成长： “我从0岁到18岁，每天都是爸妈陪我。18岁到22岁，每周回一次家。然而我还是很内向。” （推翻“陪伴就会外向”的简单论断）

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

1. flux / fluxway 项目（自律代理核心）

   • 研究价值： 该群友的计划直击了当前主流代理软件在算法层面的低效痛点。研究其如何实现“将配置编译为原生C函数”，并对比Mihomo的逐行扫描与Sing-box的Trie/AC自动机等匹配算法，极具工程实践价值。
   • 行动建议： 关注代理规则匹配的高性能数据结构（如：Radix Tree / Patricia Trie, Aho-Corasick算法）。研究 re2c 的代码生成原理。留意该群友后续可能在GitHub上公开的 flux 项目，或者查阅相关的技术博客，了解他如何解决“网络栈”的性能问题。

2. Hyprland 的 Lua 配置模式

   • 研究价值： 这是一个桌面配置领域从“声明式”走向“可编程”的重要趋势。研究如何利用Lua编写逻辑复杂的窗口管理行为（例如：根据当前工作目录自动调整布局、基于CPU温度动态改变配色等），可以极大拓展平铺窗口管理器的上限。
   • 行动建议： 阅读 Hyprland 官方Wiki中关于Lua配置的最新文档。尝试编写一个Lua脚本，实现根据当前运行的应用自动切换工作区并调整窗口大小。对比传统 hyprland.conf 与Lua脚本在复杂任务上的表现。

3. 小米开发者Token Plan的使用场景与限制

   • 研究价值： 这是目前国内大厂给出的非常慷慨的API Token（7亿token），背后很可能是调用其自研的大模型（如MiLM）。研究其能够在什么上下文中使用（例如：通过API调用、在哪个IDE中集成、是否支持RAG），以及其API的限制和定价模型，可以评估它作为一个性价比极高的第三方LLM服务源的可行性。
   • 行动建议： 立即申请该Token计划。研究其API文档，尝试通过OpenAI兼容的API格式调用。测试其在不同类型任务（如代码生成、翻译、长文本总结）上的性能、延迟和成本效益。重点研究它是否可以在本地使用 opencode 等轻量级AI Agent工具作为后端。