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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：Emacs 宠物挂件（Pets）与透明窗口的可行性之争

群内围绕 vritser 在 Emacs 中开发宠物挂件（Pets）遇到的技术难题展开了深入讨论，核心痛点集中在“透明窗口”的实现上。

• 问题本质：vritser 的宠物挂件基于 GIF 动画，但 Emacs buffer 无法实现真正的背景透明，导致挂件会遮盖下方文字内容。他感叹“透明、交互啥的没有原生的体验”，AI 助手也建议接入原生组件，让他觉得“不想搞了”。
• 群友方案：有人提出参考 etaf 的像素裁切功能——将 GIF 每行像素范围裁切，用文字覆盖非人物部分，实现“最大化近似透明”。但有人指出“纵向只能按行，裁剪也还是矩形的”，无法做到精确。更彻底的方案是“搞一个动态模块，把 child frame 的窗口句柄传给动态模块来做透明”，并提到 Windows 的“异形窗口”概念。
• 最终成果：vritser 晒出 macOS 上的 frame-transparency 补丁效果，群友反馈“我也用了，我适配了 Emacs master”。但大家一致认为“macOS 的支持还是好，windows 太垃圾了”，且“透明得底层搞搞”，难度较高。

专题：Rime 输入法 userdb 的进程锁与多设备同步冲突

围绕 Rime 的 userdb 为何需要进程锁展开辩论，核心分歧点是“同步是否会导致冲突”。

• 起因：群友抱怨“rime 的 userdb 为什么要加进程锁，好 sb”。κόσμος 解释这是 LevelDB 的限制，防止数据损坏。
• 冲突根源：roife 提出 Emacs Rime 与系统 Rime 同时运行时会因共享 userdb 而冲突。但 κόσμος 反驳称，真正的冲突只在“共享 LevelDB”时发生，跨设备同步（导出 txt 再导入）反而是最朴素的文件同步，不会冲突。
• 实际痛点：roife 回应“就是要同步手机和电脑上的数据啊，那不同步就不冲突，这有什么意义？” 最终引出“多 Rime 实例共存的解决方案”——“可以单独设置 userdir，这样 userdb 就是不同目录了”，这也可能是未来 emacs-rime 的改进方向。

专题：Emacs 的 GUI 与 TUI 之争——etaf 框架与 Canvas 的未来

围绕 etaf 框架的定位和 Emacs 未来方向展开，是全场最深度、最有前瞻性的技术辩论。

• etaf 的定位：作者表示“etaf 是基础框架”，擅长做 text UI，“属于降维打击”，但“目前做的偏向 GUI 的 app 是为了展示能力”。
• GUI vs TUI 的本质：有群友认为“表格这个东西太 GUI 了”“不想在 Emacs 里模拟 GUI”，但 etaf 作者回应“GUI 和 TUI 只是展现形式的差异，并不对立，本质的差别还是在能否全键盘方便的操作，以及融合 Emacs 的交互方式”。他举例“你这里的搜索框就挺多余的，我是倾向于能绑按键的都绑按键”。
• Canvas 的发布：群友确认“Canvas 已经发布了，不是在 master 吗”，但“要等到 32 得好久了，大概 2 年左右”。etaf 作者承认“等 Canvas 正式发布后肯定要换到 Canvas”，目前是过渡方案。
• 运行时统一问题：owdo 指出“渲染运行时和应用运行时还是有合并的可能”，但作者坚持“渲染运行时不建议和应用运行时合并”，因为 etaf 侧重前端，而 IM 需求对应用运行时要求更高，需要形成 convention。

---

🔑 关键概念与技术解析

• etaf：一个基于 Emacs 的 GUI 应用开发框架，支持复杂布局、动画、鼠标交互，可用于开发 IM 客户端、B站客户端等。擅长 text UI，但也能做 GUI 效果。
• frame-transparency 补丁：macOS 上为 Emacs 窗口提供透明支持的补丁，群友已适配 Emacs master。是解决宠物挂件透明问题的关键。
• userdb：Rime 输入法的用户词库数据库（基于 LevelDB），默认加进程锁防止损坏。多实例共享会导致冲突，可通过设置独立 userdir 解决。
• 异形窗口：Windows 上的一种窗口形状自定义技术，可让窗口非矩形，是透明窗口的底层方案。
• Canvas（Emacs 32）：Emacs 32 预计引入的原生 Canvas API，支持更强大的图形渲染，etaf 作者计划在未来迁移到该方案。
• moshi：群友提及的终端串流工具，近期不稳定，“tmux 会话都能串，错乱”。

