我选择Emacs作为我的新文本编辑器

关于，我在换工作。我即将离开IDE*的围墙花园，前往部署在AS/400*上的专有语言。我们用IBM RPG*和Cool Plex编写，它们看起来有很多元代码，我现在知道是RDFTriples。

在我的新工作中，我使用开源技术编写面向Web的应用程序，并部署到Linux上。我需要找一位编辑来帮我完成这项任务。

我花了一些时间探索我的选择。在那次探索中，我从卡尔·迈耶那里了解到了Emacs。卡尔是我高中时的朋友，他为世界做出了很大贡献。

当时我有三个年幼的孩子，我刚刚换了工作，换了编程语言，还不能理解Emacs。我希望我的编辑器能像其他GUI*应用程序一样工作。

我没有花时间浏览Emacs教程，而把Emacs抛在了后面。

在我新工作的几个月里，我再次转换了语言和范式。我的公司跳上一辆面包车，开到芝加哥去了解Django*和Ruby on Rails*。不到一周，我们的组织就采用了Ruby on rails。

当时，我采用了TextMate*作为我的编辑。它有一个漂亮的用户界面，不需要花多少功夫就能学会。我没有意识到shell环境的用处有多大；在以后的岁月里，我会学到更多。在我的职业生涯中，我经常依赖于文件、系统和流程的GUI视图。因此，我没有一个心理模型，可以进一步推动我走向一个集成的文本编辑器。在我的傲慢中，我没有一步步看完Emacs教程。

当时，TextMate是封闭源代码的。我用过它，也很喜欢它，但它开始滞后了。搜索项目功能开始行为不端，网格化项目陷入停顿。我找到了崇高的文字*然后换了。当时，Sublime的定位是TextMate的替代品。

然后，随着我越来越多地参与开源项目，我开始想要一个开源文本编辑器。我是在2015年了解到Atom的。它是开源的，行为非常像Sublime，所以我改用了它。在此期间，我尝试了VIM*。然而，编辑的模态性质给人一种陌生的感觉。有时，我会尝试一个教程，但它从来没有坚持下来。我还考虑过修改TextMate，因为它的所有者后来将其作为开放源码发布。

转发到。我已经开始注意到Atom中越来越多的bug和漏洞。不是害怕更换编辑的人，我开始寻找。

我也给了VS Code*一个旋转，发现它令人不安。首先，它让人感到压抑和反感。配置生态系统感觉很笨重。这些插件给人的感觉就像是一个App Store。每件事都让人感觉VS代码试图混淆它的底层系统。

几年前，我开始渴望遵循Tim Pope关于提交消息的指导来编写我的大部分提交消息。直到今天，我还在尝试编写有意义的提交消息，因为我知道这些提交消息通常与代码非常接近。有些人可能会将信息放在Github或GitLab上Pull请求消息中，但该信息不会保持在代码附近。然而，这些信息现在与Github的细节密不可分。当我想要拼写我的代码时，我不想去Github查看发生了什么。我希望我的git注解和git日志能够承载尽可能多的意义。

众所周知，最后一根稻草是要求提交消息的git*提示符。提示是一个很小的输入框；它不鼓励有意义的提交消息。相反，它鼓励简洁的承诺。仅这一功能就告诉我，使用它的人将被鼓励编写不好的提交消息。我不想成为那个有我的文本编辑器的人。

我又试了一次vim*但感觉不对劲。当我向服务器支付费用时，我使用Vim。我最近不经常这样做，因为我可能会使用Emacs的流浪汉模式。

我尝试了Emacs，并按照自己的方式完成了教程。正是对该教程的坚定承诺，以及诚实地说，该教程的写作促使我进一步深入研究。我花了一些时间摆弄Doom或Spacemacs，但最终还是选择了裸机Emacs。

事实证明，这一点至关重要。作为一个使用文本编辑器超过15年的人，我知道我使用过的功能。我选择在Emacs中做的是完成教程并开始编码。

如果我发现自己想要一个功能，我就会注意到它。然后，我找到了实现该功能的一个或多个包。我花了相当多的时间通读梅尔帕，寻找一个包裹。发生的事情是，我已经建立了自己的编辑器，满足了我的需求。

现在，大约5个月过去了，我完全喜欢这段经历。Emacs开发人员社区似乎对编写文档有更高的承诺。许多Emacs开发人员使用识字编程范例编写配置文件。换句话说，他们首先写下他们对软件的意图，然后再编写软件。

