Geekinney

外观

Emacs 社区日报 2026-06-20

约 3002 字大约 10 分钟

2026-06-20

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

Emacs 社区日报 2026-06-20 手绘图
Emacs 社区日报 2026-06-20 手绘图

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题：dirvish 的未来与Emacs社区的分叉活力

背景与痛点： 群成员注意到知名文件管理器 dirvish 的作者已一年未活跃，引发对其维护状态的担忧（“悲”）。有成员指出作者此前有过类似的长久消失后短暂回归的模式，推测为工作繁忙。 社区反应与解决方案： 社区表现出了典型的开源生态应对机制——已有用户 fork 了代码库并开始接受 PR，证明了项目的去中心化韧性。群友们分享了活跃的 fork 地址：https://github.com/latiagertrutis/dirvish，并围绕此展开了对 GitHub PR 审查体验的吐槽（“真的很痛苦”）以及对 forge/magit-forge 等工具辅助 review 的讨论。

专题：Emacs 内网页浏览工具的选择与痛点 (eww 与稳定性问题)

讨论焦点： 对于 gptel 中通过 eww 打开网页的功能，有成员虽然赞叹其“超模”，但系统性地批评了 eww 的体验。核心痛点包括：

  • 渲染问题： 不适合现代网页，样式错乱，对 Paul Graham 博客这类纯文本网站尚可，但现代网站“太慢了”。
  • 性能问题： 加载速度不理想。
  • 方案对比：
    • 反对派： 建议加装 readability 或用 Firefox 提取正文功能解决，但有成员认为过于复杂，不如直接用 Xwidget。
    • 效率派： 认为 AI 时代应直接通过 gh cli 操作，让 Agent 自动拿 Issue 并解决，无需人工通过浏览器 review。
  • 意外发现： 成员还提到了终端模拟器 ghostel 和 foot 都存在 resize 窗口时 prompt 换行/重复的 bug，而 kitty 不存在此问题，引发了关于 terminal 渲染稳定性的讨论。

🔑 关键概念与技术解析

  • dirvish: 一个 Emacs 下的现代化文件管理器，以美观的界面和丰富的功能著称。当前处于作者暂停维护的“休眠”状态，但存在活跃的社区 fork。
  • eww: Emacs Web Wowser，Emacs 内置的纯文本网页浏览器。优点是完全集成在Emacs生态内，缺点是现代网页支持极差（JS、复杂 CSS 渲染能力弱）。
  • gh cli: GitHub 官方命令行工具。在本群语境中用于绕过 GUI 审查流程，通过终端直接对 PR 进行自动化评论或操作，适合 AI Agent 调用。
  • magit-forge: magit（Emacs下的Git客户端）的扩展，允许在Emacs内查看和操作GitHub Issues/PR。优点是可本地review，缺点是无法直接查看 GitHub Actions 状态。
  • starship: 一个跨 Shell 的提示符（prompt）配置框架。讨论中提到其在 resize 时 prompt 渲染可能出错（右对齐问题），有成员因此考虑更换配置。
  • eglot: 一个 Emacs LSP 客户端。讨论中涉及两个待改进点：1) 对 UTF-8/ASCII 文件名支持不佳（有成员因此“粉转黑”）；2) 希望作者增加对代码 folding（折叠）Range Text 的支持，使 Emacs 成为唯二支持此 LSP 特性的编辑器之一（与 Neovim 并列）。
  • hideshow: Emacs 内置的代码折叠功能，通过 hide-show.el 实现。群友分享了一个 Reddit 帖子展示其优秀用法，被认为是“被低估的内置功能”。