---

💎 碎片知识与金句拾遗

• 关于 Twitter/Reddit：“twitter和reddit算是废了，不登陆连看都不让看”，有群友评价“这不就是 zhihu 开始死亡的特征么”。B站网页也一直强制登录，有人感叹“从 B 站开始收费的时候我就不用了，要么别承诺，要么遵守承诺”。小道消息称“这其实是一个 bug”。
• 关于 Emacs 输入法：“在 Linux 上不装系统的输入法，能不能靠 emacs everywhere 输入中文”，群友表示“邪修中，我也要搞这个”。有人指出“操作每多一步，人怕麻烦的心情就多一倍”。
• 关于 master 分支：群友普遍在用 Emacs master，“没有任何理由不去用 master，更多功能以及更多 bug 修复”。
• 关于 emacs31：“emacs31 给我体验很糟，刚发出来的时候我把配置迁移过去，配置都启动不了，而且 emacs31 还是不支持在终端里面输入中文”。
• 关于手机触屏 Emacs：“我的目标是在 android emacs 上面也能很好使用呢，这时按键就不是主力场景了”，有人建议“ctrl shift alt 都有粘滞键”。
• 其他金句：
  • “挂件不就是会遮盖后面的文字吗”——vritser 自嘲。
  • “等佬弄完，我就能凑上去用咯”——群友对开源协作的调侃。
  • “自从开始用仓颉就没同步过了”——实用主义者的选择。

---

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

• etaf-bili：https://github.com/emacs-taf/etaf-bili，基于 etaf 的 B 站客户端，可作为理解 etaf 应用运行时与渲染运行时分离的参考案例。
• matrix.el：https://github.com/emacs-apps/matrix.el，群友新推送的 Matrix 客户端项目，仍有“cargo.toml 需要自己改改”的遗留问题，值得观察其与 etaf 的融合。
• rime 多实例共存方案：通过为每个实例设置独立 userdir 解决 userdb 冲突，但配置同步仍需手动处理。etaf 作者 roife 的 emacs-rime 是否跟进值得关注。
• simpcc-mode：https://github.com/zHaOdANiuu/simpcc-mode，基于 Emacs 31 的新模式，群友分享后讨论较少，但可能是一个潜力包。
• 异形窗口动态模块：将 Emacs child frame 窗口句柄传给动态模块实现透明的思路，可能是 Windows 上宠物挂件的终极方案，但“透明得底层搞搞”，难度较高。

观点延伸

当天最值得咀嚼的，不是宠物透明、Rime 加锁或 Canvas 哪个功能更“酷”，而是同一个工程问题反复出现：当 Emacs 开始承载动画、输入法、聊天和移动端交互，边界必须先被定义——哪些属于渲染，哪些属于应用状态，哪些属于平台能力。边界不清，功能越多，越容易靠补丁堆出“能演示、难维护”的系统。

1. 透明问题的关键是降级路径

vritser 的讨论从 GIF 像素裁切一路走到 child frame、动态模块和 macOS 的 frame-transparency 补丁，说明“透明”并非一个开关，而是一组跨层能力。像素裁切可以做近似，child frame 可以隔离窗口，平台补丁才能接近真正透明；它们的成本和可移植性完全不同。工程上不应一开始追求桌面宠物级的完美效果，而应先写出降级矩阵：普通 buffer 是否遮挡文字、裁切误差能否接受、点击区域是否可靠、Windows 或终端上如何退化。这样才能判断是在解决产品需求，还是只是在追逐截图。

2. Rime 争论把同步和并发拆开

