Geekinney

外观

Emacs 社区日报 2026-04-25

约 4403 字大约 15 分钟

2026-04-25

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

Emacs 中文讨论组

🎯 核心热点与专题探讨

专题一：Emacs 编辑器生态的“调教”哲学——从启动速度到视觉舒适度

群内关于 Emacs 的讨论呈现出两极化的专业深度：一端是追求极致性能的 启动加速 优化，另一端是关乎日常体验的 主题配色与视觉健康。

  • 启动性能优化（Startup Profiling）：有成员分享了从 package.el 迁移到 elpaca、AOT 编译、生成 autoloads.el 等一系列激进的优化手段，但测试后发现启动时间不降反升。这引发了关于“优化陷阱”的讨论。核心观点是，Emacs 设计为持续运行的 GUI 进程，重启次数极少，因此花大精力优化启动时间（特别是 init time）的边际效用很低。建议使用 use-package-report 或 esup 等工具精准定位瓶颈，而非盲目搬用所有优化技巧。痛点：复杂的优化方案可能引入意想不到的性能开销，不如保持轻量配置或直接修改后再重启测试。
  • 视觉健康与主题选择：围绕 modus theme 的高对比度引发的“飞蚊症”和眼部不适感，群友展开了激烈讨论。
    • 观点 A（高对比度派）：认为高对比度让文字更清晰，减轻眼睛负担，尤其适合阅读代码。
    • 观点 B（低对比度派）：认为高对比度在暗色背景下过于刺眼，容易导致视觉疲劳和散光加重，建议使用如 ayu-dark、Catppuccin、doom-tomorrow-night 或 Gruber Darker 等柔和主题。
    • 解决方案：除了更换主题，还提到了手动调低亮度（通过混合黑色降低整体亮度）和通过医用手段（如眼板腺按摩、使用人工泪液）来解决干眼症状。金句：“不同的人眼睛状况不一样。可能最好的办法是保持室内晚上也足够亮然后一直用亮色主题。”

专题二：Linux 发行版选择与哲学——Arch Linux 的“幸存者偏差” vs. 稳定派的“长期主义”

这是群内最激烈、最具深度的讨论，核心是 滚动更新（Rolling Release） 与 稳定版（Stable Release） 的优劣之争。

  • Arch Linux 捍卫者（滚动派）：
    • 核心论点：长远来看，Arch 是最不折腾的发行版。因为它将升级风险分散到每一天（甚至每周），避免了 LTS 版本大版本升级时可能出现的系统级“地雷瞬间引爆”。每次滚动的风险可控、问题可定位（局部炸裂而非全局崩溃），且享受最新软件生态。
    • 反驳点：对方认为 Arch 的“每天/每周滚”本身才是最大的折腾。每次装新软件前都可能需要先滚一下系统才能安装，这打断了工作流。此外，Arch 维护者只维护最新版，迫使你必须接受每一次“软件宝宝”的成长（Breaking Changes）。
  • 稳定派（Debian/NixOS 支持者）：
    • 核心论点：不升级才最省心。专注于当前工作的稳定性，不必为软件的 ChangeLog 投入心力。一个稳定的 LTS 系统（如 Debian）可以保证几年内软件包依赖关系不变，安装任何软件都无需担心冲突。即便个别软件需要新版本，也可以通过自行编译或 distrobox 等方案解决，而不是绑架整个系统去追新。
    • 反击：他们认为 Arch 的“反向入侵”太强，大脑会被迫养成了“必须关注更新”的习惯，这是一种精神负担。而 NixOS 虽然也是滚动更新，但其声明式配置和回滚机制允许你稳定地、按需地选择是否更新，既保证了系统新鲜度，又提供了容错空间（尽管 Nix 语言本身也是学习曲线）。
  • 结论与洞察：讨论最终没有分出胜负，但揭示了一个深刻的现实：系统的选择背后是个人对“确定性”与“新鲜感”的不同偏好。没有完美的发行版，只有最适合你工作流和风险承受力的选择。SteamOS 被推荐为“最不折腾”的 Linux 发行版（A/B 升级 + 只读分区）。

