Geekinney

外观

Emacs 社区日报 2026-08-30

约 5664 字大约 19 分钟

2026-08-30

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

Emacs 中文讨论组

🎯 核心热点与专题探讨

【专题：Lisp/Scheme 的应用价值之争】

这是本日最激烈、篇幅最长的讨论。起因是一位群友在写 CL（Common Lisp）时“写抑郁了”，认为 Lisp/Scheme 似乎只有教学场景，没有一个“非它不可”的应用场景。这引出了多位群友的深度回应。

  1. 反驳“只有教学用途”的观点：

    • LEM（一个用 CL 写的编辑器）不是教学产物。
    • OpusModus（https://opusmodus.com/）——用 Lisp 代码生成乐谱的商业软件，“多 cool”。
    • Guix 的 DSL 也是 Scheme，比 Nix 的 DSL 优雅多了。
    • 宏是其他语言没有的特性，“这不够炸吗”。

  2. 什么是“王炸”：

    • 群友拷打 AI 后认为最屌的性质是热更新，可以直接改函数——这正好是 CL 的优势。
    • 有人指出“哪个动态语言能写 OS、写 editor，这还不炸吗”。
    • 但也有理性声音：“啥王炸不王炸的，现在的语言，都是你喜欢用就是了”“不都可以被替代”。

  3. 括号问题与文化阻力：

    • “括号都劝退多少人了，就这一个括号，前前后后多少人适应不了”。
    • 有人表达“要是有什么王炸的性质，我觉得括号再多也没什么问题”。

  4. 职业与兴趣的冲突：

    • 有人写 CL 越写越振奋，但也坦言“我想语言写爽了，还能把狠狠恰米”。
    • 回应：“想通过语言狠狠恰米是不太可能的，有太多比语言更重要的东西了”“工作只看钱，别谈兴趣”。
    • 有人分享自己的经历：简历写了 Lisp，没一个面试官知道怎么拼，好多连 Emacs 都不知道。

  5. 推荐的学习路径：

    • CLOS——一种不太一样的 OOP 形式，群友表示“之前很讨厌 OOP 的我也喜欢上了 CLOS”。
    • let over lambda（LOL）——用闭包模拟 OOP 所有特性，并给出实际应用（cl-ydcv 和 clfswm）。
    • SICP 中的流与惰性求值：“惰性求值怎么一步步由闭包和宏构件出来的，还得用 lisp 和 scheme 写才能有感觉”。

【专题：Emacs 生态动态】

  • Emacs 31 正式版发布（8 月 24 日）。群友“今天才知道”，引发小波讨论。
  • emacs-china 论坛 504，负载太高，后来恢复。
  • Neomacs（Rust 实现的 Emacs 类似物）发布 v0.0.16，CI 正在运行；已有人将其打包到 gentoo-zh overlay（https://github.com/gentoo-zh/overlay/tree/master/app-editors/neomacs）。

【专题：Emacser vs Neovimer 的表达方式】

一个颇有洞察力的观察：“emacser 更喜欢写博客，用文字表达，理性，内省。neovimer 则更喜欢用视频表达，酷炫，张扬。在 AI Slop 泛滥的时刻，我觉得 emacser 依然坚守本心，使用自己认真思考过的文字，来表达自己的实践，更有价值，更难能可贵。”

🔑 关键概念与技术解析

  • Viper 模式：Emacs 内置的 Vim 模拟层，早在 Emacs 20 的 NEWS 里就存在（“long long ago”）。有人质疑“viper 甚至没自动处理窗口绑定吗”，进而引出“那为什么会有 evil”的问题——evil 正是为解决 viper 不足而生的替代方案。

  • CLOS（Common Lisp Object System）：Common Lisp 的面向对象系统，与常见 OOP 形式不同。群友特别强调，即使是讨厌 OOP 的人也会喜欢上 CLOS，值得深入研究。

  • let over lambda（LOL）：一种用闭包模拟 OOP 所有特性的技巧。虽然通常被认为只用于教学，但群友发现它在 cl-ydcv（https://github.com/MasterCsquare/cl-ydcv/blob/master/ydcv.lisp/#L44）和 clfswm 中都有实际应用——“我本来以为永远用不到，没想到还是用上了”。

  • 互递归（mutual recursion）：两个或多个函数互相调用对方。群友分享了一个 7 年前用 CL 写的组合排列算法（见下），偶然写成了互递归，跑得很快，问了 AI 才知道这个术语。几乎每本讲 Scheme 的书都提过 odd? 和 even? 的互递归示例。