群里关于 userdb 的分歧，实质是两个问题被混在了一起：同一台机器上多个实例共享 LevelDB，这是并发写入和数据完整性问题；手机与电脑之间传递词库，则是状态同步和冲突合并问题。独立 userdir 能解决前一种隔离，却不会自动解决后一种“谁覆盖谁”。导出 txt 再导入很朴素，但仍需明确权威设备、同步时机和双端同时修改的处理方式。否则“没有数据库锁冲突”不等于“同步方案可靠”。

3. etaf 的价值在交互语义，不在 GUI 外观

GUI 与 TUI 的争论，最终落在一个更有用的判断上：搜索框、翻页按钮、表格是否合理，不看它们像不像网页，而看它们是否融入 Emacs 的按键、minibuffer、鼠标和触屏。把渲染运行时与应用运行时分开，也是在保留这种选择：同一份状态和事件逻辑，可以有不同呈现。Canvas 是未来的渲染能力，但不能替应用设计交互约定。

可继续研究/实践

为这三类功能各写一份最小验收表：宠物测遮挡、帧率和点击；Rime 分别测本机多实例与跨设备同步；etaf 用键盘、触屏和多 buffer 跑同一流程。能被重复测试的“哲学”，才是可维护的工程判断。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题：Emacs 生态中的 IM/聊天客户端演进

群内围绕 Emacs 的聊天客户端展开了多次讨论，从 telega 到 elneo 的迁移成为关注焦点。

关键讨论点：

• telega 用户迁移到 Matrix：Evgeny Zajcev 分享了他将 telega 的 UX 理念迁移到 Matrix 客户端的经历。他坦言"haven't been using telega much lately - telegram is bridged into my matrix"，并通过构建 elneo 项目，保留了 telega 的关键键位绑定，同时改变了不喜欢的部分。
• 公共框架需求讨论：有人提议"lucius啥时候出手，提取一个公共框架"，但回应是"主要是没什么需求"，指出"提供开源的也就 tg，matrix 我不用，wechat 和 qq 需要逆向"。Discord 被提及但"官方是不欢迎第三方客户端的"。
• Matrix-Telegram 桥接问题：owdo 发现了 Matrix 与 Telegram 之间的桥接 bug（图片+文本消息在 Telegram 端丢失文本），引发了对桥接源码的调查（涉及 mautrix/telegram 和 t2bot/mautrix-telegram），最终确认是桥的问题而非 telega 问题。
• elneo 发布：Evgeny Zajcev 宣布将 elneo 从 .emacs 中剥离并正式发布：https://github.com/aard-fi/elneo

各方观点：

• 有人感叹"审美不如"、"关关 line number, 修修 fringe char"，关注 Emacs 的视觉细节。
• 对 Discord 的第三方客户端限制表示遗憾："以前用得最多的是 whatsapp, 但也锁得很死"。
• "这个合并了啊，值得开心的，起码等了2年半了"——提及某个等待已久的功能合并。

专题：远程 Claude 代理机器的商业模式

群内对基于 Mac mini 的远程代理服务（如 agent.space）展开了深入讨论。

核心讨论点：

• 有成员分享 https://agent.space/zh-hans/mac 和 https://quickservers.net/mac-mini-hosting#plans 这类服务。
• 价格讨论：丐版 $160/月，"一个月的价格够买一个 20x claude 了"。
• 商业模式分析："现在这些套餐像是下套的"，但"包含 claude token 的套餐"（类似 amp）被认为可行。
• 被封风险讨论："多的话，会的"、"得控制 tps"、"别狠狠蹬，留点余量大概可行"。
• 有人提出更聪明的方案："甚至他们可以用虚拟主机的方式来动态配置"，"对于用量小的用户，把部分性能挪出来"，"都不要三个月就能回本"。
• 技术质疑："macos 对远程并不友好"、"ssh 都是默认关闭的"、"macos 远程甚至有配置不让改"。

专题：AI 时代硬件价格与消费心理

从笔记本价格到内存价格，群内展开了一场关于 AI 时代硬件消费的讨论。

关键观点：