🔑 关键概念与技术解析

  • webkit2gtk vs. webkit2gtk-4.1：WebKit2GTK 是 GNOME 环境下常用的网页渲染引擎（用于 Electron 类应用等多个场景）。webkit2gtk 和 webkit2gtk-4.1 是两个大版本。从聊天记录看，旧版 webkit2gtk 在 Arch 上编译困难，卸载旧版只保留 -4.1 新版本是一个常见的解包编译依赖问题的技巧。
  • modus theme：Emacs 的一个高度注重对比度和可读性的主题系列。其核心特点是极高的对比度，这让部分用户感觉“刺眼”、“有飞蚊症”，但也有人认为是“最好的亮色主题”。
  • use-package-report：Emacs 内置的 package manager use-package 提供的一个功能，可以输出每个包加载所消耗的时间，用于调试 Emacs 启动速度。
  • esup：一个用于统计 Emacs 启动时各个阶段运行耗时的外部插件。虽然聊天中提到它“好多年没有更新了”，但它在老用户中仍有口皆碑。
  • AOT 编译（Ahead-of-Time Compilation）：在 Emacs 语境下，指的是使用 native-comp 功能，在安装包时就把 Elisp 代码编译为机器码，以避免运行时动态编译（JIT）带来的开销。理论上能提升响应速度，但需要更多磁盘空间和构建时间。
  • eld / elpaca：Emacs 的包管理器。eld 是 Emacs 内置的，elpaca 是一个新兴的、注重异步和性能的第三方包管理器（替代 straight.el 和 use-package 等）。
  • AppImage：一种 Linux 下的便携式软件打包格式，将软件及其依赖打包成一个镜像，无需安装即可运行。聊天中提到在 NixOS 上运行 AppImage 可能遇到缺少共享库（so）的问题，需要使用 appimage-run 工具。
  • distrobox：一个强大的工具，允许你在任何 Linux 发行版中创建和运行其他发行版的容器（如 Debian/Ubuntu 容器），从而无缝使用不同发行版的软件包，解决了单一发行版无法满足所有软件需求的痛点。

💎 碎片知识与金句拾遗

  1. Emacs 性能调优的终极秘诀：“优化也没啥用，包的性能太差只能选择不用” 和 “加载的时候喝口咖啡，就快了🌚”。（幽默地揭示了边际效用递减）
  2. 关于眼睛健康的实战经验：“我之前也是，眼睛看电脑后还会模糊。建议你去看看眼科。如果是干眼症的话，做下眼板腺按摩再滴点人工泪液就会很舒服。” —— 将极客社区的关切从代码延伸到了生理健康。
  3. 对 macOS 祛魅后的思考：“我现在对macos也祛魅了。下一次买电脑，我估计不买macos，然后进入linux世界。但我也不会去搞archlinux。不完美主义，太耗时的我不折腾，适度折腾。” —— 体现了“适度折腾怡情，过度折腾费命”的成熟极客心态。
  4. AI 生成代码的讽刺批评：“是真的，你看现在的google的产品有多难用就知道。” —— 针对“谷歌70%代码由AI生成”的传闻，犀利地指出了代码质量与用户体验之间的潜在冲突。
  5. 一个有趣的 Rime 输入法使用技巧：“可以考虑禁用macos的英文输入法，只用rime的英文。” —— 使用一款输入法统一处理中英文，可以避免不同输入法之间的切换冲突和特性差异。
  6. 硬件与发行版的权衡：“我这次是为了整一个无风扇的才搞了 mac （”—— 硬件需求驱动软件选择。
  7. 关于“软件宝宝”的比喻：“用Arch岂不是把软件当成了人类宝宝来养护，软件的ChangeLog是它的成长线，Arch维护者几乎不遗漏软件宝宝的成长细节……你们在电脑里 鸡娃，鸡软宝。” —— 极其生动地描述了滚动更新的维护状态。

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

  1. Emacs 启动配置性能分析工具：

    • 研究点：虽然 esup 较老，但可以尝试使用 M-x benchmark-init-show-durations-tree（如果已安装 benchmark-init 包）或命令 M-x elp-instrument-package 等替代方案。深入研究如何使用 elpaca 的 :defer、:demand 键以及 gc-cons-threshold 的环境变量来精准控制加载时机。
    • 行动建议：运行 M-x use-package-report 分析自己的配置，找出加载时间最长的Top 5包，逐一优化其加载方式（如按需加载、延迟加载）。不要盲目复制别人的优化，要基于自己的 profile 数据。

  2. NixOS 的非标准软件运行方案：

    • 研究点：聊天中提到 NixOS 上运行 AppImage 困难。深入研究 nix-shell 与 steam-run（Steam Runtime）或其替代方案 nixGL/nix-gui。了解一下 distrobox 的具体使用（它本质上是一个包装了 podman/docker 的工具），以及如何用它来无缝运行 GUI 应用（通过 X11/Wayland 的 socket 共享）。
    • 行动建议：在 NixOS 上安装 distrobox，创建一个 Fedora/Ubuntu 的容器，并尝试在其中安装一个原生不支持的闭源软件或一个需要特定旧版 glibc 的二进制。体验容器内外的流畅文件与剪贴板共享。

  3. Emacs 上使用 AI 辅助配置：

    • 研究点：聊天中提到“Nixos 我都让AI配了”，但 Emacs 本身也可以接入 AI。研究 Emacs 的 AI 插件生态，如 gptel（支持多种后端）、copilot.el（对应 GitHub Copilot）或 llm 库。探索如何用 AI 帮助排查配置错误（如：将编译错误或启动报错粘贴给 GPT 请求解决方案）。
    • 行动建议：在 Emacs 中安装 gptel 包，配置好你的 API Key（如 OpenAI/Claude），并向它提问“我的 use-package 配置中关于 lsp-mode 的延迟加载为什么会失败？” 或 “如何用 elpaca 替代 straight.el 管理我的包？” 体验 AI 帮你写配置的便利与局限性。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题：NeoEmacs 的“All in Rust”重构与跨平台编译挑战

