Table of Contents
customizable emacs
Emacs是世界上可配置性最强的编辑器。
我最开始试图在上面这句话里，加上“几乎”或者“之一”来让这句话变得更准确。后来发现不管加上哪个词，这句话都会变成一句错误。
是的，世界上没有任何编辑器，在可配置性上能超越它。
争论这句话的对错已经没有意义，我现在想知道，为什么它可以在可配置上能够达到极致。或者，为什么其他编辑器达不到这种可配置程度？
这篇文章将尝试从一个矿工的视角，把最宝贵的这部分内容挖掘出来。
源码设计
linux kernel内核用到了很小一部分的汇编源码，据说新版本已经完全用c来实现了。
如果不是迫不得已，我相信linux kernel还是倾向避免接触到汇编的。
Emacs也遇到了这样的问题，由于效率上的考虑，它不得不将一部分底层代码使用c语言来构建。从本质上来说，Emacs是一个用c语言实现的lisp解释器。
剩下80%的部分，Emacs是使用在c上构建的lisp语言来编写的。
elisp更接近脚本语言，它有点类似python（sorry，其实是python有点类似lisp），也可以编译为字节码。它的一切都是可读的，任务一个lisp语言的函数，都可以快速找到它对应的lisp源码。
这就为用户提供了接近真相的机会，如果你愿意，甚至可以根据自己的需要直接修改核心的Emacs（好吧，你最好不要这么做，这意味着你已经脱离了Emacs和其他Emacer的支持）。
软件设计
软件包括两部分，可执行的二进制或脚本文件和它所包含的文档。
Emacs的核心软件都是结构化的，这使得我们可以很容易地找到相关功能所在的源码。比如，如果你想研究Emacs中的window操作实现，可以找到window操作对应的lisp文件window.el。
文档部分也是经过了精心设计的，从C-h对应的完整的文档分类可见一斑。这使得Emacs的用户很容易地可以查找到一整块完整的功能，读过Emacs手册的人应该都深有体会。
这里需要说明一点的是，Emacs的文档系统其实还包含了动态文档系统，比如查看当前mode或key bindings。所有的文档组成了一张严密的网络，使得我们在Emacs中可以快速地到达想要去的各个地方。
扩展语言
众所周知，Emacs使用了自己用c语言实现的一种lisp方言：elisp。
我认为，elisp被大家过分夸大了，甚至给人一种“Lisp不同寻常的语法决定了其开发者都是资深开发者”的印象。
甚至，我认为，恰恰是elisp的一些缺点，才导致Emacs的扩展性达到了无与伦比的高度。
lisp的括号可能是最被人诟病的设计，有一个lisp笑话被lisp黑客广为流传：“据说一个黑客偷到了美国用于导弹控制的LISP代码的最后一页，却发现这最后一页全是右括号”。
你可能写过python或者c语言这种面向对象或者面向过程的语言，但是遗憾的是，在lisp的世界里，这两种编程范式都很难被广泛实施，有很大原因源自lisp的括号设计。括号的大量出现，决定了你很难一口气写出100行的代码（希望你有勇气接受这个挑战）。所以它强制你精简每一个函数的实现，大量的微小函数组成了一张紧密的网，来提供强大灵活的整体功能。
这其实就是自底向上的编程思想了，没错，lisp强制我们使用自底向上的思想来思考问题。
说到自底向上编码，它的好处在哪里呢？它里面其实包含了分层的思想，即下层的功能可以很容易地被上层代码复用，而且当粒度足够小时，几乎所有想要的功能都一触即达。我们想要的只是一个编辑普通文本的编辑器，最后一不小心就变成了一个操作系统。
当我在借用第三方package实现某个功能时，一下子就找到了我所需要使用了所有函数，我需要做的只是使用自己的风格封闭它。
据说，当你打算设计一个极度复杂的系统时，lisp会让开发成本和维护成本随复杂度呈指数下降。Emacs就是一个例子。
“凡有的，还要给他，让他丰足有余。”
Emacs并非无所不能
最后的这个标题出人意外，前面夸赞了那么多，最后要承认它只不过是个使用习惯令人蹩脚或者过时的编辑器吗？
不是的！
我想知道网络上，Emacer们都在干些什么（问题来自知乎）：
- 你认为最好看的 Emacs 配色方案（color scheme）是哪款？
- emacs还能做什么？emacs比vim好在哪里？
- Vim 和 Emacs 分别适合哪些人群？
- 谁知道emacs lispy-mode的用法？
- 对于使用emacs包管理器ELPA，你有哪些推荐的包？
我之前是一个vim用户，想学习Emacs多次未果，主要是觉得Emacs的按键太反人类。但是这是一种先入为主的思想，现在看来，应该让Emacs来适应我们，而不是本末倒置，要知道，Emacs就强大在它的可配置性上。
不要在自己还没有尝试了解一个东西之前，试图通过直接询问的方式一劳永逸。可以临时解决问题，但是不要在自己还不清楚的事情上浪费太多时间，最后原理没了解，只是在东拼西凑试图猜中答案。
不要做一个完美主义者。我之前也喜欢折腾，从字段，到配色，最后发现，这其实跟不动脑思考只知道蛮干是一样的。要精进不要盲进，少即是多，容忍不知道。
另外，不要试图寻找自己不需要的答案，也不要试图通过询问一次性获得答案。我们不需要知道别人使用哪些package，自己用的顺手才最重要。第一手资料在官方手册或者包列表服务器，我们要找的答案，绝不会简单地摆放在google里。