Geekinney

外观

Emacs 社区日报 2026-05-03

约 3573 字大约 12 分钟

2026-05-03

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

Emacs 中文讨论组

好的，老铁们。这周的群聊记录看似碎片化，实则信息密度极高。既有对下一代编辑器 neomacs 的硬核编译与调试，也有关于编辑器UI哲学和字体排印的深度讨论。我已将其中的核心信息和散落的珍珠整理如下，供各位品鉴。

🎯 核心热点与专题探讨

【专题一】neomacs：从“尝鲜编译”到“项目工程化”的硬核之旅

这是本周当之无愧的主角。群内大佬围绕 neomacs（一个用Rust实现的Emacs）展开了从编译、调试到设计理念的全方位探讨。

核心观点与痛点：

  1. 编译是道硬门槛： macOS 用户首当其冲，遇到了 gmp（大数运算库）的路径识别问题（pkg-config 找不到），最终发现是使用了 Rosetta 2 转译的 Intel Homebrew，而 Apple Silicon 的原生 Homebrew 路径不同。Fedora 用户则卡在 LTO（链接时优化）阶段，16G 内存被吃满，系统卡死。最终靠关闭 debug 和调整 lto 为 thin 才顺利编译。
  2. 从“能用”到“好用”的哲学之争： 核心开发者 eval_exec 提出为 neomacs 内置更多主题，引发了群内关于编辑器默认行为和用户体验的讨论：
    • 反对派认为，用户更倾向于自己折腾主题，内置过多不仅增加维护负担，也非实用主义。
    • 开发者视角：eval_exec 坚持 100% 兼容现有 Emacs 生态，因此“只会加东西，不会删东西”。但他同时考虑调整默认配置，比如将默认主题、菜单栏、工具栏和滚动条替换为 JetBrains 那种更现代、功能更丰富的风格，以此作为 neomacs 的“特色卖点”。
  3. 编辑器核心体验的打磨： 用户上报了 neomacs -Q 下“删除键”映射成 C-h 的奇怪 Bug，以及启动后大量的 ERROR 日志。开发者要求开启 RUST_LOG=debug 并提供完整日志，展现了良好的Bug追踪流程。