这是本日最核心的讨论，围绕着 NeoEmacs（一个用 Rust 重写的 Emacs 兼容实现）的编译、运行与依赖问题展开。多位群友参与了从源码构建到调试的全过程。

核心痛点与解决方案：

  • 编译依赖问题（macOS）： 群友在 macOS 上尝试编译时遇到 gmp 库链接失败的问题。定位到 gmp-mpfr-sys 与 Homebrew 的 gmp 包的关系，通过 brew --prefix gmp 获取路径并提 issue 解决。
  • .elc 文件生成与版本兼容性： 构建成功后运行的 neomacs 找不到 .pdump 文件和报错，最终定位为 .elc 文件需要使用特定版本的 GNU/Emacs（分支 705c0e3）生成，而不是随意版本。项目维护者意识到需要让 NeoEmacs 自己生成 .elc 文件以消除对外部 Emacs 的依赖，实现真正的“自举”。
  • --release 构建耗时： 因为需要执行 LLVM LTO（链接时优化），cargo xtask fresh-build --release 执行非常慢（十几分钟），群友直接等待编译完成，体现了对项目的热情。

关键对话还原：

“我知道了，我要改一下。neomacs 会加载 .elc 文件，.elc 文件是用 gnu/emacs 生成的。我要改一下，让 neomacs 去生成 .elc 文件。” —— @eval_exec（维护者） “All in Rust 了吗?” —— 群友提问 “是的。” —— @eval_exec（维护者）确认了这一目标，宣告核心架构彻底脱离 C 语言依赖。

专题：Markdown 文档的下一代范式——从 KaTeX 到 MDV

讨论呈现出两条并行的探索路线：深度定制编辑器的公式渲染 与 文档即产品的极简可视化。

  • 路线 A（编辑器层）：KaTeX/LaTeX 后端抽象 群友描述了在 Emacs/NeoEmacs 中构建一个通用的 LaTeX 渲染后端（latex -> dvi -> svg），并计划与 KaTeX/ratex 后端合作，通过“一点点 elisp”即可让其它 major-mode 切换使用任意后端（typset / latex/ katex）。核心思路是“可插拔的数学公式渲染引擎”。

  • 路线 B（文档元语言层）：MDV 的兴起 群友分享了 MDV（Markdown Visualization）项目：它利用 Markdown 的极致简洁性，在纯文本内构建数据可视化文档，不依赖复杂框架，强调“文档即产品”。有群友评论：“它不炫技，而是在效率与表达间找到最优解。” 这引发了对 Markdown 生态边界的重新思考。

