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

Emacs 中文讨论组

好的，作为资深的技术社区编辑和知识管理专家，我已经对这份长达432条消息的群聊记录进行了深度挖掘、整合与提炼。以下是本期结构化知识库：

🎯 核心热点与专题探讨

【专题讨论】Emacs 的多线程/多进程未来与新架构探索

这是贯穿全天最核心、最具有深度的技术讨论。话题由 magit 性能痛点引发，最终深入到 Emacs 架构的底层设计与未来可能性。

• 导火索：Magit 的性能之殇

  • 用户抱怨 magit 操作“卡一下”，尤其是在本地操作时。讨论迅速从“如何优化 magit”转向“问题的根源是什么”。
  • 核心结论1：Magit 慢，一部分源于 git 自身命令行执行的串行开销，另一部分则是 Emacs 单线程模型下，任何阻塞性操作都会卡住整个 UI 的 “图形渲染总线也塞在主主进程” 的设计。
  • 诊断方法：群友提供了精准的 Emacs 性能诊断工具链：
    1. (advice-add 'call-process :before ...) 监控 Emacs 在调用外部进程时的具体操作。
    2. M-x elp-instrument-package <PACKAGE-NAME> 对某个包的所有函数进行性能剖析（如 elp-instrument-package magit），再通过 M-x elp-results 查看耗时分布。
    3. 直接使用内建的 M-x magit-profile-refresh-buffer 分析刷新 buffer 的瓶颈。

• 解决方案的三大流派 讨论分化为三个方向，代表了社区对 Emacs 未来路径的不同设想：

  • 当前流派：异步进程与外部工具

    • 核心思想：Emacs 已经支持异步进程，尽可能将重活（如 git 操作、LSP）交给外部进程。
    • 代表讨论：emacs-tramp-rpc（远程文件操作优化）、ast-grep（高级 grep 替代品，本质也是外部进程调用）、rass (一个 Python 写的 LSP 客户端)。
    • 评价：这是最务实的方案，但治标不治本，依赖外部工具和进程间通信的开销。

  • 激进流派1：多进程+图形渲染分离

    • 核心思想：将 Emacs 拆分为两个或多个进程。一个专门负责 UI 渲染（类似 GPU 驱动），另一个负责核心编辑器逻辑。这相当于“2个emacs实例”。
    • 代表项目：Neo Emacs (neomacs)。与会者明确指出，Neo Emacs 的核心策略正是将 GNU Emacs 的 C 部分用 Rust 重写，保证 Lisp 层 100% 兼容，同时实现多线程/多进程和渲染分离。其作者也在群中现身，坦言“lisp 的部分，neomacs和 gnu emacs 一模一样。 c的部分就是保证逻辑一致的重写”，并且已经可以跑起 Doom Emacs。
    • 讨论热点：neomacs 何时能生产可用？作者表示 v0.0.8 即将发布，届时邀请大家体验。

  • 激进流派2：改良式多线程/异步模型

    • 核心思想：在现有架构上，引入类似 JavaScript 的事件循环（Event Loop）和 Worker 模型。
    • 讨论核心：“全局可变状态（Shared Mutable State）”是 Emacs 无法多线程的根源。
    • κόσμος (一位重度参与者) 深入剖析了引入多线程的复杂性：不仅仅是 buffer-local 状态，甚至像 string-match 这样的底层函数也在修改全局状态。引入多线程会破坏数以万计的已有包。
    • 该流派的建议：“elisp 就应该直接抄 js 模型”，即引入异步机制和 Worker，但不共享内存，通过消息传递数据（类似 Actor Model）。已经被讨论的方案包括 sharedarraybuffer（借鉴 JS）。

【专题讨论】编辑器的备选方案与生态比较

除了 Emacs 本身，群友也广泛讨论了其他工具，反映了“极客”们广阔的技术视野。

• 终端模拟器之争：Kitty vs. Ghostty

  • 这是持续一天的热点。双方各有支持者。
  • Ghostty 优点：本地化做得好（Linux 用 GTK，macOS 用 SwiftUI）、视觉效果好。
  • Ghostty 缺点：Linux 上存在内存泄露、字体渲染曾有问题、功能不如 Kitty 全面。有人觉得“很卡”。
  • Kitty 优点：功能强大（如 editor scrollback）、速度快（部分用户认为比 Ghostty 快）、性能稳定。
  • 其他讨论：有人感叹“windows 上 ghostty 不能设输入法”，引出 ghostel 插件用于解决输入法问题；还有人推荐了foot和纯 elisp 的终端模拟器 eat。

• Coding Agent 与编辑器

  • 有人提到“coding agent 流行以后没打开过 [GUI 编辑器]，还是终端舒服”，侧面反映了开发工作流的转变。
  • 同时，对 “vibe coding” 的质量表达了担忧：“很多人是vibe了不管后续了，没有维护的意愿”。

• Ast-grep：高级结构化搜索和替换工具

  • 群友大力推荐 ast-grep，并将其功能概括为：
    1. 替代 rg（ripgrep）：作为更高级的代码搜索工具。
    2. 代码重写：基于 AST 进行精准的批量重构。
    3. Lint 规则引擎：用 AST 匹配反模式（anti-pattern），写自定义 Lint 规则。
  • 有人评价“rewrite 略屌”。

🔑 关键概念与技术解析

• Magit Profile：Emacs 自带内置的性能剖析工具，专门用于分析 Magit 的 buffer 刷新速度。用法：M-x magit-profile-refresh-buffer。
• Elp (Emacs Lisp Profiler)：Emacs 内置的性能分析器，可以植入包的函数，追踪函数调用次数和耗时。用法：M-x elp-instrument-package 和 M-x elp-results。
• Neo Emacs (neomacs)：一个旨在用 Rust 重写 GNU Emacs C 核心的开源项目，目标是在保证 Lisp 生态 100% 兼容的前提下，引入多线程、更现代的渲染管线。其 C 部分被重写以支持并发，而 Lisp 层保持不变。
• Ast-grep：一种基于 AST（抽象语法树）的代码搜索、重构和 lint 工具。它不依赖正则表达式，而是基于语法树模式匹配，因此精度和结构感更强。
• ghostel：用于解决 macOS 上 Ghostty 终端模拟器无法自动切换输入法的插件，它监控焦点事件，确保在输入命令时强制切换到英文输入法。
• Windows Powershell 生态混乱：群友揭露了 Windows 上多个 PowerShell 变体存在的混乱局面：
  • Windows PowerShell：基于 .NET Framework，内置于系统，慢。
  • PowerShell (pwsh): 基于 .NET Core 的跨平台版本，快但独立安装，与旧 Windows 生态不完全兼容（如某些 cmdlet 或 COM 对象）。
  • PowerShell ISE：服务器版特有的 GUI 脚本编辑器，界面老旧。
  • 这种不一致性对开发者造成了“地狱”般的混乱。

💎 碎片知识与金句拾遗

• Emacs 在日本：“日本那边用 emacs 的比例高吗？” / “老年人里比较高”、“学校里很多教授都会”、“东大有个做机器人的研究室祖传配置（Scheme写代码）”。———— 一句“祖传配置”，道尽了 Emacs 在老牌极客圈里的独特地位。
• Emacs 与国产编辑器断层：“emacs最先进的年代，老中普遍还用不上电脑呢” / “跳过了unix（不过这是好事😈”…… 群友无意间点出了文字编辑器代差的时代背景。
• 极简主义宣言：“很多大家觉得必要的东西都是被固有的 presets 影响了”、“去掉了，好像没什么影响”—— 针对去除 Modeline 等 UI 元素的反馈，一语中的地揭示了配置过度的普遍心理。
• 关于 Fork 与维护的困惑：“这帮老外很奇怪，自己又想要一个 Firefox 的版本，又不愿意自己 Fork 一个开发” / “他们没明白开源首先是自己用”。 —— 这是来自开发现场的真实感悟，值得每个项目 owner 深思。
• 关于 VScode 风评：“vscode 最近是不是逐渐被抛弃了? 风评下降” —— 一个零星的暴论，但也反映了社区对“宇宙第一 IDE”地位的一些反思。
• 关于老中与 Emacs：“牢中为什么那么不喜欢 emacs” / “年轻一代习惯了触屏手机（iPad）的就更不喜欢 Emacs了” —— 触屏一代 vs. 字母按键与快捷键，这可能是更本质的“代沟”。
• 一个有趣的巧合：“我上一家公司也很多人用 [Emacs]” —— 这句话居然引起了群友的兴趣，可见 Emacs 在公司层面普及度之罕见。
• 关于性能的吐槽：“magit真是太慢了……但是确实好用” —— 简短两句话，道尽所有 Emacs 用户对 magit 又爱又恨的复杂情感。
• 关于 ast-grep 的安利：“它还可以充当语法检查？” / “你可以把某种anti-pattern用ast写出来然后让linter检查” —— 这才是 ast-grep 真正的潜在价值所在。

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

• Neo Emacs (neomacs)：一个 Rust 重写核心的 Emacs 实现。目前已经可以运行 Doom Emacs。关注其 v0.0.8 发布，是 Emacs 多线程/新架构的最前沿尝试。
• emacs-tramp-rpc：一个用于优化 TRAMP 远程文件编辑的 RPC 方案。其作者在维护 magit 的分支，说明这可能是提升远程开发体验的关键项目。
• ast-grep.el：ast-grep 的 Emacs 插件。ast-grep 本身是一个强大的结构化搜索和重构工具，值得深入学习其 lint 规则的编写，实现对代码库的自定义静态分析。
• Rassum Frassum (rass)：用 Python 编写的 Emacs LSP 客户端，旨在解决 Emacs 单线程下多语言服务器低效的问题。这是一个典型的用外部进程解决 Emacs 内部短板的实用主义方案。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“Magit 慢”，而是 Emacs 社区又一次撞上了老系统的根本矛盾：真正难的不是把代码改快，而是在不摧毁生态的前提下，把一个默认单线程、全局可变状态密布的 Lisp 机器，改造成现代交互系统。

1. 多线程不是答案，隔离边界才是答案

群里有人很快指出：问题不只是 buffer-local，连 string-match 这种底层操作都会改全局状态。这句话比“Emacs 要不要多线程”更关键。

共享内存多线程在这里不是银弹，而是炸弹。老包默认一切都在同一个世界里发生：hook、buffer、match data、窗口状态、text properties，很多代码靠隐含顺序活着。直接并行化，等于把历史契约撕掉。

所以更现实的方向不是“让 elisp 全面多线程”，而是重新定义边界：哪些东西必须留在主线程，哪些东西可以 frozen view、message passing、worker/actor 化。JS 模型被提到不是偶然：它的价值不在“也有 worker”，而在它承认主世界不可乱碰，重活通过协议出去，结果再回来。

2. Neo Emacs 的赌注不是 Rust，而是兼容性

Neo Emacs 最有价值的地方，不是“C 换 Rust”这个技术标签，而是它选择 Lisp 层 100% compatible、C 层逻辑一致重写。这是一个很工程化的判断：Emacs 的资产不在核心代码行数，而在几十年 elisp 生态和用户配置里。

如果不能跑 Doom Emacs，架构再漂亮也只是新编辑器；如果能在兼容层上逐步拆渲染、拆进程、拆 IO，它才有资格挑战 GNU Emacs 的路径依赖。群里“还不能生产用，但 v0.0.8 邀请体验”的信息，正好说明它现在处在最关键的验证期：不是验证愿景，而是验证兼容成本能否被持续摊薄。

3. AI Agent 时代反而会放大 Emacs 的老问题

“coding agent 流行以后没打开过 GUI，还是终端舒服”和“vibe 了不管后续，没有维护意愿”放在一起看，很有意思。Agent 会把编辑器从“人手操作界面”推向“任务编排控制台”：更多外部进程、更多日志、更多异步反馈、更多结构化搜索与重写。

这会让 Emacs 的优势和短板同时放大。优势是它本来就是可编程工作台；短板是当 LSP、Magit、agent、TRAMP、终端模拟器都在争主线程时，卡顿不再是体验问题，而是编排系统的可靠性问题。

可继续实践的方向

与其空谈“Emacs 多线程”，不如选一个真实高压场景做基准：大仓库 + Magit + 多 LSP + agent 日志 + ast-grep 重写。记录哪些操作卡 UI、哪些可以外部化、哪些需要共享 buffer 视图。能被这个基准证明的架构改动，才值得进入 Emacs 的未来讨论。

Emacs 轻聊讨论组

好的，收到 327 条群聊记录。虽然大部分为日常闲聊与技术吐槽，但其中关于 Jujutsu (jj) 版本控制 的深度技术思辨值得提炼。以下为今日结构化总结。

---

🎯 核心热点与专题探讨

专题：Jujutsu (jj) 的 Submodule 困境与兼容性之痛

今日最硬核的讨论围绕 Jujutsu (jj) 展开，核心痛点是 如何用 jj 优雅地处理 Git 子模块，以及与 Gerrit 等 Git 工作流的兼容性。

讨论参与者：几位正在进行 jj 深度实践的用户。 核心矛盾：

1. 子模块 (Submodule) 支持不足：参与者 A 在 jj 中处理包含 Git 子模块的项目（如 Gerrit 项目）时遇到问题。参与者 B 提到用 ghq 配合软链接绕过，但不满于 mani 等工具 不支持 jj native。
2. 与 Git 工作流兼容：参与者直言“pr模型肯定还是不契合”，并引用了 AI（可能指 Claude/GPT）的判断，强调 jj 与 Gerrit 平台不是同一逻辑。另有参与者感叹“要和git兼容还是太难了”，认为应该先实现一些更原始的功能。
3. 设计方案反复：参与者 A 分享了一个创意：利用 jj 的 bookmark 机制来实现 submodule 功能，但随后在 05:23 自己推翻：“算了，设计不出来，我之前考虑的显然还是太少了”。

结论与共识：这是一个没有在今日得出解决方案的开放性问题。核心矛盾是 jj 的架构思想（change-centric, stacked PR）与 Git 的 ref-centric 心智模型之间的根本冲突。参与者普遍认为这是一个有意义的探索方向，但短期内没有现成答案。

---

🔑 关键概念与技术解析

• jj-forklift 的 stacks PR: 可能是一个用于 Jujutsu (jj) 的、与堆叠式 PR（Stacked Pull Requests）工作流相关的功能或提案。它暗示了 jj 社区正在尝试解决如何更好地与 GitHub/GitLab 的 PR 生态进行互操作（如处理多个相关分支的依赖关系）。
• heirline (Neovim 插件): 一个高度可定制的 Neovim 状态栏和 Tabline 插件，以使用 Lua 配置、性能良好且灵活性超出 lualine + bufferline 著称。群友用它实现了 LazyVim UI 与 NvChad UI 的混血效果。
• quickshell-git (dankLinux): 可能指一个基于 quickshell 进行深度定制的 Linux 桌面 shell 配置。quickshell 是一个用 C++ 编写的高性能 Wayland shell 组件框架，但此处的“dankLinux”更像是一个用户对其高度定制化配置的昵称（类似于“我的 Arch Linux”），而非一个发行版。
• Tramp-RPC: Emacs 中 Tramp 远程文件编辑方式的优化方案。原生 Tramp 通过 shell 命令执行，速度慢；Tramp-RPC 通过一个远程持久化进程（服务器端）来减少往返通信延迟和文件读取开销。群友反馈即使有优化，magit 在 Tramp 下依然缓慢，说明其瓶颈仍在于大量文件状态读取和同步操作。

---

💎 碎片知识与金句拾遗

• 关于大厂 AI Token 的“钓鱼策略”：一位群友揭示了残酷的现实：

  “大厂们的小算盘，一开始疯狂鼓励大家用 AI，报销额度打满，等大家习惯依赖后，再收紧每位员工的 Token 用量，让离不开 AI 的自掏腰包去买。腾讯被曝，多部门员工月 2000 美金 AI Token 预算，已逐步下调不到 2000 元人民币。”

• 关于省钱与折腾：群友在讨论本地训练模型（MLX）的昂贵与困难时，另一人调侃：

  “我要向你学习这种精神，至少准备个1500亏损预算吧？毕竟得试错。”

  发起人回答：

  “我没准备那么多。我35b租便宜的5090按小时应该不会很贵，单次估计20-30。周末我就按天租。”

• 关于艺术家转码农的幽默：一位马来西亚华人画师（能画水彩、得过全国奖）在群内展示其高度定制的 Neovim 配置（heirline、whichkey 图标全填满），并自嘲：

  “我nvim 真的花了很多心思在ui 上（” “画画的人怎么去碰了linux ricing，nvim 等的东西”

• 关于文生图模型的差距：群友用 wan 2.2 本地跑二次元视频生成，另一位直接用 Gemini 跑出同提示词的效果。结论：

  “相同提示器gemini的效果。。。”“好看太多了我去”“logo为啥不能完全match”。但最终得出的观点是：“我觉得调一调应该也能做出来，区别就是时间长短。”

• 关于“自费”的无力吐槽：

  “自费也没多少钱”，牛马中的牛马。

• 关于赚钱的脑洞：

  “ai炒股” “我还想过到券商开量化接口，然后用ai做操盘计划” “炒股 买体彩” “不如发涩图，每天都发，坚持几个月就有钱了吧” “youtube 的分成怎么样？”

• 关于 Emacs 回退的界面设计：

  “macOS 之前有个版本就是配了icon，但是icon要做到视觉大小一致，上下还对齐太难了，所以后来还是回退了。”

• 关于 Wayland Compositor 的选择：群友从 hyprland (搭配 quickshell) 切换到 niri，认为 niri 更省电且稳定，尤其是 触摸板手势不错，适合笔记本。

---

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

• Jujutsu (jj) 的 bookmark 机制与 submodule 解决方案：这是一个非常前沿且尚未解决的问题。关注 jj 社区（如 jj GitHub repo 的 issues/discussions）关于 submodule 的讨论和 roadmap。对于想从 Git 迁移到 jj 的团队来说，这是一个关键的缺失能力。
• Wan 2.2 开源视频生成模型：这是一个较新的开源视频生成模型，群友尝试用于批量生成短视频。关注其推理效率（尤其是结合本地 GPU 如 5090）和 fine-tuning 的可行性，是一个潜在的副业尝试方向。
• Noctalia v5 (quickshell 替代)：这是一个不依赖 quickshell、完全用 C++ 重写的 Neovim/niri 桌面 shell 配置。其性能优化（从占用 >1G 降到稳定 600M）和稳定性（无崩溃）看起来很有潜力，适合喜欢高度自定义但不想被 quickshell 的不稳定困扰的用户。

🧠 Hermes GPT-5.5 观点延伸

今天最值得咀嚼的不是“jj 怎么支持 submodule”，而是一个更硬的判断：新工具真正的工程门槛，往往不在它自己的抽象是否优雅，而在它能不能穿过旧生态的接口债。

1. jj 的问题不是 submodule，而是“兼容层会吞掉新心智”

群里从 jj-forklift、stacked PR、Gerrit upload，一路聊到用 bookmark 设计 submodule，最后自己推翻方案：“考虑太少了”。这不是失败，反而是很好的工程嗅觉。

jj 的吸引力在于 change-centric：它把“修改”当一等公民，而 Git/Gerrit/submodule 的世界更像 ref、commit、路径和外部仓库指针拼出来的协议集合。你可以做桥接，但桥接越厚，越容易把 jj 拉回 Git 的心智模型里。最后得到的可能不是“jj 支持 submodule”，而是“用 jj 重新实现一遍 Git 的历史包袱”。

所以“先实现一些比较原始的功能”是对的。底层能力先稳定，再谈高阶语义。否则 bookmark 这种优雅机制一旦被拿来承载 submodule 的兼容语义，很容易变成抽象污染。

2. 工具迁移不是 CLI 替换，而是协作协议迁移

“pr 模型肯定还是不契合”这句话比 submodule 本身更关键。很多开发者评估新 VCS 时，会停在命令体验：status 好不好看、rebase 爽不爽、stack 好不好推。但团队真正运行的是协作协议：review 怎么发生、CI 认什么 ref、Gerrit 怎么建 change、机器人怎么读状态、子仓库怎么 pin。

如果这些协议没迁移，个人局部效率提升会被组织边界吃掉。jj 在个人分支管理上很强，但遇到 Gerrit、submodule 这种“历史制度化接口”，就不能只靠更聪明的本地模型解决。

可验证的工程判断是：一个 jj 兼容方案是否靠谱，不看 demo 里能不能跑通，而看三件事：失败时能否回滚到普通 Git；CI/Gerrit 是否无需理解 jj 也能正确工作；多人同时更新子模块指针时冲突语义是否清楚。

3. AI 工具成本讨论其实也是同一个问题

下午聊 AI token 预算、晚上聊本地训练、租 5090、H100/H200、Wan/Gemini 差距，看似跑题，其实同构：先进能力一开始像工具红利，后来会变成依赖成本。云端模型效果好，但额度、价格、隐私、可控性受平台限制；本地模型可控，但要用时间、显卡、调参和失败预算换。

这和 jj 一样：新抽象要落地，最后都要接受工程现实的审判——谁付成本，谁处理边界，谁承担失败。

可继续实践的方向

可以把“jj + Git 旧生态兼容”当成一个小型工程课题：选一个真实含 submodule、Gerrit/PR、CI 的仓库，列出所有外部系统实际读取的 Git 状态，再反推 jj 只需要暴露哪些最小兼容面。别先设计完美 submodule；先证明最小协议闭环。