(defun combination (n lst)
  (labels ((combine-1 (n lst)
         (if (eql 1 n)
         (list (list (car lst)))
         (mapcar #'(lambda (x) (cons (car lst) x))
             (combination (1- n) (cdr lst)))))
       (combine (n lst acc)
         (if (eql n (length lst)) (nreverse (push lst acc))
         (combine n (cdr lst)
              (append (nreverse (combine-1 n lst)) acc)))))
    (combine n lst nil)))

💎 碎片知识与金句拾遗

  • PragmataPro：κόσμος 回答“这是什么字体”时给出的答案。这是一个付费编程字体，支持多种特殊符号。
  • Windows Terminal 待选框挡住字母的问题：推测是“中文字体高了，行高还是按比较低的英文算得”。有人指出“Windows Terminal 的源码开源了，可以去看”。
  • 推荐文章：https://mike.hostetlerhome.com/my-emacs-misconceptions —— 群友分享的关于 Emacs 误解的文章。
  • org 博客配置：群友 zdn 分享了自己的配置（https://codeberg.org/zdn/pages），并表示效果“还是可以的”。
  • “我日常喜欢 linux 是因为我非 linux 不可么？换了就不行么？并非，纯热爱。” —— 用热爱而非必要性来解释选择。
  • “我简历写了 lisp，没一个面试官知道，都来问我怎么拼。” —— 冷幽默地反映了 Lisp 在小众中的现实。
  • Emacs 31 正式版：8 月 24 日发布，群友当天才知道。
  • viper 内置的历史：Emacs 20 的 NEWS 里就有 viper 了，已经非常古老。

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

  • Neomacs（https://github.com/eval-exec/neomacs）：Rust 实现的 Emacs 类似物，v0.0.16 已发布，且已被 gentoo-zh overlay 打包。值得关注其发展方向和与原生 Emacs 的差异。
  • OpusModus（https://opusmodus.com/）：商业化的 Lisp 音乐生成软件，是 Lisp 在非教学领域的强有力例证。
  • let over lambda 在实际代码中的应用（cl-ydcv、clfswm）：可深入研究如何用闭包模拟完整 OOP 体系。
  • CLOS 的独特对象模型：对反感传统 OOP 的人来说，CLOS 可能是值得深入理解的一种替代范式。
  • 群友分享的互递归 combination 函数：虽然群友自己“现在都看不懂”，但跑得很快（不到 10 秒），值得拆解其算法逻辑与优化点。

观点延伸

当天争论真正有张力的地方，不是 Lisp 有没有一个足以征服所有人的“王炸”，而是我们究竟用什么标准判断一门语言值得长期投入。更可靠的判断是：它是否能把建模、运行、观察和修改压缩进一个低摩擦循环。宏、REPL、热更新，以及 LEM、Guix、OpusModus 这些例子，价值并不只在“功能清单”，而在于它们让程序更像可以持续塑形的材料，而不是编译一次就只能被动维护的成品。

1. 可替代，不等于没有工程价值

“现在的语言都可以被替代”并不能直接否定 Lisp。工程上应该追问的是：换成另一门语言后，表达领域模型、构造 DSL、交互式调试和响应需求变化的成本是否上升。语言优势很少表现为“没有它就绝对做不到”，更多表现为“用它做这类事，反馈更快、结构更贴近问题”。因此，所谓王炸，最好被定义成可测量的反馈优势，而不是宣传口号。

括号会带来学习成本，生态会影响交付成本，确实都是现实约束。语言选择本来就是表达能力、团队接受度、工具链和部署环境之间的权衡，而不是寻找一门永远正确的语言。

2. 动态能力越强，越需要留下证据

“可以直接改函数”的爽感是真实的，但它也要求开发者补上另一半工程纪律：命名、测试、示例、版本记录和可重放的启动方式。群里那段互递归代码“跑得很快”，却连作者后来都不容易读懂，正好说明运行效率与理解效率是两条不同的轴。

CLOS 和 let over lambda 值得研究，不是因为它们能制造更炫的代码，而是因为它们迫使人重新思考对象、状态、闭包和边界如何组织。AI 可以在事后告诉我们某段代码属于互递归，却不能替代代码本身的可解释性。动态环境提高了探索速度，也可能积累“只有当时的作者知道怎么改”的知识债务。

3. 兴趣与职业之间隔着可交付物

