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

Emacs 中文讨论组

🎯 核心热点与专题探讨

【专题一】NeoMacs 与编辑器选择：未来与传承

群内围绕一个名为 NeoMacs 的新兴项目展开了激烈讨论。该项目被寄予厚望，希望它能像 NeoVim 之于 Vim 一样，成为 Emacs 的现代化分支。讨论的焦点在于：

• 期望与愿景: 成员希望 NeoMacs 能解决 Emacs 的性能瓶颈（如 API 层级多、速度慢），并保持对 Elisp 的兼容性，从而继承 Emacs 庞大的生态。许多人将其与十年前的 NeoVim 项目类比，认为这是一个充满潜力的新起点。
• 现实与挑战: 有经验的成员指出，当前 NeoMacs 距离“可用”还有很大距离，光标动画等炫酷 UI 并非核心。他们强调，Emacs 的核心价值在于其深度可定制性和独特的编程模型（Lisp 运行时），而非表面速度。直接使用 Emacs 并学习 Elisp 被认为是更务实的选择。
• 哲学分歧: 讨论揭示了编辑器选择背后的不同哲学。一方追求极致的速度和现代化（NeoVim/NeoMacs 路线），另一方则看重稳定性、无限的扩展能力和“一个编辑器统治一切”的终极理念（Emacs 路线）。有成员直言：“用上了 Emacs 就不想用别的了。”

【专题二】Emacs 的核心竞争力：超越文本编辑的操作系统

群内深入探讨了 Emacs 区别于其他编辑器（尤其是 Vim/NeoVim 和 VSCode）的独特价值：

• 终极可定制性: Emacs 不仅仅是一个编辑器，更是一个用 Elisp 编写的运行时环境。用户可以在编辑器中直接执行 Elisp 代码来即时改变编辑器的状态和行为，这是其最根本的超级能力。
• 杀手级应用: Org-mode 被多次提及，作为 Emacs 独有的、无可替代的知识管理与生产力工具。此外，Dired（可像文本一样编辑的文件管理器）和 winner-mode（窗口布局历史管理）等内置工具也展示了其深度集成的工作流。
• 统一工作流: 许多成员将 Emacs 作为其数字生活的中心，用于写代码、做笔记（Org-roam）、任务管理（Org-agenda）、碎片收集、甚至邮件和阅读。其理念是卸载所有其他 IDE 和记事本，在一个高度定制化的环境中完成所有事情。
• 性能与配置: 关于“Emacs 慢”的刻板印象受到挑战。有成员指出，在现代硬件上，原生编译的 Emacs 30/31 以及通过 emacsclient 连接守护进程的方式，启动和运行速度都很快。对于新手，推荐使用 Doom Emacs 或 Spacemacs 这类预配置框架降低入门门槛。

【专题三】AI 时代的程序员生存危机与价值重估

聊天记录后半段，话题从工具转向了更宏观的行业焦虑与职业思考：

• AI 的冲击: 成员普遍感受到 AI 编程（如 Copilot）带来的巨大冲击，认为它正在快速“吞噬”软件工程流水线中的中间环节价值。传统的 CRUD 业务开发、前端 UI 堆叠等工作的价值被认为正在急剧下降。
• 价值曲线理论: 有人提出，未来程序员的价值将呈“倒 U 型”分布。最容易被替代的是“传统全栈”（仅会前后端业务开发），而更靠近用户端产品洞察或底层复杂技术（如并发、高性能计算、编译器）的两端，价值更高，更难以被 AI 替代。
• 职业困境与选择: 有成员分享了低薪、高压、背锅的职场经历，表达了对行业现状的失望，甚至认为不如从事保安、外卖等“纯体力活”。讨论中也涉及了应对策略：要么向产品/业务端转型，要么深入底层技术（如学习 Rust 的 Tokio 并发框架），或者拥抱小众但具有超级表达能力的语言（如 Lisp 家族），成为“单打独斗”的异数。

🧠 关键概念与技术解析

