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

2020-10-19 15:15:08

关于,我在换工作。我即将离开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上的时间越来越多,因为它做了越来越多我想要的事情,所有这些都是在文本文件和目录的基础上构建的。