查文档看到一个显示文件git信息的命令,切过去摁快捷键,发现learnEmacs这个目录已经创建了快一周。

从下载,看教程,修饰一番换成喜欢的配置,到创建项目开始每天一边写Org一边探索,终于算是开始适应这个“编辑器”了。

为啥要开始学Emacs?老实讲,以前我是很看不上这些远古时代留下的东西,一方面是初学编程时被老工具坑过,一方面也是被看起来非常陡峭的学习曲线给吓跑了。工具是用来提高效率的,要是折腾上半天还玩不转,那我用它干啥。再说了,现在的IDE功能如此强大,从自动补全到debug追踪,都有着很完善且开箱即用的支持,何必要从头开始配置一个编辑器呢?

事情的起源往往不止一个因素。也许是对纯键盘操作模式的好奇,对据说最高效率的编辑方法的疑惑(因为看起来要背很多键位,Vim也是),或者是被经典的“最好用编辑器”之争所吸引,在看了几篇深度分享的文章之后,我觉得有必要尝试一下。另外自从在VSCode上开写Flutter,把跟其他各种脚本的工具统一了之后,我开始喜欢上这种轻量级的开发模式。从代码到编译产物的整个过程更加清晰,要么使用插件辅助,要么在终端上执行命令。编辑器就是写代码,后续的工作有其它的工具来负责,清爽了许多。

初学者往往急于看到效果,所以容易一头扎进框架的大山里。某种程度上说,IDE也算是一种框架,隐去了部分细节,给使用者十分方便的体验。并不是说这么做不好,只是随着学习和实践的深入,我们更需要对原理和本质的理解来解决问题。

这么说有点模糊,其实我觉得,开始学习Emacs和自己最近做出的其它选择,比如开始读一些解读框架本身的书,开始研究以前觉得没用的东西,这些变化都是某个意识觉醒的反应。不再执着于能做出什么东西,而是去真正的了解它,搞懂它。有时候看似很大的进步,实际上只是学会了怎么去调用API,有结果,不一定就代表着自身技术的提高。

为啥要学Emacs?本质上来说,Emacs是一个套着编辑器外科的Lisp执行环境,因此又有着编辑器中的“操作系统”之说。在我的浅薄认知下,这个语言虽然不面向对象,但是跟解决问题的直接思维非常相近。除了能高效的调用各种脚本,实现各种功能外,它自身对于文本编辑的一整套逻辑(看完自带的tutorial就能明白),也非常直观且具有语义性。这也就意味着,基础命令基本就是相应的缩写,想到就能摁出来,熟悉之后效率非常高。

相比于点点鼠标,能省多少时间呢?其实也省不了多少,但是不会打断你的编写状态。在高速的编写调整中,与输入一致的操控方法会带来非常舒爽的体验。我觉得vim也差不多,选择Emacs纯粹是因为可玩性更强。就比如说Org,这是一个非常适合写文档和做计划管理的mode,在纯文本的基础上,实现了一些优秀功能。就比如可以自由的指定标题层级,用快捷键来折叠展开,切换待办列表是否完成,插入格式化高亮代码……类似于MarkDown,但功能要更加强大,除了对效果的即时计算和渲染外,你甚至可以执行插入的代码片段,并把结果输出在文档中。当你完成某个待办项的时候,完成状态和比例也会自动更新。这就极好的展示了Emacs的强大之处,虽然本体上只是一个编辑器,但可以通过各种插件来实现相当多的功能。

嗯……是不是觉得跟VS Code很像。确实,两者有跟多共通的地方,我相信后者一定博采众长,学到了这一优点。我已经在VS Code上安装了Emacs按键绑定的插件,包括在oh-my-zsh中做了相关的设置,现在无论是在编辑器还是终端,都可以无脑的进行高效输入。

除此之外,我觉得通过学习Emacs的各种用法,也是对于一些实现原理的探索。如何去配置插件,查看简易帮助,阅读文档说明……在这个过程中就能了解到很多原理性的知识,看到高手是如何设计并实现这些功能的。学习Linux,研究算法题,读框架文档等等,这些都是类似的事情。虽然没有做出一个多姿多彩的网页或者App,但是对于个人软件工程技术素养的提高是很有益的。

光学习不实践,和只实践不学习都是错的。也许世界上并没有所谓的捷径,打不好基础就建不了高楼,刻意忽略或者被动跳过去的知识,都会在以后的某个陷阱里等着你。所以,还是抱着朴实平淡的初心,学习时就一心一意的搞懂本质,实践时就用最好的方法完成任务。当面对各种情形下的开发需求时,能够游刃有余的挑选出最合适的工具,我想这也是实力的真正体现了。