“简历上的 Lisp 还要解释怎么拼”说明市场通常不会为语言偏好本身付费。它更可能为可运行的编辑器扩展、稳定的 DSL、可维护的系统、清楚的文档和能被别人接手的结果付费。兴趣与职业不必强行统一：兴趣负责选择能激发思考的工具，职业则要求把这种思考包装成别人能够部署、验证和复用的成果。

“Emacser 更喜欢写文字”的观察也可以推进一步：文字的价值不只是表达态度，而是把配置、代码、实验过程和结论连接起来，形成可追溯的个人知识系统。

可继续研究/实践

选一个小而真实的任务，例如编辑器功能或最小 DSL，分别用 Lisp 与熟悉的语言实现。记录需求变更后的反馈时间、修改范围、重启或重构次数、测试覆盖和交接难度。不要比较谁更“优雅”，只比较哪种工作流更容易探索，也更容易留下下一次仍然看得懂的证据。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：NixOS 的“真香”与“真痛”——一场持久的信仰之争

本次讨论中，围绕 NixOS 的优缺点爆发了激烈的辩论，参与者分成了“坚定拥趸”和“理性退坑”两派，其核心矛盾点颇具代表性。

支持方观点（“真香”派）：

  • 声明式配置的终极魅力：认为“配置一次就可以用一辈子”，系统成形后只需“小修小改”，且电脑损坏后无需从头配置，环境可完整复现。
  • 沉淀与固化：Nix 能将个人长期摸索出的各种“方案”和“workaround”固定下来，形成可持续的资产。
  • 生态与工具：nix-ld 等方案解决了 FHS 兼容性问题；nixpkgs 包库庞大，即使没有现成包，也可通过自建 Flake 或借助 AI 打包解决。

反对方观点（“真痛”派）：

  • 兼容性痛点：历史软件多基于 FHS 设计，Nix 的目录结构导致兼容性差，AppImage 更是“老大难”。
  • 更新策略僵化：Nix 更新单个软件需要额外维护多个 nixpkgs，且 /nix 存储大量重复内容；被迫“更新就得全部更”，在需要频繁更新单一软件的工作场景下极为不便。
  • 配置维护成本：认为 Nix 的本质是“一直在配置的路上”，遇到问题难以快速解决，尤其在工作时“给你来一下”，浪费时间。相比之下，Debian + 脚本初始化系统，换电脑“两下的事”。
  • Nix 语言自身缺陷：认为 Nix 语言是最大的短板，打包时仍需混用 bash/nushell；而 Guix 使用成熟的 Scheme (Guile)，整个系统统一接口，更优雅。

关键解决方案与妥协：

  • 使用其他发行版 + 安装 Nix：作为包管理器使用，享受 Nix 的包生态，同时避免系统级绑定带来的风险。
  • 借助 AI 简化打包：AI 让打包门槛大幅降低，甚至有人提到使用 Guix 时“让 AI 自己来打包”。
  • 承认 Nix 并非银弹：讨论中有人总结，NixOS 的价值在于“把配置维护这件事强制化下来了”，是一种理念上的升华。

衍生话题： 群内还提到了对某个人（或组织）声称要 fork nixpkgs 的讨论，普遍持观望态度，认为“大概率会 fork 一个”，但对社区贡献持悲观态度，戏称“这帮人真有点魔了”。

专题二：Org-mode 导出 HTML 的“Face”之痛——追求像素级完美渲染的挣扎

围绕如何让 Emacs 导出的 HTML 与 Buffer 中的语法高亮（Face）完全一致，展开了一场技术深挖。

问题描述：

  • Emacs 内置的 org-html-export 导出的代码块样式与编辑器内所见不一致，存在大量 Face 错乱（“错 30% 都是低估了”），尤其是白色被错误导出为黑色等问题。
  • 浏览器默认的 <pre> 字体（等宽字体）渲染效果不佳，影响美观。

技术探索与解决方案：

  1. 美化 CSS：推荐了经典的 orgcss（gongzhitaao.org/orgcss/），并提供了自定义 CSS 覆盖 pre 和 code 字体族的配置代码。
  2. 精确导出 Face：发现 htmlize-file 可以 100% 正确导出 Buffer 的 Face，而 org-html-export 不行。
  3. 替代工具链：介绍了 htmlize 和 engrave-faces 两个 Emacs 插件，用于改进导出样式。
  4. 理想方案构想：提出与其纠结于导出 Face，不如导出“Face 名字”，再在外部映射到自定义主题；或直接放弃高亮 Face，改用 highlight.js 给代码块着色。
  5. 更彻底的反思：有人考虑重写整个 ox-html，但因“没有解析器”而头疼；也有人推荐直接用 Hugo 发布 org 文件，绕开 Emacs 导出链。