💎 碎片知识与金句拾遗

  • 关于代码审查工具： “AI 时代不应该直接接入 gh cli 么” → “能啊，让AI给你调用就行 帮我使用 gh cli review #123 PR”。 典型的“凡事先让AI跑个流程”硬核思路。
  • 关于Terminal Resize Bug： “就是resize窗口会让之前显示的prompt换行，然后在刷新的时候刷出来的prompt是在新行显示的，然后就会重复。” 一段精确的bug复现描述，并附赠了一句赞美：“这是feature：‘孙悟空的技能特效’”，充满了极客的自嘲幽默。
  • Emacs 内置魔法： “太赞了，这多省事儿啊” → “我贴的帖子中的那个我觉得比较好，也不会出现忽略掉的问题，结构还在”。 此处指的是 hideshow 内置折叠功能的优雅实现。
  • 简单实用的想法： “想做一个 esh-tldr” → 一个未实现的点子：在Emacs Shell中集成 tldr（简化版man）命令，简化命令行学习，体现了“Eat your own dog food”的产品思维。

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

  1. dirvish 的活跃 Fork： github.com/latiagertrutis/dirvish 。建议检查该 fork 的 PR 与改动记录，可作为项目临时维护的参考。
  2. Emacs LSP 折叠支持（Range Text）： 关注 eglot 或 lsp-mode 关于添加 textDocument/foldingRange 支持的讨论。Reddit 帖子 https://www.reddit.com/r/emacs/comments/1uafbsn/underappreciated_emacs_builtins_hideshow_60/ 提供了基于内置 hideshow 的优秀实现思路。
  3. Emacs 内的 SVG 渲染： 群友分享的 Reddit 帖子展示了 Emacs 中通过 SVG 进行力导向图的渲染，虽然需用 overlay 交互性略差，但视觉效果炫酷，值得探索其在数据可视化或交互式文档方面的潜力。链接：https://www.reddit.com/r/emacs/comments/1u9vvt3/emacs_svg_rendering_in_force_directed_graph_sims/。

Emacs 轻聊讨论组

好的，各位。这是根据今天（2026年6月20日）社群讨论提炼的知识快照。今日讨论内容相当丰富，跨越了AI应用、系统设计哲学、开发者工作流等多个硬核领域。

🎯 核心热点与专题探讨

专题：通往“App中心”交互的极客之路

本次讨论的核心热点源于一位群成员（有多年macOS使用经验）在Linux环境下对窗口管理的深度抱怨与探索。这并非简单的“Linux vs macOS”之争，而是一场关于“界面交互第一性原理”的深度技术思辨。

核心痛点与协同解决方案：

  1. 痛点定义：

    • “窗口中心” vs “应用中心”： Linux桌面环境（DE）如Hyprland的Tiling Window，以“窗口”为第一公民进行管理。而macOS的内在逻辑是以“App”为中心，管理的是App的启动、隐藏、聚焦，窗口只是其属性。这导致从macOS切换过来时，管理粒度错位，心流被打断。
    • “Workspace沙盒”的反感： 发起人明确表示“很讨厌多个Workspace”，希望通过一次性按压（如 Tab+字母 ）直接弹跳到需要的App，无论它在哪个虚拟桌面。
    • 效率至上： 追求“下意识”的肌肉记忆切换，认为 rofi 或 Alfred 式的检索（还需输入/选择）在应对高频App时，仍比直接绑定快捷键慢一步。

  2. 社区提供的解决方案与思路：

    • 现状模拟与脚本化： 多位群友指出，现代Wayland合成器（如Hyprland, Niri）已经提供了足够强大的IPC（进程间通信）接口和窗口属性（如 appid, focusHistoryID）。
      • “最后聚焦”策略： 对于快速切换，可由脚本根据 appid 获取该App的窗口列表，默认聚焦 focusHistoryID 最近的窗口，解决了多窗口跳转的模糊性问题。
      • 社区代码资产： 群友 0WD0 分享了其用 Clojure (Babashka) 编写的脚本（hyprland.el项目的一部分），展示了如何通过 hyprctl 实现精确的聚焦/启动/隐藏逻辑，并给出了核心函数。这证明在现有技术栈上“模拟”App中心行为是可行的。
    • 底层重构： 另一位群友提出是否可以直接 “Vibe 一个 DE”，并指向了 river 这个“只负责管理窗口，不负责其余任何逻辑”的最小化Wayland合成器。其思路是放弃现有DE的复杂抽象，直接基于river的底层库，从零编写一套纯粹的“按键绑定-动作执行”逻辑，完美复刻macOS式的交互。

