外观
Emacs 社区日报 2026-05-03
约 3573 字大约 12 分钟
2026-05-03
自动整理自 Telegram 讨论组,每天更新。内容为 AI 摘要,仅作信息索引与回顾。
Emacs 中文讨论组
好的,老铁们。这周的群聊记录看似碎片化,实则信息密度极高。既有对下一代编辑器 neomacs 的硬核编译与调试,也有关于编辑器UI哲学和字体排印的深度讨论。我已将其中的核心信息和散落的珍珠整理如下,供各位品鉴。
🎯 核心热点与专题探讨
【专题一】neomacs:从“尝鲜编译”到“项目工程化”的硬核之旅
这是本周当之无愧的主角。群内大佬围绕 neomacs(一个用Rust实现的Emacs)展开了从编译、调试到设计理念的全方位探讨。
核心观点与痛点:
- 编译是道硬门槛: macOS 用户首当其冲,遇到了
gmp(大数运算库)的路径识别问题(pkg-config找不到),最终发现是使用了 Rosetta 2 转译的 Intel Homebrew,而 Apple Silicon 的原生 Homebrew 路径不同。Fedora 用户则卡在 LTO(链接时优化)阶段,16G 内存被吃满,系统卡死。最终靠关闭debug和调整lto为thin才顺利编译。 - 从“能用”到“好用”的哲学之争: 核心开发者
eval_exec提出为 neomacs 内置更多主题,引发了群内关于编辑器默认行为和用户体验的讨论:- 反对派认为,用户更倾向于自己折腾主题,内置过多不仅增加维护负担,也非实用主义。
- 开发者视角:
eval_exec坚持 100% 兼容现有 Emacs 生态,因此“只会加东西,不会删东西”。但他同时考虑调整默认配置,比如将默认主题、菜单栏、工具栏和滚动条替换为 JetBrains 那种更现代、功能更丰富的风格,以此作为 neomacs 的“特色卖点”。
- 编辑器核心体验的打磨: 用户上报了
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下。
💎 碎片知识与金句拾遗
- Rust 生态的有趣发现:
cosmic-text(一个流行的 Rust 文本布局库)竟然依赖了yazi(一个文件管理器)。这揭示了 Rust 生态中依赖关系图的复杂性和“偶然性”。yazi可能是作为cosmic-text某个特性(如图片预览或其他文件操作)的可选依赖引入的。 - 关于 Rust 工具链的实践: 在项目根目录使用
rust-toolchain.toml来固定 Rust 版本是良好实践。它能确保所有开发者(包括CI)使用完全一致的编译器版本,避免“我机子上没问题”的尴尬。 - 关于“懒惰”的实用主义: “大家都是实用主义偏多,要搞配色主题的话多数人更喜欢自己搞。” —— 这是对开源社区“用户画像”的一个精准观察。
- 关于 Neovim 的跨界安利: “Emacs is a fantastic SQL editor.” —— 虽然来自Reddit,但也从侧面反映了Emacs(或类Emacs编辑器)在特定编辑场景下的独特优势。
- 关于 macOS 环境的杂学: “开头不是
/opt就看出来了吧(是 Intel Homebrew)。” —— 一个区分 Apple Silicon Mac 上不同架构 Homebrew 路径的实用技巧。
🛠️ 值得深入研究的点 (Follow-up)
- Neovim 的“一键式”体验方案: 针对“编译困难”的痛点,研究如何利用 GitHub Actions 的
release.ymlWorkflow,在每次发布新版本时,自动为 Linux (.AppImage/.rpm/.deb), macOS (.dmg), Windows (.exe) 等主流平台构建并上传编译好的二进制文件。这是降低项目贡献门槛、扩大用户群体的最佳实践。可以研究tauri-apps/actions或自定义脚本。 - 字体排印的绝对尺度解决方案 (Emacs/Neovim): 根治中英文混排问题,不应只停留在等宽字体的组合上。建议深入研究
harfbuzz(文本整形引擎) 和fontconfig(Linux 字体配置) 的配合。一个可行方案是:在编辑器中设置两个独立的face(或 buffer-local 的配置),一个专门用于处理 ASCII 字符(英文字体),另一个用于非 ASCII 字符(中文字体),并手动校准它们的基线(baseline)和字号(scale),而不是依赖系统默认的 fallback 机制。 - 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)
Polylith架构实战调研
- 建议:深入研究Polylith的官方文档(
polylith.gitbook.io)和成熟案例。重点关注其“组件拆分策略”、“副作用管理层(Brick Boundaries)”的设计,以及它在Clojure/ClojureScript之外(如Python、TypeScript)的移植可行性。尝试在一个小型前端或后端项目中实验性地应用其分级抽象思想。 - 研究入口:
polylith.gitbook.io
- 建议:深入研究Polylith的官方文档(
Codex
/goal模式的能力边界与风险- 建议:寻找Codex
/goal功能的详细评测和实际使用日志(如X/Twitter上的21小时重构案例)。亲自在一个沙盒项目中测试其对中大型代码库的重构、文档生成或测试用例补全能力,记录其完成率、出错模式以及对依赖的引入倾向。 - 研究入口:查阅OpenAI官方文档关于Codex
/goal的介绍,并关注社区中的“war stories”。
- 建议:寻找Codex
macOS 26 设计哲学与UI复古化实验
- 建议:虽然不推荐立刻升级,但深入研究macOS 26的“Liquid Glass”设计规范的官方文档。同时,可以对比研究一套完全不同的UI范式,比如在Linux上使用i3wm、dwm等平铺窗口管理器,或学习使用Raycast/Alfred等替代传统Launchpad的快捷启动器,体验“干净利落”的交互方式。
- 研究入口:Apple Human Interface Guidelines (HIG) 中关于macOS 26的部分;i3wm、Raycast的官方文档。