核心痛点总结：

  • Org 导出 HTML 的 Face 映射机制存在缺陷，不依赖第三方工具（如 htmlize）很难达到完美效果。
  • 群友感叹“他明明能做到一模一样，这让人伤心”，反映出对 Emacs 核心功能“差一步”的惋惜。
  • 有人尝试“导出 AST 再加工”，但仍感觉与解析器方案相比“差不多”，本质还是需要统一 AST 来解决。

🔑 关键概念与技术解析

  • nix-ld：NixOS 生态中用于兼容 FHS（Filesystem Hierarchy Standard）的方案，允许在 Nix 环境中运行传统路径结构的二进制文件，解决历史软件的兼容性问题。
  • Flake：Nix 生态的新特性，一种声明式的、可复现的项目配置和打包格式，便于自定义包管理和环境共享。
  • htmlize / engrave-faces：Emacs 插件。htmlize 能将 Buffer 内容（包括 Face 样式）导出为 HTML；engrave-faces 则更精确地保留 Emacs 的 Face 信息，用于导出到 HTML 或 LaTeX。
  • orgcss：一个经典的 Org-mode HTML 导出样式表，提供了简洁、美观的默认样式，常被用户作为定制的基础。
  • lazyblorg：一个用 Python 编写的、基于 Org-mode 的博客发布系统，强调懒加载和自动化。
  • user-lisp：Emacs 31 引入的新特性，允许用户指定存放配置的目录，无需显式设置 load-path，简化了配置管理。
  • omarchy：一款 Arch Linux 定制的发行版（或配置框架），因其被包装成“全新桌面环境”并获得巨额融资（据称 1000 万美元）而引发争议，被认为是“炒作的神”。
  • niri：一个基于 Rust 的、滚动式窗口布局的 Wayland 合成器，作为 Hyprland 的现代替代品，支持 Lua 配置。
  • mihomo：一个 Go 语言编写的代理工具，常用于科学上网，是 Clash 的一个分支（或核心），配置较为复杂。
  • cybercity：一个基于 Claude（或类似技术）的在线“赛博城市”互动项目，可通过链接分享。
  • zulip / discourse：两款开源论坛/聊天软件，均以 HTML 形式返回内容，但 discourse 提供 raw 格式接口，而 zulip 仅提供 HTML，对数据抓取不够友好。

💎 碎片知识与金句拾遗

  • “甚至这种效果都可以在 emacs里实现，原理上没问题” —— 对 Emacs 扩展能力的绝对自信。
  • “下载有ai，写脚本也不费劲了” —— 用 AI 辅助编写系统初始化脚本，已经成为部分用户的主流实践。
  • “nix配置成形了之后基本上就都是小修小改了” —— 对 Nix 配置稳定期状态的描述，精准且令人向往。
  • “说实话nix的缺陷还是它自身的nix语言” —— 一句犀利的技术批判，直指 Nix 语言的设计问题。
  • “我打算后面让ai来研究一下” —— 遇到复杂技术难题（如统一 AST）时，直接甩给 AI 的现代工作流。
  • “果子用户进了 Linux 大观园” —— 形容 macOS 用户初入 Linux 世界时眼花缭乱的状态。
  • “给 arch+hyprland 打包定制一下，就骗了 1000w 刀，估计投资人都是 macOS和win用户，没吃过没见过，但凡逛过两天 r/unixporn 都没这么容易被骗😁” —— 对 Omarchy 项目融资的辛辣讽刺，认为其本质只是包装炒作。
  • “我特别社恐 非常讨厌别人给我打电话” —— 程序员社恐的真实写照，引发了关于阿里巴巴客服骚扰的共鸣。
  • “linux 桌面正处于并将长期处于，让真正的专业开发者在工作时间制作，这一新常态的初级阶段？” —— 对 Linux 桌面生态现状的戏谑性总结。
  • “我发现不是字体问题 是主题问题” —— 排查问题时的重要提醒：表象是字体，根源在主题。
  • “Org 的话就直接加在文件里面。” —— 提示可以用 #+begin_export html 块在 Org 文件内直接嵌入 CSS，无需外部文件。
  • “我现在用其他发行版也还真不知道到底要干什么” —— 反 Nix 观点中透露的迷茫，凸显了 Nix 声明式配置对“环境确定性”的吸引力。
  • “下次重置啥时候” —— 结合开头关于“按钮已按下”、“庆祝活动改期”的讨论，推测群内在关注某个“重置”倒计时或定时任务。

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

  • Guix 的“AI 打包”工作流：有群友提到用 Guix 时“直接让 AI 自己来打包”，这暗示了一个“AI 辅助打包”的新范式。值得深入研究：AI 如何理解 Guile/Scheme 的打包 API？这种模式能否推广到 Nix 或其他包管理器？
  • engrave-faces 与 ox-html 的深度整合：既然 htmlize-file 能完美导出 Face，而 ox-html 不行，未来是否可以开发一个基于 engrave-faces 的导出器，彻底解决 Org 导出样式错乱问题？
  • 统一 AST 的设想：群友提到“各个应用用的 markup 格式不统一太难受了，还不可能用 treesitter”，并打算“让 AI 来研究一下”。这指向了一个潜在的开源项目：用 AI 解析各种 markup 格式并统一为 AST，用于渲染和转换。非常有前瞻性。
  • Emacs 31 的 user-lisp 目录机制：作为配置管理的新范式，值得进一步探索其最佳实践，尤其是如何与 early-init 和 init 文件配合。
  • NixOS 与 Guix 的 AI 集成：讨论中反复出现“AI 打包”和“AI 调错”，如何将 AI 能力无缝集成到 Nix/Guix 的包管理和配置流程中，可能是未来解决“配置负担”的关键方向。
  • hyprland 的 Lua 配置：群友提到“最近配置换到 lua ，玩法更多了”，这可能代表了 Wayland 合成器配置的轻量化趋势，值得跟踪其社区生态发展。