组织模式是我以前的文本编辑器所缺少的部分。Carstin Dominik花时间构建了组织软件开发、研究和编写的非编码任务的功能。如果我重新开始我的博客，我会利用org-mode和ox-Hugo来写博客。

组织模式将有意义的工具层叠在纯文本文件之上；语法接近Markdown，但差别很大。结构的简单性使世界与众不同。使用纯文本，我可以运行低级Unix命令(例如grep、sed等)。而且还具有对数据的更高级别的编程访问。

在使用magit之前，我几乎总是使用git*的命令行工具。我之前的工作流程是使用终端声明我的GIT提交，然后使用文本编辑器编写提交消息。作为提交消息编辑器打开Atom很慢，这是我离开Atom的另一个原因。我不想等待数秒才开始编写提交消息。

除了读取git日志之外，我现在使用Magit执行几乎所有的git任务。这包括一个令人惊叹的交互式git rebase环境。

当卡尔把我介绍给Emacs的时候，他给我看了一整段话。这一功能让我印象深刻。这不是什么花哨的事，但它表明Emacs将列宽视为一等公民。

遵循这种结构有助于确保您的GIT日志旅行不会过于混乱。如果您要与命令行交互，这也会有所帮助。换句话说，自动换行很好，但它不是通用的，也不是在所有上下文中都有效。

我已经使用此命令快速包装文档，以免它流出屏幕。对于编码缓冲区，我禁用了自动换行。我也渴望120字符线宽的代码和80字符线宽的评论。为什么会有这样的差异呢？评论应该读起来更像散文，长长的台词会使段落更难阅读。

这不是什么命令，但自从我了解Emacs以来，我就一直对此持乐观态度。

直到我偶然发现它，我才知道我想要Swiper。我现在一直在使用它；它甚至取代了我在Emacs中的默认查找行为。

是干什么的呢？我输入Control+S，用Emacs的话来说就是C-s，然后开始输入一个单词。在当前缓冲区底部的小型缓冲区中，我看到包含该单词的行。这有点像一个有上下文的发现。重要的是，这不会移动主缓冲区中的光标。

所以我很快就引用了一些东西，然后继续打字。或者，我可以在迷你缓冲区中导航并跳转到主缓冲区中的该位置。相当圆滑。

Wgrep-ag套餐有点让我大吃一惊。它允许您使用ag*和wgrep编辑搜索结果。

在Emacs中，我使用ag搜索项目。Emacs在迷你缓冲区中呈现搜索结果。在本例中，小缓冲区是Emacs底部的一小部分行，显示结果的子集。

在小缓冲区处于活动状态(例如，我一直在那里键入结果)的情况下，我调用了Ivy-Octure。该函数在只读缓冲区中打开所有搜索结果。当我写这个例子的时候，我想“我想知道我是否可以使用常春藤-发生在Swiper结果中？是的我可以。所以我在解释的时候学到了一些东西。

使用这个新缓冲区，我调用函数wgrep-change-to-wgrep-mode。这会将常春藤发生缓冲区切换到编辑模式。我开始编辑搜索结果，就好像它是它自己的文件一样。

然后保存编辑，wgrep-ag将所有这些更改写回找到的结果。

从另一种角度来看，wgrep-ag加载一个半结构化缓冲区。每行有三个字段：文件名、行号和行文本。我可以使用wgrep-ag将这些更改写回原始文件。

TextMate首先向我介绍了这个强大的概念。从那时起，这个功能就成了我的编辑器的必备功能。

Iedit-默认情况下，如果我键入Control+；(例如C-；)，iedit包将突出显示该单词的每个匹配项。我现在可以输入，然后iedit会更新所有匹配项。

多光标-这个包提供了更精细的粒度控制，并允许我在10个连续行上设置光标并开始键入。

直到我安装了Expand-Region，我才知道我错过了什么。现在使用Control+=(例如C-=)，我的光标扩展到最小的逻辑区域(例如突出显示一个单词)，再次键入它会扩展该区域(例如突出显示句子)，依此类推。而Control+Shift+=(例如C-+)则收缩该区域。

我已经用它为我在行业竞选中的新远景写了竞选笔记。双向链接和快速笔记捕获工具成就了信息管理的梦想。

在Away中，它创建了一个我可以使用Emacs编辑和导航的Wiki。

今年，Emacs吸引了我。随着我进入软件开发的第三十年，我开始欣赏教程、文档和拥有自己的工具。Emacs做到了这一切。它甚至和我一样老。

我发现我花在Emacs上的时间越来越多，因为它做了越来越多我想要的事情，所有这些都是在文本文件和目录的基础上构建的。