🔑 关键概念与技术解析

  • NeoEmacs / Neomacs： 一个用 Rust 从头开始重写 Emacs 编辑器核心的项目，目标是实现完全“All in Rust”。它拥有独立的渲染引擎（neomacs-layout-engine）、WGPU 支持的图形栈。目前的编译流程仍依赖一个特定版本的 GNU/Emacs 来生成 .elc（Emacs Lisp 编译文件）。
  • .pdump 文件： NeoEmacs 启动时加载的“便携式转储”文件。它通过加载并序列化一个已经初始化的 Emacs 会话状态来加速启动，是 NeoEmacs 项目中的重要机制。
  • cargo xtask fresh-build： NeoEmacs 的自定义构建命令。常规 cargo build 可能不会处理 Emacs Lisp 文件的编译和捆绑，而 fresh-build 会执行完整的构建脚本（包括生成 .elc、.pdump 等），是项目专有工作流。
  • LTO（链接时优化）： --release 模式下构建时间极长的原因。Rust 编译器会在链接阶段对整个程序的二进制代码进行全局优化，以换取更小的体积和更快的运行速度。
  • MDV（Markdown Visualization）： 一种基于 Markdown 语法的数据可视化方案。它主张在纯文本中用极简语法实现图表、图形等可视化元素，不需要引入复杂的 JavaScript 框架（如 D3.js）。
  • gmp-mpfr-sys： 一个 Rust 的 FFI 层 crate，用于与 GMP（GNU 多精度算术库）、MPFR 和 MPC 库交互，在 NeoEmacs 这类项目中用于支持大整数和浮点运算。

💎 碎片知识与金句拾遗

  • 对 DeepSeek v4 的长上下文记忆评价： “用了一天 deepseek v4, 感觉它和智能体配合的很好，在同一个 session vibe 了半天都是很长的复杂任务，hermes 之前的记忆问题没有出现过。应该是模型本身做了压缩的功能，我感觉效果挺不错的。” —— 群友 @用户X 对 v4 模型在长对话中的记忆能力给出积极反馈。
  • Emacs 驱动 Agent vs Agent 调用 Emacs 的哲学碰撞： “他（指某个链接项目）这个和我之前的想法一样，只不过我希望直接通过 emacs 驱动 agent，而不是外部的 agent 来调用 emacs。” —— 群友 @用户Y 强调对“编辑器原生”的控制平面能力的追求。
  • 对 MDV 文风的高度评价： “语法克制、架构简洁，却把「文档即产品」这件事做到了极致。它不炫技，而是在效率与表达间找到最优解，值得每个热爱工具的开发者试一试。” —— 群友分享了 MDV 项目的观感，成为今日金句。
  • NeoEmacs 编译过程中的趣味日志： 群友贴出了一段 debug 日志（neomacs-layout-engine 的 layout_window_rust 调用），里面显示了字符宽度 16.26、行高 33.00 以及一个长长的 mode-line 输出 " U:--- *scratch* Top L4 (Lisp Interaction ElDoc) "，展示了极客们对于底层细节的痴迷。

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

  1. NeoEmacs 的“All in Rust”自举之路：

    • 后续研究建议： 关注仓库的 pr 和 issue，尤其是 .elc 文件生成依赖的移除。阅读 xtask 目录下的构建脚本（Rust 代码），理解 fresh-build 的完整流程。尝试在 macOS 上按照最新文档从头编译并提 issue。
    • 研究价值： 了解一个复杂的 Rust 项目（涉及 Emacs Lisp 解释器、布局引擎、WGPU 渲染栈）如何在跨平台（Linux vs macOS）上解决 C 依赖（如 gmp）和构建脚本健壮性的问题。

  2. MDV：探索 Markdown 可视化新范式：

    • 后续研究建议： 克隆并运行 MDV 项目（https://github.com/drasimwagan/mdv），理解它是如何在不依赖复杂框架的情况下实现图表和可视化元素的。考察其语法设计是否足够简洁到能嵌入到普通的 Markdown 编辑器中。
    • 研究价值： 启发如何将数据可视化“语言化”而不是“代码化”，对于写技术博客、设计文档的人来说，这可能改变写作习惯。

  3. Emacs 驱动的 Agent 控制平面设计：

    • 后续研究建议： 结合群友讨论的 org-runbook（链接：https://gsj987.github.io/org-runbook-a-set-of-multiagent-skills.html），研究如何利用 Emacs 的 Org-mode 作为无服务器状态的编排器（状态机）。思考如何在 Emacs 内部实现 Agent 的触发、状态管理和结果展示，而不是将其作为外部工具。
    • 研究价值： 这是“编辑器即操作系统”理念在 AI 时代的延伸，探索传统编辑器的交互模型如何与现代 LLM 智能体磨合，可能诞生新的开发工作流。