观点延伸

当天关于 NixOS 和 Org HTML 的两场争论，表面上一个在谈系统配置，一个在谈网页渲染，底层却是同一个问题：复杂性不会因为自动化消失，只会被转移。转移到哪里、能不能定位、是否能重复验证，才决定一套工具最终是资产还是负担。

1. 可复现和可变更，本来就是两条轴

NixOS 的支持者看重的是“电脑坏了也能重建”，反对者在意的是“今天能不能只更新一个软件”。这不是谁更懂工程，而是两种工作负载发生了冲突：前者追求环境稳定和长期复用，后者需要快速试错、频繁装开发版软件。

声明式配置的价值，是把依赖、版本和 workaround 从记忆里拿出来，变成可以重建的输入；代价是每个例外都要进入这套模型。Debian 加初始化脚本也能实现迁移，只是部分成本藏在脚本、手工步骤和环境差异里。AI 可以降低“写配置”的价格，却不能替你决定哪些东西应该冻结、哪些东西必须允许单独变化。

所以，真正该测的不是哪种方案更优雅，而是三件事：新软件的加入速度、单包更新的摩擦、故障后的恢复时间。数据比信仰有用。

2. Face 错乱首先是边界错误，其次才是样式错误

讨论从字体和主题一路追到 htmlize、ox-html、Face 名字和统一 AST，说明问题已经超出 CSS 范围。htmlize 直接读取 Buffer 的 Face 能得到正确结果，而经过 Org HTML 导出后出现大量错误，至少说明两层之间对“样式属于什么、何时计算、如何映射”没有稳定契约。

继续调颜色只能遮住症状。更可靠的做法是把文本结构、语义角色、Face 名称和主题映射分开保存，再让 HTML 作为一个输出后端。这样可以分别测试解析、映射和浏览器渲染，定位到底是哪一层丢了信息。改用 highlight.js 可以绕过 Emacs Face，但它是换了一套语义来源，不是修复原来的转换链。

3. 个人知识系统也该保留“源”和“视图”的区别

Org 文件应当是结构化源，HTML、主题和代码高亮只是视图。若把某次导出的视觉结果当成事实，换主题或换发布工具就会重新陷入手工修补。配置系统如此，知识发布系统也如此：源数据要稳定，中间表示要可检查，最终渲染要能回归测试。

可继续研究/实践

选一段同时包含标题、代码和多种 Face 的 Org 文本，保存 Buffer Face、Org AST、导出 HTML 和浏览器样式四层快照；再记录一次 Nix/Guix 与 Debian 脚本的安装、单包更新和故障重建耗时。先把边界测出来，再决定哪种自动化值得长期维护。