解决方案与进展：

  • macOS 编译问题被 hermes 解决并提交了 PR (https://github.com/eval-exec/neomacs/pull/91)。
  • 通过 CI 自动打包并提供 Release 二进制文件的计划被提上日程，这是降低用户使用门槛的关键一步。
  • fresh-build 的并行优化已显著提升编译速度（本地7分钟）。

【专题二】中英文混排的字体排印“顽疾”

一个看似简单却让无数（特别是终端与编辑器）开发者头疼的问题：如何解决中英文字体混排时，图标显示不佳、字符间距不一致的问题。

痛点：

  • 用户尝试了组合方案：等宽英文字体 IoskeleyMono Nerd Font + 中文等宽字体 LXGW WenKai Mono TC，但AI输出的图标效果依然“太难看了”。
  • 这表明仅仅使用“等宽”字体族并不能解决所有排版问题。问题可能出在：
    • 字体的度量信息（如 EM 和 Ascent/Descent）不一致。
    • 图标字体（通常是 Nerd Font 中的部分）本身的尺寸和对齐问题。

群内给出的探索方向：

  • 字体 Property 属性调整： 给图标元素加上如 (1 . em)， :height， :ascent 等参数进行微调。这更像是一种 Hack 而非根本解决办法。
  • 未达成的共识： 讨论并未给出一个“开箱即用”的解决方案，这仍然是编辑器/终端领域一个待解决的开放性问题。

🔑 关键概念与技术解析

  • neomacs: 一个用 Rust 语言重写的、旨在 100% 兼容 GNU Emacs 生态的新兴编辑器。它利用 Rust 的内存安全特性和 WGPU（下一代图形API）来实现更现代的渲染和体验。目前的开发重点是实现基础功能和优化构建流程。
  • LTO (Link Time Optimization): 链接时优化。一种编译器优化技术，它在链接阶段对所有编译单元进行全局分析，从而进行更加激进的优化（如内联、死代码消除）。代价是极大地增加编译时间和内存消耗。neomacs 的 release 构建默认开启了 LTO，这是导致 16G 内存不够用的主要原因。
  • RUST_MIN_STACK: Rust 环境变量，用于设置线程的主栈大小。当遇到栈溢出（stack overflow）错误时，可以尝试设置一个较大的值（如 export RUST_MIN_STACK=8388608）作为临时解决方案。
  • Rosetta 2: Apple 为搭载 Apple Silicon (M1/M2/M3) 芯片的 Mac 提供的动态二进制翻译技术，允许其运行为 Intel x86 架构编译的软件。使用 Intel 架构的 Homebrew 安装的库，会被安装到 /usr/local 下，而 Apple Silicon 原生版本则在 /opt/homebrew 下。

💎 碎片知识与金句拾遗

  1. Rust 生态的有趣发现： cosmic-text（一个流行的 Rust 文本布局库）竟然依赖了 yazi（一个文件管理器）。这揭示了 Rust 生态中依赖关系图的复杂性和“偶然性”。yazi 可能是作为 cosmic-text 某个特性（如图片预览或其他文件操作）的可选依赖引入的。
  2. 关于 Rust 工具链的实践： 在项目根目录使用 rust-toolchain.toml 来固定 Rust 版本是良好实践。它能确保所有开发者（包括CI）使用完全一致的编译器版本，避免“我机子上没问题”的尴尬。
  3. 关于“懒惰”的实用主义： “大家都是实用主义偏多，要搞配色主题的话多数人更喜欢自己搞。” —— 这是对开源社区“用户画像”的一个精准观察。
  4. 关于 Neovim 的跨界安利： “Emacs is a fantastic SQL editor.” —— 虽然来自Reddit，但也从侧面反映了Emacs（或类Emacs编辑器）在特定编辑场景下的独特优势。
  5. 关于 macOS 环境的杂学： “开头不是 /opt 就看出来了吧（是 Intel Homebrew）。” —— 一个区分 Apple Silicon Mac 上不同架构 Homebrew 路径的实用技巧。

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

  1. Neovim 的“一键式”体验方案： 针对“编译困难”的痛点，研究如何利用 GitHub Actions 的 release.yml Workflow，在每次发布新版本时，自动为 Linux (.AppImage / .rpm / .deb), macOS (.dmg), Windows (.exe) 等主流平台构建并上传编译好的二进制文件。这是降低项目贡献门槛、扩大用户群体的最佳实践。可以研究 tauri-apps/actions 或自定义脚本。
  2. 字体排印的绝对尺度解决方案 (Emacs/Neovim)： 根治中英文混排问题，不应只停留在等宽字体的组合上。建议深入研究 harfbuzz (文本整形引擎) 和 fontconfig (Linux 字体配置) 的配合。一个可行方案是：在编辑器中设置两个独立的 face（或 buffer-local 的配置），一个专门用于处理 ASCII 字符（英文字体），另一个用于非 ASCII 字符（中文字体），并手动校准它们的基线（baseline）和字号（scale），而不是依赖系统默认的 fallback 机制。
  3. Emacs/Neovim 的“现代化”UI 哲学： 受 neomacs 启发，研究如何在现有的 Emacs 框架中通过包（如 emacs-mac， pgtk 分支，或结合 posframe、vline 等）来实现 JetBrains 风格的高级 UI 元素。例如：
    • 自定义 modeline 使其变成类似 IDE 的标签页和状态指示器。
    • 替换 scroll-bar 为在侧边显示代码诊断信息或搜索结果的“迷你图”（mini-map/scrollbar map）。
    • 探索使用 eww 或 xwidget 来实现更丰富的内联渲染。

Emacs 轻聊讨论组

🎯 核心热点与专题探讨

专题一：AI辅助开发与跨语言架构设计

本日最强烈的技术讨论围绕如何利用AI进行TypeScript开发，并尝试对齐Clojure风格的Polylith架构展开。

  • 核心痛点：成员对AI（尤其是Codex）写TypeScript的“副作用蔓延”感到不满，称“写写就多了一堆依赖”。同时，对于TypeScript到ClojureScript的跨语言转换，普遍认为“感觉不可行”，关注点集中在如何保持架构一致性而非直接转译。
  • 解决方案探讨：
    • 成员提出使用eslint-plugin-boundaries来强制执行模块边界，但觉得“有点累”。
    • 核心思想是借鉴Clojure的Polylith架构，这是一种微服务的Monorepo架构，将副作用封装在同一层，业务逻辑在另一层，提供“更干净的API接口”。有人将其类比为“Python数据分析项目的模块化入口方式”。
  • AI工具新动向：Codex推出了/goal指令，允许长时间运行任务直至完成。有实际案例显示其跑了21小时的重构任务，仅极少部分未覆盖。这被认为是AI开发者工具的重大跃进。

专题二：操作系统的“臃肿”与复古UI美学

由一则1997年Visual Studio的游戏开发视频引发了一场关于UI简洁性的怀旧与批判浪潮。

  • 核心矛盾：对现代操作系统的“液态玻璃”设计风格（尤其指macOS）的强烈反感，认为其“所有界面都像被打肿了”、“对设计的限制其实很大”。怀念早期软件“干净利落、清清爽爽、可用面积大”的体验。
  • 关键细节：
    • macOS已跳过16-25的版本号，直接进入MacOS 26（按年份命名），但传统Launchpad被移除，替换为类似Raycast/Alfred的快捷启动器。Apple Music是本次升级唯一公认的受益者。
    • 成员坚持留在macOS 15.6.1，并收到忠告“你先别升”。
    • KDE被认为预设不好看，但“好在能调”，而默认值被认为能“节约时间”。
  • 深层观点：UI繁重的根源被归结为早期内存和CPU资源有限（2核/4核）的约束，而现在资源富裕导致设计膨胀。

🔑 关键概念与技术解析

  • Polylith：一种用于构建微服务的Monorepo架构模式，起源于Clojure社区。核心思想是将项目拆分为可复用的“组件”（bricks），并将副作用（如数据库、网络请求）与纯业务逻辑严格分层，提供统一入口（类似于Python的模块初始化）。其特点在于架构抽象优先于特定语言实现。
  • ClojureScript (cljs)：Clojure语言的编译器，专门针对JavaScript运行时（尤其是浏览器和Node.js）。它允许开发者用Clojure的语法和函数式编程范式来编写前端应用，并与现有的JavaScript生态互操作。
  • /goal (Codex)：AI编程助手Codex的一个高级指令模式。不同于逐条提示，/goal允许用户设定一个长期任务目标（如“重构整个模块”），AI将持续运行并自我迭代，直到目标达成或遇到无法解决的障碍。
  • Liquid Glass (液态玻璃)：Apple在macOS 26及iOS后续版本中推广的一种设计规范，强调模糊、半透明、高光和高动态效果的UI元素。讨论中对它持强烈批评态度。
  • Meridian：一个基于Claude SDK的反代项目（GitHub: rynfar/meridian）。核心功能是消耗Claude的API配额，模拟其原生能力。讨论中提及它可能被用于规避封号，但也警告其可能存在剔除敏感关键词导致无法使用的风险。

💎 碎片知识与金句拾遗

  • “我宁愿以前内存小的时代，不搞这么多臃肿的按钮，动态。” —— 对UI极简主义的直白怀念，认为功能优先于花哨的视觉效果。
  • “默认是非常重要的，可以节约时间。” —— 对KDE等可高度定制桌面的反思，认为默认配置的优化程度直接决定了用户入门成本。
  • “codex越来越强了。” / “卧槽、这么强。” —— 对Codex /goal 演示的直观反应，承认AI自主完成复杂长任务的能力正在超预期。
  • “AI写ts，写写就多了一堆依赖。” —— 对AI生成代码的常见痛点总结：为了快速实现功能，AI倾向于引入不必要的第三方库，导致项目膨胀和维护负担。
  • “国内现在有啥划算coding plan么😮‍💨” —— 对海外API封号、虚拟卡风险以及国内（如Kimi）高昂API费用的无奈吐槽。
  • “kimi api两天就100块，太离谱了。” —— 一个具体的使用成本数据，反映了国内某些AI API服务的高昂定价。
  • “deepseek 按照 utc+0 的时间做统计的” —— 一个冷门但实用的运营细节，暗示了API统计/计费的时区陷阱。

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

  1. Polylith架构实战调研

    • 建议：深入研究Polylith的官方文档（polylith.gitbook.io）和成熟案例。重点关注其“组件拆分策略”、“副作用管理层（Brick Boundaries）”的设计，以及它在Clojure/ClojureScript之外（如Python、TypeScript）的移植可行性。尝试在一个小型前端或后端项目中实验性地应用其分级抽象思想。
    • 研究入口：polylith.gitbook.io

  2. Codex /goal 模式的能力边界与风险

    • 建议：寻找Codex /goal 功能的详细评测和实际使用日志（如X/Twitter上的21小时重构案例）。亲自在一个沙盒项目中测试其对中大型代码库的重构、文档生成或测试用例补全能力，记录其完成率、出错模式以及对依赖的引入倾向。
    • 研究入口：查阅OpenAI官方文档关于Codex /goal 的介绍，并关注社区中的“war stories”。

  3. macOS 26 设计哲学与UI复古化实验

    • 建议：虽然不推荐立刻升级，但深入研究macOS 26的“Liquid Glass”设计规范的官方文档。同时，可以对比研究一套完全不同的UI范式，比如在Linux上使用i3wm、dwm等平铺窗口管理器，或学习使用Raycast/Alfred等替代传统Launchpad的快捷启动器，体验“干净利落”的交互方式。
    • 研究入口：Apple Human Interface Guidelines (HIG) 中关于macOS 26的部分；i3wm、Raycast的官方文档。