• "这年头 32G 16村笔记本还有推荐吗"——6K 预算只能买到 16GB，引发"内存真贵啊"的感慨。
• 有人花了 6100 买 thinkbook16 后吐槽："这💻 4500 才是合理价格"。
• lucius 分享自己的 T14p 配置（U9 285H 32gb 1tb 3k屏幕），购买时 7800，现在补贴后 11076，感叹"太可怕了"。
• "双11都是先涨价做活动，当年的国补反而是最实在的"——多年消费经验的总结。
• mac mini M4 16GB 机器 4600，"160美元等于1255，三个半月就可以回本"——对比远程代理服务价格。

专题：开源维护困境与 Wayland 生态

hyprland 的 issue 处理问题引发了开源维护讨论。

讨论要点：

• "hyprland 提 issue 也很麻烦"，有人吐槽"色彩管理没人修"。
• 维护者现状："维护色彩的那个已经不维护了，不用 hyprland"，"其他人应该也不懂"。
• 资金讨论："hyprland 有资金支持吗"——"有的"、"dhh 不就支持了"，但"那 issue 处理不及时感觉不太应该"，"拿钱干活是不是🤔"。
• 有人提到"我老老实实用 openbox 了，kde 6.8 放弃 x11 了，悲"。
• Wayland 进展："wechat 也支持 wayland 了，很舒服"，但"wps 到现在都没有 wayland 支持，这算是信创最重要的一个环节吧"。

---

🔑 关键概念与技术解析

• elneo：Evgeny Zajcev 开发的 Matrix 客户端，采用"server using upstream libraries"策略，保留 telega 的键位绑定。这是 telega（Emacs Telegram 客户端）的 Matrix 变体。https://github.com/aard-fi/elneo

• telega-bridge-bot.el：telega 的 bridge 机制，用于将 Telegram 桥接到 Matrix 等平台。owdo 遇到的"图片+文本消息在 Telegram 端丢失文本"问题源于桥的实现。

• mautrix/telegram 与 t2bot/mautrix-telegram：Matrix-Telegram 桥接的两种实现。群内确认了 owdo 使用的桥是后者（基于 bio 链接判断）。

• disco.el：https://github.com/emacs-apps/disco.el，emacs-apps 组织下的项目。有人回应"我已经有公共框架了"并指向该组织，说明这是某种公共框架的尝试。

• agent.space / quickservers.net：提供 Mac mini 远程托管的服务商，通过 GUI 虚拟化（"现成的 gui 基建"）让用户远程使用 macOS 机器，常用于运行 Claude 代理。优势是"uu 远程直接过去就是大家熟悉的"界面。

• 视频按帧切图播放技术：有人询问视频播放支持，回应"把视频按帧切为图片，再通过图片的按帧增量更新来实现播放"——一种通过图片序列模拟视频播放的方案，可能用于特殊渲染环境。

---

💎 碎片知识与金句拾遗

• 冷泡茶智慧："7窨茉莉花半斤 100"、"每次冲它一瓶的量可能只要几毛钱"、"可以直接丢进矿泉水瓶，晃一晃静置1-2小时，就是好喝的茉莉花茶了"。这是对东方树叶这类高价瓶装茶的理性替代方案。还有"我是泡陈皮"和"保温杯泡淡一点的红茶"的建议，以及"单丛不适合空腹喝，容易醉茶"的警告。

• 关于开源贡献与 AI 分红："ai 如果赚钱的话应该给所有的开源代码贡献者提供分红吧"——"怎么可能"，因为"我用 ai 分分钟就能把一个开源功能，换个语言，换种写法来写，这个时候还怎么算？"

• Git 提交的 Co-authored-by 彩蛋：有人分享了一个极其夸张的 commit 信息，将 GNU nano、Ghostty、zsh、Git、OpenSSH、GnuPG、Wayland、wlroots、Mesa、systemd、Linux 等几十个项目列为 Co-author，结尾"Godel's Incompleteness Theorems (some documentation will remain unprovable)"，堪称开源幽默的巅峰。

• zcode 的隐私问题："zcode 这种嘴上说开源，搞 ab 版，静默上传用户仓库的软件我已经卸载了"——对某款"开源"软件的不信任。

• "Emacs 是谁的下位"：有人吐槽"ob 真的是 Emacs 的下位啊"，引发"Emacs 是谁的下位 🤪 VSCode 吗？"的调侃，最终回答："冯诺伊曼机的下位"。