• NeoMacs: 一个旨在现代化 Emacs 的新兴开源项目，目标类似 NeoVim，希望重构代码库、提升性能，同时保持 Elisp 兼容性。
• Elisp: Emacs Lisp 的简称，是 Emacs 编辑器的扩展和脚本语言。其核心能力在于允许用户在编辑器运行时动态修改和扩展编辑器自身。
• Org-mode: Emacs 内置的一个强大的文档编辑、项目规划、任务管理和笔记系统，支持层级大纲、时间管理、文学编程等，是许多用户的“杀手级应用”。
• Dired: Emacs 内置的文件管理器，独特之处在于可以进入“编辑模式”（C-x C-q），像编辑普通文本一样批量重命名、删除文件。
• winner-mode: Emacs 内置的一个次要模式，提供 winner-undo 和 winner-redo 命令，用于恢复之前的窗口布局。
• Burly.el: 一个第三方 Emacs 包，可以将当前的窗口和缓冲区布局保存为书签，方便快速恢复复杂的工作场景。
• Evil: 一个 Emacs 插件，在 Emacs 中模拟 Vim 的模态编辑体验。群内对其评价两极分化，有人认为它降低了门槛，有人则认为它破坏了 Emacs 键位的统一性。
• SICP / HtDP: 《计算机程序的构造和解释》与《程序设计方法》的缩写，是两门经典的计算机科学课程，常使用 Scheme/Lisp 系语言教学，与 Emacs/函数式编程社区有深厚渊源。
• Clojure/ClojureScript: 一种运行在 JVM 上的现代 Lisp 方言，以及其可编译为 JavaScript 的兄弟版本。支持同构开发，即用同一套语言和逻辑同时编写前端和后端代码。
• Tokio: Rust 语言中一个广泛使用的异步运行时库，用于编写高性能、高并发的网络服务，代表了向“底层复杂技术”靠拢的方向。

💎 碎片知识与金句拾遗

• 关于速度：“在 Linux 系统不慢，目前最新的 Emacs 30 或者 31 还是很快了。” —— 为 Emacs 正名。
• 关于学习曲线：“我从用 Emacs 到习惯 Emacs，应该花了 2 年左右的。” —— 道出了精通 Emacs 所需的耐心。
• 关于配置：“我现在不纠结了。没有那么完美主义倾向。也不折腾自己的配置了。搞个 Spacemacs，熟悉就好。” —— 从折腾回归实用的心态转变。
• 关于硬件：“25寸，3k，2倍缩放” 和 “墨水屏，其实显示效果极佳”。群内对 大上（Dasung）墨水屏显示器 有实际讨论，关注其护眼效果和价格（25寸约 7-8k）。
• 关于补全：“emacs 补全性能应该是没 vim 和 vscode 好的”—— 对 Emacs 弱点的坦诚。
• 关于 LSP 痛点：“我们公司那项目得开 ts，vue，tailwind 这 3 个 server……内存都会炸掉。” —— 现代前端开发工具链的资源消耗现状。
• 关于语言设计：“Go 是因为类型系统设计得比较差。” —— 对 Go 语言泛型未出现前困境的尖锐评价。
• 一句精辟的总结：“屎山一般都是用很显式的语言写的很隐式的系统。” —— 道出了即使用“工程化”语言，糟糕的设计也会制造出难以维护的代码。
• 一个生动的比喻：“AI 写的代码，最终负责还是要人来……去年我们主管喜欢 copilot 拉屎，我给他擦了好多次屁股。” —— 形象描述了 AI 辅助编程下的责任与负担。
• 关于宏的威力：“有宏就不一样了，可以把前后端代码抽成一个表达式，编译成不同逻辑。” —— 展示了 Lisp 宏在实现领域特定语言和消除重复代码方面的强大能力。

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

1. 追踪 NeoMacs 项目进展:

   • 研究什么: 密切关注 NeoMacs 的 GitHub 仓库，看其架构设计如何平衡性能重构与 Elisp 兼容性。特别关注其如何处理 Emacs 的 C 核心与 Lisp 运行时之间的交互。
   • 怎么研究: 定期查看项目 commit 记录和 Roadmap。可以尝试从源码编译早期版本，测试其与常用 Elisp 包（如 Org-mode, Magit）的兼容性，并对其启动速度、内存占用进行基准测试，与原生 Emacs 进行对比。

2. 探索同构开发与 Lisp 宏在实际项目中的应用:

   • 研究什么: 深入研究 Clojure/ClojureScript 生态，特别是像 Replicant 这样的全栈框架。重点理解如何利用 Lisp 宏（Macro）抽象前后端共享的业务逻辑、API 定义和数据校验，实现“写一次，跑两端”。
   • 怎么研究: 选择一个简单的全栈项目（如 Todo App），分别用传统技术栈和 Clojure 技术栈实现。对比两者在 API 同步、类型安全、代码复用方面的差异。阅读 libpython-clj 这样的项目，理解 Lisp 语言如何优雅地桥接其他庞大生态（如 Python）。

3. 评估 AI 时代下的“硬核”技术护城河:

   • 研究什么: 针对群内提出的“价值曲线两端”理论，选择一端进行深入。例如，深入研究 Rust 的 Tokio 异步编程模型，编写一个高性能、高并发的网络服务（如自定义协议网关）。
   • 怎么研究: 通过实现一个非玩具项目来体会复杂性，例如一个支持自定义过滤规则的异步网络代理，或一个简单的分布式键值存储。在此过程中，记录哪些问题 AI 能较好辅助，哪些复杂并发 Bug 必须依靠人的深度推理和系统性知识来解决，从而切身感受所谓“难以被替代”的技术领域究竟有何特点。

Emacs 轻聊讨论组

今日尚未生成该讨论组总结。