观点总结： 讨论最终指向了“Gap”的存在——现有Linux DE（哪怕是最极简的平铺WM）仍是在“窗口”的抽象层上进行增强，而难以原生地提供“App”层级的抽象。 弥补这个Gap的方案分为两种：在现有系统上通过脚本“打补丁”，或者从底层构建一个以App为核心的合成器。这是一个极客社区对软件交互本质的自我追问与实践。

🔑 关键概念与技术解析

  • GLM-5.2： 智谱AI发布的新一代大语言模型。群内讨论关注其在不同平台的表现差异，认为“百炼”平台（阿里云）提供的版本“更会思考”，优于“火山”平台。在OpenCode中体验良好，但被评价为“不是多模态”且订阅额度紧张。
  • Hermes： 一款用于管理知识库的开源工具。在讨论中被提及可用于处理 org-mode 文件，但需要人为设定处理规则，且AI生成的“味太重”，仍需人工审核和二次加工。
  • Hyper Key： 一种键盘映射概念，即将一个不太常用的修饰键（如Caps Lock或Tab）映射为一个“超级键”，然后与普通字母键组合，形成海量的自定义快捷键。本文中用于实现 Tab+字母 快速启动/切换App。
  • appid / focusHistoryID (Wayland相关)： appid是Wayland协议中用于标识一个应用程序的ID（类似X11的WM_CLASS）。focusHistoryID是某些合成器（如Hyprland）为每个窗口维护的聚焦时间戳索引。这两个属性是实现“App中心”管理脚本的关键。

💎 碎片知识与金句拾遗

  • Markdown渗透：“感觉支持markdown也算是大势所趋了, 连微信都支持了（虽然只在bot页面）”
  • 对AI基础设施化的向往：“去见证 AI 成为和电力一样的基建的社会”
  • Agent自主性的惊悚一刻：“我去，我的agent学会调pkexec来找我要root权限了”
  • 对“窗口中心”的精准吐槽：“我需要操控的是 app，而不是窗口，以 app 为中心操控他的启动、隐藏、窗口数量多少、窗口尺寸”
  • 来自Mac用户的Linux使用阻力：“这个是我没有完全切 Linux 的一个重大的阻力（窗口管理）”
  • 知识管理的清醒认识：“毕竟代码能跑就行，文字这东西本身就是思想和表达”；“ai的味儿太重，不足以用来做笔记，需要自己再加工一遍”
  • 硬件vs场景的幽默：“买这么一屋（GPU服务器），都购买一部车了”；“比例不太对，而且这么放的话人怎么出去”
  • 对Nix生态的评价：“nixpkgs还是太权威了，什么包都敢打”
  • 关于Web复古风格UI的讨论：有群友分享了一个Web UI风格，被认为难以用现代前端框架实现，但可以用CSS渐变+噪声纹理模拟。有人表示“看起来很累”，也有人认为这是“新时代的梦想”。

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

  1. river Wayland合成器： (https://codeberg.org/river/river) 一个极具极简主义风格的动态/平铺Wayland合成器。社区认为其“只负责窗口管理”的架构，非常适合作为构建自定义、以“App为中心”的交互方式的底层基础设施。值得深度研究其API和插件系统。
  2. Hyprland IPC 与自定义脚本： 群友0WD0分享的脚本和思路（通常Clojure + Hyprland DIPC）是一个极佳的起点，展示了如何用高级语言触达底层窗口管理。研究hyprctl和Hyprland的socket通信方式，可以打造一个完全符合个人心流的顶级工作流。
  3. OpenCode + GLM-5.2： 体验在OpenCode这种AI编程IDE中运行GLM-5.2，并对比在不同云平台（百炼 vs 火山）上的表现差异。思考模型额度与实际使用的性价比。