• AI 对话的无奈："为啥 gpt 每次对话结束总是反问一下，md 脑子有坑"——对 AI 对话模式的吐槽。

• 外贸行情："9 月中国经济成绩单……外贸继续一枝独秀、一骑绝尘"、"做外贸的是不是赚麻了"，但"这钱显然跟普通从业者没关系"；"看到有跟俄罗斯做汽车订单的，一年几百万收入，不过要会俄语和客户的信任"。

• "现在也是赚的信息差的钱"——对远程代理机器服务本质的判断。

• "被驯练了🫠"——"现在看这种 ai 文感觉都能反应过来 ai 想说啥"，对 AI 生成文本模式的敏锐感知。

---

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

• elneo 项目（https://github.com/aard-fi/elneo）：Evgeny Zajcev 的 telega-like Matrix 客户端，值得关注其"server using upstream libraries"策略，以及 telega 键位绑定在 Matrix 场景的迁移方案。

• emacs-apps 组织（https://github.com/emacs-apps）：有成员声称"我已经有公共框架了"，暗示该组织下存在某种统一框架（如 disco.el），值得深入探索其架构。

• 远程 Mac mini 托管服务的虚拟化技术：群内讨论揭示了"虚拟主机方式动态配置"的可能性——"一个虚拟主机对应一个公网 ip，对于用量小的用户，把部分性能挪出来"，这种技术路线如果成熟可能颠覆传统 VPS 模式。

• 视频按帧切图增量更新播放方案：虽然细节未展开，但这一技术可能适用于特定场景（如 Emacs 内的视频播放或远程 GUI），值得深入研究。

观点延伸

中心判断：当天最值得咀嚼的，不是某个客户端或某种远程机器的“好不好用”，而是边界一旦被隐藏，系统的真实成本就会转移到用户和维护者身上。

1. Emacs 客户端的核心不是“支持多少平台”，而是能否守住一套稳定的交互语义

elneo 的出现说明，telega 真正可迁移的部分并不只是 Telegram 协议，而是它对消息、列表、跳转和键位的整体组织方式。把 Telegram 桥接进 Matrix，再在 Matrix 上复刻 telega 的 UX，本质上是在做“协议替换、交互保留”。这比单纯再写一个聊天客户端更有价值：用户迁移的是工作方式，而不是某个服务商。

但当天关于“图片加文本在桥的另一端丢失”的排查，也揭示了另一面：一旦系统由多个客户端、桥接层和服务器组成，问题就不能再按“哪个界面坏了”来判断。消息是否完整，应当成为桥接层的可验证契约，而不是靠用户偶然发现。图片、文本、回复关系、编辑和线程，都应该有最小回归用例。否则“公共框架”越抽象，故障归因越困难。真正值得建设的公共框架，不是把代码集中起来，而是把跨平台语义和测试边界固定下来。

2. 远程 Mac 代理服务卖的不是机器，而是身份、额度与风险的打包

群里把每月 160 美元与一台 Mac mini 的价格放在一起比较，直觉上像发现了一个简单的回本模型；但这个模型成立的前提远不止硬件折旧。真正稀缺的可能是稳定的服务资格、可持续的使用额度、网络出口、隔离能力，以及平台封禁后的损失承担。

“几个人共用”“控制 TPS”“给低用量用户动态挪性能”听起来像 VPS 的超售逻辑，但 AI 服务的限制往往与账号行为、请求模式和责任归属绑定，不是单纯的 CPU、内存切片。共享越充分，单位硬件收入越高，同时也越难回答：谁造成了风险，谁承担恢复成本，怎样证明没有越过服务条款。于是，这类生意的核心不是有没有 GUI 基建，而是能否把租户隔离、用量计量、异常停用和合规边界做成产品能力。没有这些，所谓“信息差”更像把不确定性转卖给客户。

可继续研究/实践

可以分别为 elneo 或现有桥接链路建立一组“消息语义回归测试”，覆盖图片、文字、回复、编辑和多端往返；也可以给远程代理服务做一张不含营销话术的单位经济表，至少列出硬件成本、有效占用率、服务额度、网络与维护成本，以及封禁或退款的最坏损失。能经得住这两张表的方案，才值得继续投入。