我如何深度整合Emacs

共有 139 条讨论

1. > 我见过当工具不再成为阻碍，人们得以自由创作时所能达到的境界。这就是世界级运动员、音乐家、艺术家、作家，当然还有程序员们将脑海中的构想转化为现实的方式。

   我认为这是个谬误。若带着工具偏见去探究这些人的成就，你终将得出工具是成功关键的结论。

   现实中，多数人最初怀揣着强烈的成就渴望，其余皆随之而来。若想成为世界级音乐家，先开始练习乐器吧。最好能爱上音乐本身，严谨细致的练习计划自然会随之而来。

   换言之：纵使拥有全球顶尖的工具，若缺乏内在驱动力，你依然会像从前那样无所作为。

   这个创意很酷，听起来充满趣味与创造力。我无意贬低它，但也不希望人们产生“工具→成功”是正确路径的误解——在我看来，这种认知是错误的。

   回复

   1. 我愿更进一步。世间顶尖的工具往往只适用于顶尖使用者。例证比比皆是：顶级车手驾驭的车辆，我几乎必然会撞毁；顶尖飞行员操控的飞机，我连操控原理都无法理解(奇怪的是，汽车也存在同样现象)。

      一把顶级吉他反而容易弹错音符——正因优秀吉他手通常不会失误。

      现在我觉得可以稍作改写：顶尖表演者对工具了如指掌，甚至能与之融为一体。这固然需要工具具备一定品质，但表演者自身更需付出巨大努力。

      回复

   2. 你让我想起这段话：“若想造船，莫要鼓动众人去砍伐木材、划分任务、发布命令。不如教他们向往那浩瀚无垠的大海。”——安托万·德·圣埃克苏佩里

      回复

      1. “若想建造百艘船，请参照前文”

         回复

   3. 我的理解略有不同：若工具成为阻碍，不仅会削弱效能，更会抬高专业人士发挥最佳水平的门槛。诚然顶尖人才无惧工具限制，但若工具品质更优且“不碍事”，就能让更多人以更少阻力发挥极致潜能。

      回复

      1. > 若工具品质更优且更“不碍事”，就能让更多人以更少阻力发挥极致水平。

         我认为YuukiRey的观点在于：这种说法并不成立。阻碍人们发挥极致潜能的瓶颈，几乎从来不是工具造成的阻力——除非你已具备扎实的既有技能基础。绝大多数情况下，阻碍在于动力、兴趣、时间、精力等因素。

         理论上工具确实能提供帮助。但实践中，对工具的追求往往沦为干扰。这正是“GAS”(装备获取综合症)这种(过度贬义的)概念产生的根源。在数字领域，类似现象就是作家耗费金钱和时间寻找完美文本编辑器、完美键盘、完美显示器等组合，却始终无暇写作。当然存在工具确实是核心突破点的例外情况，但这类案例凤毛麟角。

         事实上我从YuukiRey的观点中领悟到的是相反的道理：

         > 没错，顶尖天赋者无论用什么都能出类拔萃

         关键在于：顶级工具仅对顶尖人才真正有意义，因为对绝大多数人而言，工具本身并非瓶颈所在。

         回复

         1. 拙匠诬器

            回复

   4. > 若你带着工具偏见去探究这些人的成就，就会得出工具对成功至关重要的结论。

      我认为你引用的作者观点是：要避免工具成为阻碍。若你是作家，成功之道在于写出好作品。若操作系统崩溃，写作时还得反复点击菜单，创作效率自然大打折扣。这正是十多年前众多博主采用Markdown的原因——纯文本写作让工具不再成为阻碍。关键不在于工具能否提升效率，而在于选择不会拖累效率的工具。

      回复

   5. 或许这是谬论，或许并非如此。但我常听人说“我不使用工具X，因为它并不能真正提升我的效率”。这里的X可能是emacs、调试器、性能分析器、Linux系统、版本控制、代码注释等等。长期观察这类人的工作方式后，我认定他们大多只是在为自己的懒惰找借口。结果因人而异。

      回复

   6. 确实如此。当你拥有卓越的技艺时，劣质的工具会成为制约因素。但精良的工具无法弥补技艺的不足。

      回复

   7. 赞同。纵使拥有最顶尖的工具，也无法保证“成功”。

      回复

   8. 我认为这种说法过于简单化。在我看来，艺术与科技更像是场舞蹈，难以分辨谁在引领谁。

      例如：摄影术的发明催生了印象派与安迪·沃霍尔的全部创作。当今最受瞩目的艺术家Beeple(其作品在传播媒介、工具乃至创作技法［如“每日创作”］上都极具技术前瞻性)便是明证。

      音乐领域体现得尤为深刻：迈尔斯·戴维斯与披头士的职业轨迹皆始于萌芽期的录音产业，最终却在配备尖端设备的专业录音室完成创作——那些乐器与技术在短短五至十年间才得以诞生。

      电子音乐领域尤为显著，例如Native Instruments的Massive合成器催生了dubstep流派，这便是鲜明的例证。若纵观电子音乐发展脉络，这种关联性不言自明——2000年前的音乐作品往往因制作方式而显露年代感：如今音乐人使用DAW数字音频工作站，而过去则依赖功能有限的硬件设备，这些设备不仅产生特定音色，更带来编曲与创作上的多重限制。

      这恰恰印证了你提到的观点：艺术(或任何领域)的成功很大程度上取决于你投入其中的热情与动力。当你探索充满未开发潜力的全新领域时，激情更易迸发——历史上这类突破往往由技术驱动。反之，若学习萨克斯时总拿自己的即兴独奏与约翰·柯川比较，只会令人丧失斗志，产生“永远无法企及”的挫败感，最终放弃努力。此外还存在收益递减效应——例如音乐领域已被深度开垦，培养特定技能(达到该级别的爵士演奏)的回报率已然降低，因为艺术疆域的大部分疆土早已被探索殆尽。

      若将这些观点回归艺术本身，我认为当今已存在技术更精湛的萨克斯独奏家——例如对音乐理论的理解更深入，且数十年的实践迭代已完善演奏技法(现今相关书籍与研究成果浩如烟海)。但你无法复制当年那些音乐家们所感受到的纯粹激情——他们通过反复推敲音乐理论(一种技术形式)来开辟新的音乐可能性，并借助录音这一新兴媒介进行分享与学习。

      需要澄清的是，我基本认同你的观点，但需补充更细致的理解：应借助技术让创作过程尽可能激发你的热情，但这种热情的核心目标在于驱动你持续练习与进步。同时要发掘未被开发的潜力(例如：一个与当下相关的具体案例——我认为基于GPU的渲染技术至今仍未被充分探索。Beeple虽已将其运用于艺术创作，但高昂的入门门槛[职业生涯中硬件/软件成本可能累计达1万美元以上]意味着该领域仍蕴藏着巨大潜力。

      例如Daft Punk在技术普及后仍能开辟新境地https://pitchfork.com/features/lists-and-guides/9277-the-yea…：

      > 技术让音乐创作变得触手可及，这在哲学层面颇具趣味性，固然可喜。但另一方面，当人人都能施展魔法时，魔法反而消失了——若听众自己就能创作，他们何必费心去欣赏呢？

      回复

   9. 这在一篇关于Emacs的文章里显得尤为讽刺——这款软件常让人陷入这样的困境：本该“专注创作”的时间，却变成“管理我的定制Emacs，求别搞砸”。

      回复

      1. 不妨将其视为一种创作实践。任何实践的重要部分都需投入技巧锤炼。

         有人满足于标准化但未优化的工具，有人痴迷于打造自己的高阶TUI界面。过程即目标。即便你只写了个配置文件，也算数。

         回复

2. 我深爱Emacs。初识它是在2008年左右的Braille Plus移动管理器上——那台运行Linux的设备专为盲人设计，堪称绝世之作。此后再无同类产品。BT Speak虽是基于树莓派4的仿制品，却因Linux辅助功能难以适配低功耗设备而运行迟缓。

   总之，我开始在那个点字机Plus上的Emacs教程里学习Emacs命令，这些命令对我来说很有意义。可惜的是，Emacspeak在Linux和Mac上运行良好，但在Windows上却不行——而所有盲人都用Windows。Speechd-el只能在Linux上运行，因为它依赖Speech-dispatcher。不过昨晚我在安卓的Termux上成功让Speechd-el发声了，虽然按键与语音之间存在明显延迟。Emacspeak的开发已暂停，而Speechd-el似乎也有半年未更新。Emacs本身包含大量普通屏幕阅读器难以解析的内容，这正是Emacs专用语音接口如此实用的原因。

   以下是几个示例：

   * 在Windows系统中，使用Windows终端和NVDA屏幕阅读器时，方向键会朗读光标位置，但C-n/C-p、C-f/C-b等组合键NVDA不会发声。这是因为启用了-nw命令行选项，导致GUI不可访问。* 但执行 M-x 时，它会报读“minibuf帮助，M-x，Windows Powershell终端”。此时可通过list-package+RET命令浏览软件包，方向键可移动选项，但N/P键虽能切换软件包却无语音反馈。可见回显区功能正常。* 然而日历等程序与屏幕阅读器的配合效果极差。它只会朗读整行内容，而非聚焦的日期。左右方向键操作时仅报读“1 2 3 4 5”等数字序列。可见自定义界面存在严重缺陷，想到它处理Helm时的表现就令人不寒而栗。

   哈哈，或许能让AI为Windows版Emacspeak开发优质语音服务器。

   回复

   1. 太棒了。

      我真心希望让自己的网页应用尽可能对盲人友好。

      能否告诉我这方面的最佳实践和最糟做法？

      有什么推荐的文章吗？

      如何测试网页应用对盲人的无障碍性？或许尝试仅用屏幕阅读器和键盘操作？

      回复

   2. 你让我既惊叹又谦卑。感谢分享经验！

      回复

3. 我发现最流畅的跨设备捕捉工作流是在手机主屏设置快捷键：点击后即可录入语音、转录文字，并以org-syntax时间戳格式保存至inbox.org文件，同步至主电脑。

   这些笔记采用与org-mode日志簿相同的格式，但也可设置为独立待办事项标题等形式——毕竟都是纯文本。

   我坚持每天清晨清空inbox.org，通常处理20-30条记录。重要事项会修订归档，其余则按时间顺序存入日志文件以备查阅。

   编辑：顺便一提，若能开发一个版本，将手机剪贴板内容自动追加到转录文本中就太棒了，这样就能捕捉链接和/或文本片段。甚至可能支持多媒体内容，不过还不确定如何实现。

   回复

   1. 二十年来我始终依赖无缝捕捉功能，这与《搞定》理念不谋而合。

      我的解决方案是使用Twilio短信号码，自动将接收到的任何文本插入我的todo.md文件顶部。此前使用todo.org服务，直到大约一年前。

      iOS系统无处不在地支持从任何界面快速分享至短信。通过主屏幕快捷方式向该联系人发送短信很简单，同时几乎所有应用的分享菜单也能实现此功能。

      回复

   2. 我非常想了解你描述的快捷方式。这个工作流对我而言将极具价值——我的笔记已通过syncthing同步，捕捉工具使用Orgzly Revived，但自动转录捕捉内容将彻底改变我的工作模式。

      回复

      1. 这是个iPhone快捷指令。链接在此：https://www.icloud.com/shortcuts/a8a0076cc03f4e699d8ca34bd3d…

         我把inbox.org存放在Dropbox里，这样就能保持同步。

         这个快捷指令叫“longdictate”，因为之前有个版本不需要我在说完后按停止键——它会自动在我说完时停止录音。但误触率太高，经常打断我，所以后来加了这个按钮。

         安卓系统应该也有类似iPhone快捷指令的功能吧？

         回复

   3. 太棒了——你用安卓设备吗？

      我在iPhone上尝试过类似方案，但始终找不到可靠(甚至任何)方法运行rsync脚本。

      最终还是回归纸笔记录，综合考量这对我最合适。

      回复

      1. 是的，iPhone。我把文件存放在Dropbox里，这样就能保持同步。

         快捷方式：https://www.icloud.com/shortcuts/a8a0076cc03f4e699d8ca34bd3d…

         回复

      2. 这并非rsync，但你可以将a-Shell[0]与iOS快捷指令集成。不过需要注意的是，同步操作需在脚本中实现，而非后台自动进行。我通过Python脚本为邮件创建别名，这样就无需在收件箱启用通配符地址功能。

         [0] https://github.com/holzschu/a-shell

         回复

4. 这是基于功能/工作流的绝佳入门指南

   岁月流转间，人们逐渐领悟到，诸如Org、Dired等所谓“功能”本质上不过是幻象。它们只是他人编写的Elisp代码并冠以名称。你可以采纳或舍弃它们，亦可编写自定义代码进行修改/扩展/定制。

   一切皆由你掌控。你无需依赖所谓的“神圣插件架构”，更不必等待IntelliJ产品经理的许可。

   终有一日你会领悟Emacs的“可编程外壳”本质——屏幕上每个文本单元都可被赋予特定含义(参见人机交互研究中的“识别器”概念)，并通过编辑器自身或外部进程/脚本执行操作。若操作足够频繁，就创建键绑定。这是你的家，随心所欲

   根据环境配置，你或许再也不用面对无法掌控的文本。从此摆脱“应用程序开发者”的桎梏

   我自2005年便开始使用它。猜猜当年那些热门编辑器如今还有多少存活？

   给真正想学习者的建议：从纯净默认配置起步，包括那些古怪的默认键位，完成内置教程后，仅添加自己编写且理解的配置项。用其自身逻辑去理解它。虽然各类扩展包提供“炫酷功能”，但堆砌的复杂依赖关系对新手而言晦涩难懂，反而阻碍学习进程——这是我的观点。

   回复

   1. 1995至2006年间，我因工作环境的UNIX系统缺乏专业IDE，便用它替代。

      当这个需求消失后，我便告别了Emacs。

      回复

      1. 某些项目(尤其工作场景)中，我完全接受使用IDE。但当我需要折腾多个生态系统和操作系统时，有时根本无法获得IDE支持。几乎在所有系统上，我只需复制init.el文件，几分钟就能复现全部工具环境。

         回复

5. 越是深入了解Emacs，越觉得几十年前我们在桌面隐喻这条路上选错了岔路。

   回复

   1. 对我而言，Emacs的强大之处在于能完全依靠键盘操作——这不仅效率更高，而且比起用鼠标点击视觉菜单，体验也更令人愉悦。

      对键盘操作不熟练者而言，这恐怕是场噩梦。我认为它适合资深用户却令普通用户望而却步，且不确定能否真正打造出兼顾两者的界面——通常只能取舍。

      Emacs令我着迷的另一特性是能实现任何可编程功能。这点在资深用户与普通用户间的鸿沟更为显著。

      我认为这类工具注定只能吸引少数精英用户。

      回复

      1. 二十多年前接触Emacs时，“只用键盘操作”曾是极大的骄傲，至今我仍不明白其意义何在。谁在乎呢？我使用Emacs正是因为能编写整个操作环境。

         本质上鼠标只是模态编辑的一种形式。Emacs当然对此支持得淋漓尽致，神模式就是我首选的模态输入次要模式，但点击跳转到屏幕位置往往比搜索或avy-jump命令快得多，更不用说对腕部更温和了。此外还能自定义菜单和工具栏图标，让原本需要组合键甚至 M-x 命令才能实现的功能，只需点击一两次即可完成。

         鼠标最大的优势在于：单手操作时，另一只手还能边喝饮料边吃零食，同时滚动浏览代码或文本。如今我用左手操作轨迹球。无论如何，键盘与鼠标之争在我看来始终是技术圈诸多无谓争论之一。

         回复

         1. 用适合你的方式。

            我的浅见：

            几乎所有人体工学专家都会告诉你，鼠标使用比键盘操作更易引发人体工学问题。他们会明确建议你尽可能多地记忆键盘快捷键。

            > 但点击跳转到屏幕位置往往比搜索快得多

            确实可能更快，但这是常态吗？我清晰记得——十五年前读过一篇推荐isearch移动光标的博文，当时就深以为然。不过显然并非人人认同。

            > 更别提它对手腕的保护效果了

            劣质鼠标的危害堪比键盘操作姿势不当。只有当疼痛来袭时你才会意识到，但并非所有人都能忍受至此。

            > 更不用说它对手腕有多么温和

            你 不该 移动手腕！动整个手臂。再次强调，只有当你感到疼痛时才会意识到这一点。并非所有人都能忍到疼痛的程度。

            > 然后你可以自定义菜单和工具栏图标，让原本需要组合键甚至更复杂的M-x命令的功能，只需1-2次点击就能完成。

            键盘操作同样适用此理。若选择为特定命令 定制 菜单，亦可通过键盘定制(如使用hydra)来缩减这些命令的按键次数。

            回复

            1. 这篇博文？

               https://sites.google.com/site/steveyegge2/effective-emacs

               养成使用 Ctrl-r(isearch-backward)和 Ctrl-s(isearch-forward)在文档中移动的习惯。当需要跳转超过5行的位置且能看到目标区域时，请务必使用i-search功能。

               高效操作的关键在于：不必精确定位目标词汇。让视线稍作放松，整体扫视目标点周围的段落或区域，选择一个相对独特或易输入的词汇。随后通过i-search导航至该位置。若锚定词不够独特，可能需要反复按Ctrl-r或Ctrl-s。但Emacs会高亮所有匹配项，若存在多个匹配项，请按Ctrl-g退出搜索并选择其他锚定词。

               此技巧一旦掌握，其强大之处难以言喻。掌握它只需反复练习直至手指“自动”操作。Emacs终将如身体延伸般自然，数百种键盘操作与微技巧将化作无意识的本能——这恰似驾驭汽车时习得的数百种精妙技巧。

               回复

            2. > 几乎所有人体工学专家都会告诉你：鼠标使用比键盘操作更易引发人体工学疼痛。他们会明确建议你尽可能多地记忆键盘快捷键。

               没错，但这是因为他们的建议针对的是“普通”电脑使用场景——大量在深层菜单中点击鼠标，以及在键盘上逐个敲击字符。RSI的本质正如其名：重复性劳损。缓解RSI的最佳方式就是停止对相同肌腱和韧带的重复性劳损。这意味着：键盘操作时穿插鼠标操作，交替使用不同手指和双手，起身伸展休息，甚至用语音输入替代物理输入设备。

               若只是文字编辑，鼠标操作主要用于滚动屏幕——这与CAD设计或插画等场景不同。在Emacs这类环境中，使用鼠标完全没问题。

               就我自身的RSI而言，运动才是真正有效的解决方案。攀岩显著改善了手腕血液循环，这或许是唯一真正的治愈之道。

               回复

         2. > 谁在乎？

            那些因长期伸手抓鼠标而患上RSI的人。

            回复

            1. 编程多年后，我的键盘高度绝不能超过膝盖。我直接将键盘放在腿上编程，鼠标完全用不上。一旦键盘抬高，我的手就会变得笨重如木杵。

               我钟爱emacs，因为键盘就能搞定一切。效率更高，长期使用对身体也更友好。我的建议是趁年轻开始：键盘直接放在腿上，搭配正交线性键盘，减少手指移动距离。起初我也持怀疑态度，但现在绝不会回头。

               回复

            2. 啊，像我的eMacs小指和拇指那样？;)

               我最近真的因过度使用左Alt键导致拇指剧痛，专门找了骨科专家治疗。

               回复

               1. 左右Alt键交替使用。人体工学专家的经验法则(绝无双关之意)是均衡使用键盘两侧。例如按Alt-x时就用右侧Alt键。

                  职业生涯早期我也曾受重复性劳损困扰，仅靠这条建议就 真正 缓解了症状。从未出现过Emacs小指/拇指问题。最近转用MacOS后， 这次 是Meta键过度使用导致拇指不适。现在必须有意识地强迫自己用其他手指按Meta键。

                  永远记住：你有五根手指——没必要总用同一两根手指按Ctrl或Alt键。让大脑适应用其他手指操作需要时间。

                  对了，确实因使用鼠标引发过大量人体工学疼痛。事实上，我从“传统”工程转行到软件工程，部分原因就是为了避免使用鼠标(比如CAD软件)。每位人体工学专家都会告诉你：“牢记键盘快捷键，尽可能减少鼠标使用。”

                  正如兄弟评论所言，那时候我就开始关注人体工学配件了。

                  我的主力鼠标是轨迹球鼠标，因为用普通鼠标在桌面上操作时，我的手臂(肘部和肩膀)会感到疼痛。

                  未来我可能会考虑入手分体式键盘。不过我确实因键程问题选了机械键盘。加上我盲打，实际接触键盘的时间反而更少。

                  回复

               2. 人体工学键盘确实有帮助。我喜欢Kinesis Advantage，但作为键盘价格偏高。

                  回复

            3. 啊对，通过减少动作变化、增加重复动作来预防劳损。

               回复

         3. > 无论如何，键盘与鼠标之争始终让我觉得是技术圈诸多无谓争论之一。

            确实。我倒不认为文本编辑速度是软件开发中的关键瓶颈。对我而言这过程充满乐趣，正是提升效率的重要因素——当然这只是个人体验。

            我的核心观点在于：键盘(高效使用需长期学习)与鼠标(学习门槛较低)之争，恰恰说明了当前桌面隐喻为何能战胜那些本应为键盘深度操作设计的方案(即便后者仍可通过鼠标使用)。你提到的“编写整个环境”概念亦是另一例证。重读自己的评论后，我意识到表达可能不够严谨，甚至像在挑起争论呢 😀

            回复

            1. 我的核心观点在于：键盘(高效使用需长期学习)与鼠标(学习门槛较低)的对比，恰恰说明了为何当前的桌面隐喻能战胜我认为专为重度键盘操作设计的方案(即便后者仍可脱离键盘使用)。

               这种键鼠对比似乎带有程序员的隧道视野。涉及版面设计、图表绘制、多媒体编辑(音频/视频/图像)、3D建模和绘图等领域，我们都认同鼠标(配合键盘)更胜一筹。正是鼠标与键盘的协同作用，才使计算机成为如此成功的创作媒介。编程在我看来是个特例——它是少数无法从鼠标中获得显著优势的创作任务。

               回复

               1. Acme编辑器堪称鼠标操作的典范。即便Emacs在鼠标适配性上也优于多数编辑器。

                  回复

         4. 人们常忽略Emacs的本质——它首先是Lisp环境，具备完全可编程特性。它能被完全定制为专属工具。即便键盘的人体工学设计(至少对我而言)确实加分，也无其他产品能媲美。实时调整工作区以优化流程，这才是其核心价值所在。

            回复

            1. 正因如此，即便它是更优的操作系统环境，我的祖母也永远不会使用它。

               由于Emacs普及不足且采用率低，用户仍需使用Notion、Outlook等企业安全要求的工具。

               回复

               1. 我不会辩称Emacs“适合所有人”，生活中我也有许多乐于接受默认设置的领域。但话说回来，若真有必要，将Emacs与现有工具整合并非难事。即便你只能通过受限的邮件客户端发信，仍可借助Emacs和胶合代码实现自动化。在MacOS上，AppleScript能创造奇迹；Windows有AutoHotKey；Linux则天生具备无限可塑性。

                  回复

         5. 我认为这完全偏离了重点。关键不在于键盘与鼠标客观上孰优孰劣，而在于主观舒适度。若某个系统使用起来“感觉”更舒适，我就会更有动力使用它，从而增加使用频率并提升效率——这本身就是选择它的充分理由。对我而言，这意味着选择键盘而非鼠标。

            回复

         6. 这里大量评论宣称键盘比鼠标更符合人体工学，我从未听闻此说，且直觉上就觉得有误(这叫 重复性 劳损，使用多种输入方式本应有所帮助)。

            但总之，若你坚持此观点，请提供 某种依据 。

            回复

            1. 这是最古老的“程序员身份认同”形式之一，属于黑客文化群体表达的口号式宣言，其真实性早已无关紧要。某种意义上堪称社交媒体的先驱——后者本就习惯性地将群体口号置于数据之上。毕竟程序员才是社交媒体的发明者与开创者。

               回复

         7. 过度使用鼠标会引发重复性劳损。坦白说，比起Emacs，使用Vim(或如今的neovim)更能预防这种问题…

            回复

      2. 鼠标(或触摸屏)能完成 所有 操作。让我们从这些开始：

         (xterm-mouse-mode 1)
         (global-set-key (kbd “<mouse-5>”) 'scroll-up-command)
         (global-set-key (kbd “<mouse-4>”) 'scroll-down-command) 
           (global-set-key (kbd “<wheel-up>”) 'scroll-up-command)
           (global-set-key (kbd “<wheel-down>”) 'scroll-down-command)
         

         回复

      3. > 我最爱的Emacs功能莫过于能用代码实现任何想象中的操作。

         但你本来就能做到吧？Emacs 并非首次允许执行 Lisp 代码

         回复

         1. 这不仅在于它使用 Lisp。我确实喜欢这一点，也认为这是正确的选择。更重要的是，即便是“光标向下移动”这样基础的操作，也未直接绑定到特定按键。更惊人的是，只要你提出请求，帮助系统会直接带你查看任何命令的源代码(需配置才能深入到C源代码层级，但功能确实存在)。

            这就像遇到“ls”命令的问题时，想快速扫描源代码解决——在Emacs里往往只需按个键就能实现。而在多数系统里？祝你好运吧。

            回复

      4. 信不信由你，即便在Windows系统也能实现100%纯键盘操作。我有个朋友是Windows服务器管理员(微软的忠实拥趸)，他完全不用鼠标。

         回复

         1. 你 可以 这么做，但未必 应该 这么做。

            我曾效仿《EVE Online》里那位无需鼠标就能飞速完成任务的伙伴尝试过。天啊，光是按Tab键切换界面就耗费大量时间——某些操作需要反复切换15次才能完成，而用鼠标点击只需不到一秒。

            回复

            1. 正因如此，多数程序都支持Alt+快捷键组合。

               回复

   2. Emacs适合乐于折腾工具、按需调整的人群。它确实大幅提升了我的生活质量。

      但很多人讨厌这种特性——他们想要的工具必须把所有相关功能置于核心位置，无关功能要隐形或直接移除，且不提供任何可调整选项。工具应该开箱即用，最好永远不变。

      折中方案是那些开箱即用却能通过扩展深度定制的浏览器。MS Office也是典型代表。

      回复

      1. > 许多人厌恶这种设计，他们想要的工具应将所有相关功能置于核心位置[…]

         许多人甚至不懂如何正确使用工具。记得我给程序员讲授Perl课程时，他们常拿我用emacs开玩笑，自己却用vi或vim。

         但当我观察他们做练习时，总能听到光标触及行尾时发出的“咚”声。为什么？因为他们按下光标键后，总要等光标移动到行尾，再切换插入模式才开始输入。

         就连我这个卑微的emacs用户都清楚，vi里有直接跳转行尾并插入内容的命令。

         回复

         1. 我说的不是Emacs或Perl这类超灵活工具。我指的是那些专注单一功能、运行流畅、无需(甚至禁止)任何调整的工具。锤子、钢锯、复印机、自动售货机，或是像age这样的软件，又或是notepad.exe。它们能在极短时间内被完全掌握，即便你在不同车间拿起一把钢锯，它的工作原理也几乎与你的那把完全一致。

            某种程度上，这与某些人偏爱C语言的逻辑相似——他们宁愿在底层精确指令机器执行操作，也不愿选择TypeScript、C++这类抽象丰富的语言，更不用说Lisp了。后者虽需通过抽象层调整来优雅准确地表达解决方案，却往往缺乏直接性。

            回复

            1. > 自动售货机

               它给了我橙汁，我想要柠檬柠檬水。另一台吞了我的硬币。

               但务实而言，多数任务需要多步骤完成(比如我们通常用邮件编写程序同时发送邮件)，因此僵化的工具有时不够便捷。

               再看普通剪刀。它们专精一事且做得出色——除非手柄方向不对。试着用右手剪刀换左手操作，那简直笨拙得要命。

               回复

      2. > 他们想要的工具应将任务相关功能置于核心位置，无关功能则隐匿或缺席

         这正是Emacs的精髓。你只需将相关功能拖至顶部，无关功能自然沉入底层。

         关键在于Emacs中，多数工具不会预设功能使用方式。即便存在默认设置，也仅是建议。你获得的不是需要学习适应的工具，而是工具的模板/理念/初始版本，由你亲手打造专属形态。

         更重要的是整合理念而非孤立工具。

         回复

         1. 那些假定用户具备能力却依然彬彬有礼的工具，使用起来真是令人愉悦。

            回复

      3. > […] 人们讨厌那个 […]

         但这只是文化，且极易被塑造。许多人宁愿整天赌博看色情内容，但我们认定这不是最佳人生选择……于是建立起一套体系(学校)来管理他们的学习过程，引导他们十多年，再将其纳入经济和社会体系。同样地，我们也建立文化机制来确保人们掌握营养、出行、人际关系等基本技能。

         近年来，这些机制正以“便利”之名不断消解，未来几十年恐将引发恶性后果。我认为让隐蔽的模式主导计算领域同样危险。

         回复

      4. 有些人只想“埋头做事”，不愿多年积累工具箱。我认为若某项操作仅需执行一次，未来大概率还会重复，因此环境能大幅缩短达成目标的时间成本。某些任务的投入产出递减，但我在emacs中编写的脚本每天运行时，每次都能节省数分钟。

         回复

      5. > 很多人讨厌这样

         但这种态度对开发者而言似乎很奇怪。我对事物运作原理的好奇心，以及让计算机精准执行我指令时的喜悦，正是我以编程为生的动力。

         回复

         1. 我属于这类人，或许能解释清楚。我也想学习Emacs，为窗口管理器打造完美配置等等，但除此之外还有长长的待办清单——想做的事、想建的东西、想学的东西。我的时间有限，生活其他需求更消耗精力，自然需要取舍。

            回复

            1. 这听起来不像“厌恶”，更像是时间管理决策。我对此持保留意见——我认为投入时间打造优质开发环境，在整体效率层面能获得显著回报(当然存在上限)，但选择权在你手中。Emacs确实并非适合所有人，即便在热衷折腾的人群中也是如此。

               回复

         2. 人生处处是抉择点。将决策资源投入真正重要的事物——比如项目、工作或金钱——而非编辑器配置这类次要事项，完全合情合理。数十载Emacs生涯中，我既经历过疯狂折腾的时期，也曾有过多年毫无建树的阶段。

            回复

         3. 完全赞同。但同时我敢打赌，相当一部分开发者并非出于对计算机和折腾的热爱才投身其中。这本身并非坏事，只是我的观察。

            回复

   3. 我完全认同——我们本可以拥有完全统一的计算环境，结果却得到了…应用程序。

      回复

   4. 我发现Emacs开箱即用就很出色(除了会生成带~结尾的烦人备份文件)。我用它替代了nano和vim。

      回复

   5. 斯托曼说得对。

      回复

   6. Emacs在自身隐喻中走错了岔路。长远来看，能在生产环境与编辑器间自由调用代码库才是颠覆性变革。尽管Elisp的设计理念有其合理性，但在权衡取舍中，它终究败给了所有具备通用编程生态的Lisp语言。

      我对基于Common Lisp的Lem抱有期待。我们只需汇聚足够的信号，让潜在用户感知行动的时机已然成熟。为 Lem 点赞 https://github.com/lem-project/lem

      我对 org 模式也有同感。不错。能在团队中使用吗？现实点吧。我更希望 markdown 能增强嵌入数据功能。它不是 XML，这很好。但 org 模式实在太奇怪了。据我所知它仍在探索内联数据嵌入，因此嵌入能力其实很有限。比如用CSS类包裹特定词汇导出时，可能需要使用笨拙的字面语法。

      Emacs的修道院式文化带来必然后果——它极擅长自我封闭。若无法接受这种取舍，你只能继续寻找替代方案。

      回复

   7. Emacs本应近乎完美，唯一阻碍它的只有Emacs本身。

      至今仍难以置信我们有给奶奶用的IRC(Slack)，却没有给奶奶用的Emacs。

      人们总纠结于它的可编程性，但核心在于其界面设计，以及同时颠覆桌面与终端范式的理念。

      回复

   8. 越了解Emacs就越庆幸自己没加入这个邪教

      别用70年代的“人体工学”(如果这还能称作工学的话)浪费我的时间

      将它与艺术相提并论简直令人不快。你不是在创作艺术，只是在为Emacs开发又一个插件——让别人用效率可能低5%的方式完成工作，却懒得花两天时间自动化处理。

      回复

      1. Emacs没有插件。它只有一个小型C语言核心(内核)负责处理底层细节，其余功能均由Lisp代码实现，这些代码被拆分为各类包(库和工具)。作为Lisp语言，你可以随意修改和重定义任何符号。

         关键在于，内置和第三方包已足够丰富，你几乎无需编写自己的代码。我的整个配置过程基本就是设置选项和组合包。

         回复

      2. 虽然存在诸多限制，但个人认为“耗时两天”的说法如今已不复存在——得益于大型语言模型，它们能根据基本规范生成基本正确的elisp代码。当然结果因人而异。我发现对于特定场景，这种效率提升远不止“可能提高5%”——它几乎消除了“希望编辑器能实现<x>功能”与实际拥有该功能之间的摩擦，是我用过最接近理想状态的环境。

         回复

6. 想请教资深Emacs用户：

   你们如何看待Doom Emacs或Spacemacs这类强意见化发行版？

   我长期用Doom Emacs进行日常日记和任务管理。选择它的理由是预配置已达到合理标准，而实际文本编辑时，作为资深vim爱好者，evil模式完全能满足需求。

   然而每当我试图突破预配置的“安全边界”——即仅通过leader键操作的领域时，总会感到无所适从。对于系统更底层的交互方式，我缺乏直观的把握能力。

   既然渴望深入探索，我意识到需要重新研读推荐的教程或书籍。

   是否该彻底重装Emacs？

   PS：我过去接触过多种Lisp语言，也对Doom进行过基础定制，所以基本能摸清门路，但总觉得不太顺手。

   回复

   1. 我个人认为：禁用菜单栏的发行版很糟糕，采用极端暗黑主题的发行版很糟糕，两者兼具的发行版简直不堪入目。尤其针对Doom，我讨厌它默认采用Vi键位映射(我极度厌恶模态编辑模式，这正是我使用五年Vim后弃用的原因)，还改动了's'键功能，连肌肉记忆都无法依赖。

      我试过Spacemacs和Doom(以及Witchmacs、Bedrock等其他方案)，现在只用自己写的800行init.el(含注释和空格，实际行数更少)和110行custom.el (若将custom文件设为独立于init的文件，手动编辑init时使用customize修改设置就不会出错)。

      若你真心喜欢Doom，不妨尝试研读其代码库；若觉得负担过重，或许从零开始配置自己的环境更合适。

      回复

      1. 我认为部分批评有失公允，因为这些问题其实很容易解决。例如禁用evil模式或更换主题，在Doom配置中只需一行修改。毕竟任何有主见的Emacs发行版都必须做出某些选择，否则用户使用它们就毫无意义。

         对我而言，Doom的主要问题在于：(a)整体引入的复杂性过高，(b)预装配置项过多导致用户在缺乏核心原理理解的情况下被迫使用，而这种理解正是定制化的基础。

         回复

   2. > 你如何看待Doom Emacs或Spacemacs这类强意见化发行版？

      若使用原生Emacs而不做任何定制，你将获得极其基础的文本编辑器体验。这本身无可厚非，但需明确：若想获得接近VSCode等IDE的即用体验，必须自行添加定制组件(如启用eglot实现LSP功能、添加company-mode实现代码补全等)。

      有些人看到原生Emacs后，可能误以为它只是个普通文本编辑器，从而选择回归花哨的IDE。对于这类用户，Doom/Space这类发行版能有效避免初始的冲击感或失望感。

      doom/space的另一妙用在于探索可能性。先发掘你喜欢的特性，再研究如何在基础配置中实现它们——本质上是在为自己的Emacs配置进行“橱窗购物”。

      但最终我建议你达到我现在的状态：从纯净版Emacs起步，逐步添加所需功能。这样既能拥有所需功能，又避免了多余负担。不会被意外特性打乱节奏，因依赖包极少而减少故障风险，加载速度迅捷因无需载入大量闲置组件，更重要的是——我完全理解配置中每个启用的功能。

      您或许还想看看emacs-solo。这是完全基于内置包而非第三方包构建的配置方案。我仍会使用某些第三方包(如company-mode)，但看到仅凭内置功能就能实现如此多的功能确实令人欣喜(例如：您可能无需安装projectile，直接使用内置的project.el即可；同样无需lsp-mode，内置的eglot完全能胜任)： https://github.com/LionyxML/emacs-solo

      回复

   3. 切勿盲从。个人配置极具私密性，预设配置会强行将他人偏好强加于你，甚至包括配置文件的组织方式。

      但归根结底是权衡取舍的问题，关键在于什么适合你。你未必需要超越发行版提供的配置，但若你愿意或需要尝试，这恰恰是探索的良机。

      回复

   4. 适合你的就是好的。若你为特定目标使用编辑器，借助Doom的防护栏也未尝不可。我以基础配置为根基，但早在发行版出现前就已使用emacs。若想深入钻研emacs，不妨从基础配置起步。

      回复

   5. 它们自有其价值。我最初使用Doom配置，它确实帮助我高效度过了基础阶段——若直接使用基础配置，那时的我可能会感到不知所措。但和你一样，当我想突破其默认配置时很快感到沮丧。

      后来我转用原生配置，并借助ChatGPT逐步解析整合我喜欢的Doom功能，最终构建出一个我真正理解且可自由调整的基础环境。

      回复

   6. 我从Emacs转到Vim，再到Vscode，最后带着Doom回到Emacs，但其实我几乎都在用这三款工具。Vscode有Copilot，Emacs有org模式，Vim则擅长轻量编辑。

      Vim如同魔法般让我无需改变肌肉记忆就能驾驭所有工具，而Doom恰好完美契合我的需求。

      我认为任何试图按本文框架掌握Emacs的人，最终都会根据自身需求调整配置，任何预设的配置方案都可能引发不满。

      问题的答案取决于你是否需要在Doom集成之外添加社区扩展，或是希望亲自定制Emacs。后者只要映射好leader键就能完美运行，所有Elisp功能基本保持原样；前者则可能困难得多。

      回复

   7. 个人认为它们是入门的好方式，无需前期投入太多时间。不过这已是十年前的事了，如今搭建可用配置要简单得多——借助LSP和内置的tree-sitter模式，你不再需要为每种语言安装三个包外加大量配置粘合剂。

      回复

   8. 我个人选择Doom是因为它内置了大量优化方案。虽然有人不喜欢hlissner将Nix的声明式包管理理念融入其中，但作为Nix用户我认为这很合理。我还是个邪恶(异端)用户——从一开始就把Doom配置成从vim/neovim过渡到emacs的桥梁，它确实做得非常出色。

      建议双管齐下。你可以同时运行多个Emacs配置：保留基础配置逐步完善，同时通过Doom/spacemacs探索更多可能性。

      回复

   9. 我在Windows主机上的Debian虚拟机里试用过Doom Emacs，毕竟这是安装新Emacs工具的好机会(边玩游戏边编程)。但Doom Emacs不够稳定。它时常崩溃，有次甚至丢失了我编写的整段函数——因为它似乎不执行Emacs常规的备份文件机制。虽然键绑定很出色，但稳定性需求让我不得不放弃它。如今我已回归标准Emacs，目前使用evil模式。

      回复

   10. 我同样深有同感，好奇是否有经验丰富的用户能提供参考资源。根据我的实践经验，在尝试Doom Emacs并遭遇跨机配置问题后，我发现只需极简配置文件就能满足Orgmode/日程管理需求。可见只要明确目标并解决具体问题，就能找到突破之道。或许将复杂度控制在可控范围内才是健康的使用方式。

       回复

   11. >>我已在Emacs上坚持每日日记和任务管理一段时间

       相信我，转用Google文档吧。

       相较于Org-mode未来可能达到的任何形态，它简直是更广阔更便捷的宇宙。不仅支持在线备份，图片还能直接嵌入文档，更有多项开箱即用的功能。你无需耗费数年学习成本，从第一分钟就能高效运作。

       回复

7. 关于EXWM及：

   Emacs是单线程的，因此系统中任何组件卡死都会导致整个系统卡死。

   在开发工作中我并未遇到此问题。编码时通常只运行极少量的X应用——基本就是网页浏览器，偶尔可能用PDF预览器或文档浏览器。我从未遇到过单线程行为阻塞窗口管理的情况。(顺带一提，虽然为真正需要并发处理的任务(如EXWM作为窗口管理器的职责)添加多线程会很理想，但我 极度 偏爱Emacs同步处理输入的方式，远胜于JetBrains那种按下组合键后，还得等待某个异步UI行为完成的恐怖体验——且结果会因后续按键发生在UI行为触发之前或之后而截然不同。)

   对于其他更侧重GUI的操作，我直接启动独立的Wayland会话。

   回复

   1. 我深陷EXWM的编程环境无法自拔。EXWM+Helm+Projectile的组合堪称完美。虽然主要用v-term操作命令行，但始终对eshell怀有兴趣，只是始终未能抽空学习。偶尔遭遇线程锁死时确实令人沮丧。有时能切换会话终止进程避免重启，但并非总能成功。即便如此我仍不愿离开EXWM。或许退休后我会以协助实现emacs+EXWM多线程化作为职业生涯的终点。这想必是艰巨的工程，但完成时定会充满成就感。

      回复

      1. 若想尝试eshell，建议结合EAT(eat-eshell-mode)使用。

         > 或许退休后，我将以协助实现emacs+EXWM多线程化作为职业生涯的终点。这想必是艰巨的工程，但必定充满成就感。

         遗憾的是，这无法通过线程解决。问题在于：

         1. Emacs 通过 call-process 启动进程时，会阻塞所有操作(包括其他线程)。
         2. 当该进程尝试映射窗口时，EXWM 因 Emacs 被阻塞而无法响应请求。
         3. 由于进程无法创建窗口，call-process 调用永远无法返回。

         要解决此类阻塞问题需修改Emacs，但此方案曾被尝试过：https://mail.gnu.org/archive/html/emacs-devel/2023-06/msg007…

         目前看来，正确方案是编写一个最简化的进程外窗口管理器(例如Wayland合成器)。

         1. 正常运行时，它将像EXWM那样向Emacs请求窗口管理指令等操作。2. 在特殊场景(待定)下，它将自主运行，以标准浮动窗口管理器模式工作，直至Emacs恢复响应。

         回复

   2. 我确实对EXWM颇感兴趣，但这可能需要提升我的Emacs技能并优化配置以延迟处理重负载任务等。若有任何实现建议，我洗耳恭听！越是使用Emacs，就越想让整台电脑都变成Emacs。

      回复

      1. 你可能无需额外优化：Emacs近期已实现重大性能提升(原生Emacs Lisp编译、tree-sitter模式、长行处理优化等)，性能问题已不常见。

         但务必尽量避免使用call-process(启动阻塞进程)。另外，我使用TRAMP的体验相当糟糕，这源于https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12145的修复方案(直白地说：TRAMP在等待网络连接时会完全阻塞整个Emacs)。

         回复

   3. 我不认为会想用通用Emacs当窗口管理器，最理性的方案应该是运行两个Emacs实例。

      回复

      1. 我深爱Emacs，但实在不解为何有人偏要用它当窗口管理器。Emacs能胜任多种任务，但绝非高性能之选——而窗口管理器恰恰是追求高效的领域。

         回复

8. > 这正是世界级运动员、音乐家、艺术家、作家乃至程序员将脑海构想转化为现实的方式。

   > 这如同砍树前对斧头的终极打磨[1]

   但若打磨斧头的过程包含听音乐、查邮件、刷资讯流等行为，或许我们该退后一步自问：是否正用无谓之事侵占了工作思维空间？

   [1] “若要我砍倒一棵树，给我六小时，我会花前四小时磨利斧头。”——据传出自亚伯拉罕·林肯。

   回复

   1. 我们用计算机完成各种任务，过程并非总是线性的。关键在于减少操作摩擦。这种摩擦可能以多种形式出现：比如光是播放音乐就要和图形界面搏斗，收邮件又要面对另一个界面，订阅源又得另开新界面。Emacs工具则相当稳定，所有操作都能通过统一界面完成。

      回复

   2. 优秀的木匠会花时间保养和添置工具。他们可能仍用着好手机，工作时戴着耳机听音乐。厨师必须保持厨房整洁有序，备齐常用工具和冷门器具。她要给锅具开锅，给刀具磨刃。

      回复

      1. 我最初的职业是厨师，每周最后一场服务结束后总会静坐磨刀。这段时光既能反思过往周期，又能为新周期做好心理准备。编程领域实在找不到类似仪式感——这话出自一个耗费数百小时为Emacs修修补补的人之口。

         回复

9. 总听人夸赞emacs多么强大，有没有适合编程新手入门的资源？我熟悉编程但不熟悉vim或emacs这类编辑器，只想踏出第一步。

   回复

   1. 最直接的入门方式是下载`emacs`，打开后直接运行内置的“Emacs教程”(点击首页显示的链接即可)。该教程会引导新手掌握编辑器核心概念、操作导航技巧、常用功能操作，并熟悉其专属术语体系。

      初期建议暂不安装任何扩展包，先充分利用内置功能(现已默认包含`magit`和`org-mode`)，花时间探索“出厂默认配置”的全部潜力。

      此外可观看`System Crafters, Howard Abrams, Emacs Rocks`等频道的视频，参考他人使用技巧获取灵感。

      虽然需要时间适应各项功能，或安装包并定制至其他编辑器的默认配置，但这份投入绝对值得。

      回复

      1. 务必充分利用“C-h k”(描述键)、“C-h f”(描述函数)和“C-h v”(描述变量)功能。Emacs的自文档特性能显著降低理解操作逻辑和选项机制的难度。

         > `magit`和`org-mode`现已默认安装)

         Org是默认安装的，但magit不是。

         回复

   2. 《精通Emacs》是本好书。但入门无需依赖它，建议先查阅https://www.masteringemacs.org/reading-guide

      回复

   3. 若尝试 Emacs 时感到无从下手，请谨记：无需立即彻底切换。可继续使用原有编辑器，仅在闲暇时使用 Emacs。或采取 50-50 的混合模式。任何能避免初期效率下降成为显著弊端的方法皆可。待你掌握要领后，仍可尝试将其应用于工作场景，在流程中发现细微问题，再利用闲暇时间或业余项目寻求解决方案。

      就我个人而言，所有纯文本文件相关工作都使用Emacs处理。此前工作中，我因在业余时间自主解决过某些问题而获益匪浅。

      回复

      1. 目前终端编辑纯文本/Markdown多用nano，IDE需求则主要依靠VSCode或Visual Studio。但总听闻Emacs能构建高效统一的系统，正考虑尝试哈哈

         回复

   4. 强烈推荐Mickey P.的《Emacs精通指南》。需要耐心学习，建议至少花一周时间循序渐进地研读，并保持Emacs的原生/标准安装状态。

      我最初花了约两周才掌握高效使用技巧(2018年时)，如今每天用Emacs处理各类任务(主要是编程和笔记)。

      回复

   5. 我衷心推荐米奇·彼得森的《Emacs精通指南》(https://www.masteringemacs.org/about)

      回复

   6. https://www2.lib.uchicago.edu/keith/emacs/

      回复

   7. 《Emacs精通指南》确实不错。但这两个程序本身都内置教程且文档详尽，YouTube上也有大量功能演示视频。

      回复

   8. 维基页面提供了大量资源链接：https://www.emacswiki.org/emacs/SiteMap

      回复

10. 题外话：身为Emacs老用户，新雇主却要求全员使用PhpStorm。别误会，这确实是款优秀的IDE，但我依然怀念Emacs。

    回复

11. 我正在探索类似的系统方案，目前在NixOS和Debian/OpenBSD这类整体式系统间犹豫不决。

    尽管我非常欣赏声明式构建的理念，但对于个人环境而言，我实在难以说服自己投入精力学习和维护Nix。尝试过几次后，遇到的多是陷阱。

    我追求的不过是打造一个简洁优雅的系统。

    回复

    1. 投入数小时学习后借助LLM工具，我获益匪浅。由于对Nix语言语法生疏，主要时间都用于掌握整体框架，总耗时不足8小时。浏览GitHub上的他人代码也极具参考价值。

       回复

12. 有没有展示高效Emacs配置及日常任务应用的优质视频？

    回复

    1. 虽非你所求，但我推荐emacs rocks视频集锦：https://emacsrocks.com/

       回复

       1. 这些视频简短精炼，不过要注意最新一期已是8年前的了 😉

          (虽然https://www.youtube.com/@emacsrocks有同作者更新的内容，似乎是关于Clojure和Emacs的游戏开发)

          回复

    2. https://systemcrafters.net/emacs-from-scratch/

       这真是我的顿悟时刻！亲眼看到别人安装使用包时，我恍然大悟：哦哦哦，这不仅酷炫，而且确实超级实用。要知道我从1998年就开始用Emacs了！发现多数包文档只详述操作步骤，却很少解释使用价值。

       回复

13. Emacs确实很棒——前提是你不介意亲手编写所有代码。毕竟与其开发文本编辑器的插件，你完全可以直接编写满足需求的应用程序。不过它确实很酷，至少能让你抓住那份难以言喻的兴奋感。

    回复

    1. 若你正在编写的应用程序基于文本，Emacs无疑是绝佳的开发环境。

       回复

14. 回复作者对exwm的评论

    我认为exwm存在根本缺陷， 尤其 在运行emacs或在其内部操作emacs时。最终你会陷入键绑定之类的争斗。

    更优方案是让窗口管理器运行在独立进程中，通过IPC与emacs的elisp进程通信。

    回复

15. 既然有Emacs，那他为何还要用Nix？

    回复

16. 关于在Emacs“外部”启用org捕获功能的提议非常有趣。对我而言，构建一套能以极低成本记录笔记、待办事项等内容的系统至关重要。无论何时，无需离开键盘，我都能记录笔记：可直接关联当前工作内容，若知晓归属位置可任意归档，或直接投入通用收件箱(系统另一部分功能是后续处理收件箱内容)。不过此前我必须始终“处于”Emacs环境中——虽然它占据我大部分时间，但并非全部。

    回复

17. 我喜欢eMacs，但感觉整个工作流设计有误。缓冲区本质是窗口管理器内部的堆叠式平铺窗口管理器。浏览器是标签式窗口管理器，许多其他应用同样具备窗口管理器特性。我希望任何应用程序的子缓冲区都能实质上成为独立窗口，让窗口管理器处理其余事务。或许这只是我需要调整的工作流程，但全局解决方案会更理想。不过现在想来已为时过晚。

    回复

    1. 你可以配置Emacs让每个缓冲区在新框架(即“窗口”)中打开，再通过窗口管理器进行管理

       回复

       1. 完全同意。我也认为同时运行两个理念和快捷键不同的窗口管理器(一个在WM中，一个在Emacs里)毫无意义。但更重要的是——这正是Emacs的伟大之处——若不喜欢默认行为，只需修改即可。

          回复

    2. EXWM + Qutebrowser 就能实现这种效果。Qutebrowser 的每个标签页都会转化为 Emacs 缓冲区。

       回复

       1. 我用 sway 将 Firefox 集成到窗口管理器时，也用过 no-tabs 扩展。通过修改 userchrome 完全隐藏标签栏效果极佳，应该也能在 exwm 上实现。

          回复

    3. 处理超长文件时Emacs不会变慢吗？比如8000行那种

       回复

       1. 我的主Org文件有2.1万行，完全没问题。笔记本是2017年左右的机型。

          我偶尔会处理30万行文件(别问为什么)，虽然基本流畅，但偶尔尝试某些优化不足的操作时会失败(比如别用magit-blame分析这种文件)。不过搜索、滚动、编辑和语法高亮都很快。

          遇到超过100M的文件时，我偶尔会切换到fundamental-mode打开，这样就能关闭语法高亮功能。

          对于真正的大文件(千兆字节级)，可使用`vlf`(超大文件)包。该包不会将整个文件一次性加载到内存中，但仍支持搜索、滚动浏览，甚至能执行M-x occur命令(类似于grep，但集成度更高且支持编辑)。

          请注意此功能基于Emacs 31版本(过去三版中已实现重大性能提升，新垃圾回收机制将带来更多优化)

          早期版本曾存在超长行处理问题，后续版本通过双重方案缓解：一方面提升内部处理速度，另一方面新增内置包so-long——该包能识别默认10KB的超长行，此时Emacs会自动关闭语法高亮等功能以保持响应速度。

          回复

          1. 当我处理一个由大量重复代码块组成的大型前端模板时，最终转向了vim。这些代码块仅在条件判断处存在细微差异。频繁的搜索替换操作下，Emacs在处理第10个条件块时开始严重卡顿。

             回复

       2. 如今情况不同了。原生编译让emacs运行更快，其他方面也有诸多改进。在基础模式下，emacs能处理超大文件。直接打开文件时速度更快——我有个10.4万行的org-mode文件，响应依然流畅。虽然还原操作耗时稍长，但缓冲区按模式格式化时界面不会卡死。

          我使用中端笔记本CPU(6核12线程)，Emacs运行流畅。相比2019年的龟速，如今简直快如闪电。

          回复

          1. 我上钩了，你那org文件到底是什么鬼？

             回复

             1. 那是三个月需要重新归档的文本。

                回复

       3. 不，但这其实无关紧要，我的重点在于所有应用程序的缓冲区都应采用窗口化设计。

          对我而言，Emacs在启用语法高亮且导航至超长行时会变慢，而文本模式既无高亮也无延迟。多数Emacs卡顿源于劣质插件，若能反馈问题或许能促使开发者修复。

          回复

18. 这话可能听着奇怪，但我真心觉得我们只需要…一个编辑器。

    这并非“要偏袒vim而非emacs”。我认为vim与emacs之争纯属无谓的战争。

    我的意思是…本质上大多数编辑器功能几乎完全相同。它们读取文件缓冲区并协助用户修改内容。可执行的操作本就有限，为何人们总要重复实现基础功能？为何不能一次性解决问题，让所有人使用统一方案？

    我们确实需要这样的方案；届时用户可自主选择编辑器类型。多年前我在Windows系统上曾以Crimson编辑器为主力工具。后来我尝试过许多其他编辑器，最钟爱的是基于gtk2的老牌蓝鱼编辑器。并非说它完美无缺，但比起记忆vim的各种快捷键，它更符合我这颗笨脑袋的运作方式。不过它需要xorg+gtk2环境，一旦缺失就无法编辑文件——这实在糟糕。这(至今仍是)我转用nano等编辑器的原因之一。但nano又依赖ncurses库，而我对ncurses深恶痛绝(尽管nano本身很出色，推荐用于快速临时编辑；处理大型文件时稍显不足，但修改配置文件的某个数值时，nano确实非常高效)。

    即便如此，我实际使用的功能也仅占Bluefish的20%左右(新版Bluefish远不如旧版优秀，部分原因在于如今的GTK实在糟糕)。我渴望能像挑选樱桃般定制编辑器，自主定义所需功能，而非事事亲力亲为。为何不能实现这种转型？为何必须几乎从零开始重构一切？这对我而言毫无道理。

    我们身处人工智能自动生成代码的时代(它们大量借鉴了他人代码)。为何不能让AI自动生成最完美、最理想的编辑器/IDE？

    回复

    1. 步骤1：创建功能最完善的完美编辑器。我们做到了。每个人都能根据自身工作流程进行完美定制。

       步骤二：用户抱怨功能臃肿，99%的可选功能毫无用武之地，代码库维护堪称噩梦。

       步骤三：于是诞生了上千款新编辑器。

       回复

    2. Bluefish已于2025年10月发布新版本，其开发页面提及gtk-3支持。你确定跟进过最新动态吗？若满意当前版本，请继续使用。

       回复

19. 除Lean或Agda语言外，为何要用emacs替代Helix编辑器？

    回复