为什么需要选择 Org-mode 和 Emacs 这两个少见的组合来写文档，甚至强调是编程文档呢。简单来说 Org-mode 即足够的简单也足够的复杂，说是简单是因为 Org-mode 使用的是类似 Markdown 的标记语言，不需要担心排版问题；说是复杂则是因为 Org-mode 不仅可以直接内嵌 LaTeX 的语句，同时也可以直接输出 LaTeX 格式，对后期排版提供了很大的自由度。同时 Emacs 和 Org-mode 的组合提供了许多实用的功能，接下来我们就一点一点来介绍。

下面的快捷键都需要在 Emacs 的环境中使用，快捷键中的括号表示 Spacemacs 的快捷键。不用 Emacs 玩什么 Org-mode。

首先我们需要插入代码块。直接输入 <s 然后按一下 <tab> 键就可以直接输入 #+BEGIN_SRC 和 #+END_SRC，在两个标记之间的区域就是我们的代码块了。类似 markdown 我们也可以指定代码块的语言：

如果想要编辑代码块中的代码，可以直接使用 C-c ' (org-edit-special) 直接进入到编辑代码的功能，这是就可以直接使用该代码块中对应的编程语言的 major mode 了，例如对上述的代码块使用改功能的话，就会出现另外一个编辑窗口，在其中就可以使用 emacs-lips mode 的补全功能了。

当然，修改完之后使用相同的快捷键就可以退出对代码的编辑，返回到对 Org-mode 文档的编辑。

另外一个 Org-mode 强悍的功能就是可以直接执行代码块中代码，然后将他们的输出反馈到 Org-mode 文件中或者输出到另外一个文件中。例如我们将光标放到代码块上，然后使用 C-c C-c (org-ctrl-c-ctrl-c) 就可以得到输出的结果：

当然我们也可以设置在哪里以及用什么参数来调用这个函数。同时也支持在行内调用：

使用调用函数的方法可以有效避免你忘记了 IEEE 754 标准而产生错误的结果。

这里的 {{{result}}} 就表示一个 Org-mode 中的一个宏。它可以在导出 Org-mode 文件的时候，将一些定义的变量插入到其中。

对于比较复杂的代码，直接写在 Org-mode 文件中就比较繁琐了。所以我们可以使用更直接的方式，使用 #INCLUDES 直接引入代码的文件。

同样的，#INCLUDES 也有类似的输入方式：直接输入 <I 然后按一下 Tab 就是类似如下的效果：

第一个参数就是文件的路径，第二个参数 src 表示的是作为代码块引入，最后一个就是编程语言的设置。:lines 就是引入行数：

当然直接跳到代码编辑模式的功能还是有，快捷键也是相同的 C-c ' (org-edit-special)。

举个例子来说明将代码和 Org-mode 文件分开存放有什么好处。假设我们写了一个简单的 Rust 函数和它的单元测试：

pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

#[cfg(test)]
mod tests {
    use super::*;
    #[test]
    fn test_add() {
        assert_eq!(2, add(1, 1));
        assert_eq!(7, add(2, 5));
        assert_eq!(-4, add(-10, 6));
    }
}

我们只想出现第 1-3 行的代码，而隐藏琐碎的单元测试。但是需要注意的是 Org-mode 不会引入指定的行数区域的最后一行，所以我们应该写成：

#+INCLUDE: "./src/main.rs" :lines "1-4" src rust

这样在最后导出 Org-mode 文件的时候，就只会出现第 1-3 行的函数定义部分了。而同时，我们还可以继续用 cargo 来运行单元测试：

$ cargo test
#    Compiling add v0.1.0 (file:///tmp/add)
#     Finished dev [unoptimized + debuginfo] target(s) in 0.58s
#      Running target/debug/deps/add-1b966bd47a8d604b
#
# running 1 test
# test tests::test_add ... ok
#
# test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

此外，Org-mode 文件还可以引入其他 Org-mode 文件。而且在引入其他 Org-mode 文件时，功能更加强大，不仅可以设置行数，还可以设置引入哪个段落。例如，在其他 Org-mode 文件中引入我们现在的「自由方便地引用文件」这个段落，就可以写做：

#+INCLUDE: "write-a-programming-book-with-org-mode.org::*自由方便地引用文件"

最后，当然就是输出成 LaTeX 了，直接使用快捷键 C-c C-e l l (org-export-dispatch) 就能保存成 LaTeX 文件。

当然 LaTeX 就有很多可说的了，例如模板和宏包等。不过这样就扯远了，偏离本篇文章的主题了。

这里我就只补充一点，如果需要给输出的 PDF 文件加上代码高亮的话，我们需要安装 minted 宏包和 pygments 这个高亮的工具并且设置 Emacs 让 Org-mode 输出LaTeX 的时候把这个包带上：

(setq org-latex-listings 'minted)
(add-to-list 'org-latex-packages-alist '("" "minted"))

然后在使用 pdflatex 命令输出 PDF 时候，我们需要加点参数：

$ pdflatex -shell-escape -interaction nonstopmode <tex-file>

最后输出的结果就是这样啦：

在输出 PDF 的时候，minted 可能会出现类似这样的错误：Undefined control sequence.。这个时候就需要手动删除 _minted-test 这个文件夹，然后再运行即可。具体可以查看 minted 的 issue。

其实上述提到的很多功能在别的编辑器或是标记语言中都都能找到。就我所知的：JetBrains 的 IDE 已经可以在 Markdown 文档中使用相应语言的编辑模式编辑代码块；RMarkdown 和 Jupyter Notebook 等标记语言也提供了执行文档内代码的功能；而最后转换成 LaTeX 的功能更是有 pandoc 等多种实现了。但是能将上述这些功能集成在一起，形成一个完美的 workflow 的，几乎没有。

有时候我会觉得 Emacs 之于 Org-mode 的意义应该是大于 Org-mode 之于 Emacs。毕竟现在人们对 Emacs 的印象大多是：运行速度慢，快捷键反人类，)))))))) 和「要不是为了 Org-mode，我早就把 Emacs 卸载了！」:)

最大的因为就是需要兼容各种各样的运行环境和工具。

在 Angular 4 中加入了 @angular/platform-server 被并入 Angular 的核心 repo，说明 Angular 的 Sever-side rending 得到越来越多的重视，所以 Angular 的库不仅要兼容浏览器环境，还要能兼容 Nodejs 的服务器环境。

此外，不是所有的 Angular 项目都是基于 Angular CLI 的，Angular 的用户有可能使用各式各样的编译器和优化工具，例如 Webpack、Rollup、Uglify 和 Google Closure 等等，而且每种编译器和优化工具都有不同的需求。

所以仅仅只提供一种编译格式是不可能满足上述所有的需求，所以我们就需要一个包的规范来实现上述需求，这就是 APF。

要能过完美的兼容各种运行环境，第一个需要考虑的问题是使用 JavaScript 模块规范。例如，很多打包工具和优化工具基本只针对 ECMAScript Module(ESM) 有效（例如 Angular AoT 就只对 ESM 有效，而不能用于 CommonJS）。而在服务器端 Nodejs 上运行的时候需要对符合 CommonJS 规范的。

在最新的 nodejs 中已经支持了 ESM，但是这个功能目前处在实验阶段，需要单独的 --experimental-modules flag。而且也并非每个人都能用上最新的 nodejs。所以这个让 nodejs 使用 ESM 还不是目前最佳的解决方法。

APF 使用的是更加通用的 UMD 的模块规范，该规范可以同时满足 CommonJS 和 AMD 的规范。这样该模块就既可在 Nodejs 使用，也可以在浏览器中通过 script tag 使用。

此外，APF 还推荐在打包的时候还打包 Flat ES Module(FESM)，即将所有的独立的 Module 打包成一个文件。这样可以降低用户使用独立 Module 时的所需体积。

根据上面的描述，似乎只要提供 ESM、FESM 和 UMD 三种格式的编译后的文件就行了吗？其实不止，另外一个重要的要素是编译后的 JavaScript 的版本。

虽然目前很多打包工具默认都是输出 ECMAScript 5(ES5)。但是考虑到所有的 evergreen browsers（一般来说，指可以脱离系统独立更新的浏览器）都已经提供原生的 ES2015(ES6) 支持。所以 APF 推荐提供 ES2015 版本的编译结果，这样可以满足部分不需要支持旧浏览器的用户。

另外一个原因就是不同的优化工具对不同语言版本支持情况也不一样。例如 Uglify 目前只支持 ES5。

最后，因为 Angular 官方支持的第一开发语言为 TypeScript，所以提供 TypeScript 需要的 .d.ts(Type Declaration File) 也是有必要的。同时，因为 .d.ts 提供的信息不足以给 Angular 的编译器使用，还需要一个提供额外的包含每个 decorator 中元数据的 metadata.json。

目前，Angular AoT 模式中会将所有的元数据编译成类的静态类型，所以也就不需要像以前那样通过 Metadata Reflection API 获取元数据了。

下面我们以一个具体的遵循 APF 的包 @angular/material 为例子，描述具体的文件结构。

首先是整体的文件结构，主要分成了 esm2015/、esm5/、bundles/ 和其他各自的独立的 module 的文件夹。其中 esm2015/、esm5/ 和 bundles/ 就分别表示了 ESM+ES2015、ESM+ES5 和 UMD+ES5 的编译结果。

.
├── esm2015
├── esm5
├── bundles
├── autocomplete
└── ...

而在 esm2015、esm5 和 bundles 中则包括了该库中所有编译结果：每个独立的 module 的编译结果和整个库的 module 的都在其中。而每一个独立的 module 而编译结果都是一个 Flat Module。

.
├── material-tooltip.umd.js
├── material-tooltip.umd.min.js
│   ...
├── material.umd.js
└── material.umd.min.js

而在每个独立的 module 中都包含的各自该 module 的 package.json、metadata.json 和 .d.ts 文件：

.
├── index.d.ts
├── index.metadata.json
├── package.json
└── typings
    ├── button.d.ts
    ├── button-module.d.ts
    ├── index.d.ts
    ├── index.metadata.json
    └── public-api.d.ts

最后，在每个 package.json 中，无论是根层级的，还是独立的 module 中的，都含有以下几个字段：

"main": "./bundles/material.umd.js",
"module": "./esm5/material.es5.js",
"es2015": "./esm2015/material.js",
"typings": "./material.d.ts",

main 字段指向 UMD+ES5 的编译结果，主要用于 Nodejs 的环境；module 字段指向 ESM+ES5 的编译结果，主要用于 Webpack 等；es2015 字段指向 ESM+ES2015 的编译结果，主要用于配置过的 Webpack 和 Google Closure 等；最后 typings 指向 .d.ts文件，用于 TypeScript。

最后，在包的根目录里还有根整个 module 和每个独立的 module 的 metadata.json 和 .d.ts 文件。

这篇文章只是对 APF 的一个简单的介绍和一个典型的例子的分析，还有更多的细节没有提及：例如，如何提供多个 entry point 这样可与成让用户只导入需要的模块，降低编译后的体积。如果感兴趣的话可以查看原文档，以及 Juri Strumpflohner 在 ng-be 上的发言视频。

自 1991 年，第一个带有文档的 HTTP ──HTTP V0.9 问世以来，HTTP 协议得到了广泛的运用。

据 Cisco 统计，在 2016 年，全球的的网络流量达到了惊人的 1.2 ZB 流量，其中视频的流量就达到了 73%。而目前的视频传输协议中最常用的分别是 Apple 的HLS (HTTP Live Stream) 和 Google 的 DASH (Dynamic Adaptive Streaming over HTTP)，而两者都是基于 HTTP 的协议。

随着互联网的发展，网络通信中的安全性也得到了重视。在 1995 年，TLS 协议的前身 SSL 协议应运而生。而我们今天要讨论的就是在 SSL 诞生的 22 年之后，互联网上的 HTTPS 运用到达了什么程度。

我收集了目前 Alexa 排名前 1,000 的网站，虽然数量不多但是都是无疑占据了互联网上大多数的流量，通过来一窥互联网当前 HTTPS 的普及程度。部分的数据来自于 ssllibs。

实际上，我有 Alexa 前 1,000,000 的网站的名单。但是 ssllib 的 API 调用起来极其费时，对一个网站 ssl 配置的查询需要 2~3 分钟的时间，所以只能退而求其次。只考察前 1,000 个网站。

首先，在这 1,000 个网站中，目前有效的网站只有 981 个，其他的网站都无法成功解析其域名，可能是网站己经下线或者迁移到别的域名了，所以其是否支持 HTTPS 就不得而知了。

然后，在这 981 个网站中，支持 HTTPS 的恰好有 800 个，占比约有 81.5%。而在前 100 的网站中，只有 10 个网站不支持 HTTPS。

虽然这 800 个网站都支持 HTTPS 协议，但是他们在协议的实现上的不同也会产生安全性的差异。例如 RC4 加密曾经是 TLS 所采用的加密算法之一，但是在 2015 年遭到了破解，因此已经禁止在 TLS 中使用了。可目前仍然有网站使用 RC4 加密，甚至作为唯一的加密手段，那其 HTTPS 就形同虚设了。

我统计了这 800 个网站所支持的最高的 TLS 协议的版本：

绝大多数的网站（98%）的网站支持了 TLS 1.2 标准。比较遗憾的是，没有看到网站使用了最新的 TLS 1.3 标准，不过考虑到 TLS 1.3 还处在草案阶段，不使用也是合情合理的。此外，我也发现了还有 37 个网站仍在使用已经被认为是不安全的 SSL 3.0。

TLS 中最常见的握手方式两种：一种是基于 RSA 算法的；另外一种是基于 DH（Diffie-Hellman）算法。RSA 算法历史悠久，兼容性好；DH 算法在加密速度上更有优势，而且拥有前向安全性。TLS 握手的一个目的就是保证安全性。DH 握手可以使用除了RSA 以外的证书来提高性能，例如 ECC。ECC 证书内置了 ECDSA 公钥，使用了ECC（Elliptic curve cryptography）算法，它的密钥更短 ── 256 bit 的 ECC 算法强度和 3072 bit 的 RSA 算法安全性相当 ── 而加密速度更快。在 800 个支持 HTTPS 的网站中，大多数的网站还是选择了传统的 RSA 证书，只有少量的网站（35 个）选择了 ECC 证书：

TLS 握手的另外一个目的就是可以验证网站的身份，即需要数字签名。目前主要的签名方式有两者，分别是 RSA 和 ECDSA（Elliptic Curve Digital Signature Algorithms）。在这 800 个网站中，有 21 个网站使用了 ECDSA 签名：

当一个网站部署了 HTTPS 后，当用户再发起 HTTP 请求时，应该主动将用户引导到更安全的 HTTPS。目前有两种方法引导：一是当用户发起 HTTP 请求时，直接将其重定向到 HTTPS；二是设置 HSTS 响应头。

在这 800 个网站中，当我们直接发起 HTTP 请求时，HTTP 的状态码分布为：

我们知道在 HTTP 的状态码中，20X 的状态码表示资源已经找到；30X 表示重定向；40X 的状态码表示资源不存在；50X 表示服务器发生了错误；因此，我们的粗略的统计为 573 个网站会将用户重定向到安全的 HTTPS 页面。其余的不会。

和直接重定向到 HTTPS 相比，HSTS 的方法要好得多：网站在 HTTP 应答头中加入HSTS (Strict-Transport-Security) 的信息。它指定了一个有效时间，在有效时间内，当浏览器下次访问该域名时将直接使用 HTTPS 协议访问。

上述两种办法都有一个缺陷：都需要先经过一次 HTTP 请求后，才能过渡到 HTTPS 请求。如果第一次的 HTTP 请求就遭到了劫持，那就无能为力了。所以，相比简单的设置 HSTS 应答头，加入 HSTS Preloading List 的意义更大。

HSTS Preloading List 的原理就是在浏览器中内置一张支持 HSTS 网站的列表，当用户访问当中的网站时，如果在有效期内的话，浏览器会直接使用 HTTPS 链接，不会再发起 HTTP 请求。

目前的 HSTS Preloading List 主要由 Chrome 维护，Firefox 和 Edge/IE 都在使用。截至 2017 年 11 月 30 号，Chrome 的 HSTS Preloading List 中一共有 41312 个域名。而在这 800 个支持 HTTPS 的域名中，有124 个网站也在其中。

Chrome 的 HSTS Preloading List 支持申请，所以可以见这个列表来的域名将会越来越多，最后覆盖到我们常用的域名。

HTTPS 链接中，另一个容易受到攻击的地方就是证书。证书是由 CA（证书颁发机构）颁布的，而受信任的 CA 多达上百个。我们先来看看这 800 个网站的证书是由哪些 CA 颁发的：

现有的证书信任链还有一个问题就是任意一个受信任的 CA 都可以给任意一个域名颁发证书。所以如果出现了中间证书甚至是根证书被盗签时，对于浏览器来说是无法分辨的。

一种解决办法就是在应答头中加入 HPKP(HTTP Public Key Pinning) 信息：即将自己的证书指纹放在 HTTP 的应答头里，让浏览器记录这些信息。当浏览器下次访问时都会验证该指纹，如果指纹不对的话，即使证书合法，浏览器也会直接断开链接。

显然，HPKP 和 HSTS 一样也有 HTTP 被劫持的危险。所以也有相应的 HPKP Preloading List。但是和 HSTS Preloading List 不同，个人用户无法申请将自己的网站加入其中。所以目前的 HPKP Preloading List 的规模还比较小，而在这 800 个网站中也只有 2个网站设置了 HPKP 的应答头。

此外，Chrome 提出了另外一种解决办法，那就是 Certificate Transparency：即将整个证书签名的过程透明化，任何证书持有者和 CA 都可以将自己证书的记录提交到相应的 Certificate Logs 服务器中，而这整个记录都是受到审计和监控的；浏览器在访问网站时就会对证书进行校验，进而做出不同的反应。

下面就是一个支持 Certificate Transparency 的页面的例子：

但是，Certificate Transparency 目前只有 Chrome 支持。而 Chrome 知道其利用率还太低，所以即使在 Certificate Logs 服务器中查不到相应的证书也不会有太大影响。

从上面的分析我们可以得出：尽管大多数的网站都已经支持 HTTPS 协议了，但是实现还是参差不齐。而面对一些新型的攻击，例如首次 HTTP 协议遭到劫持，证书被盗签等问题准备得还是不够充分。

很可惜，没有收集到所有 1,000,000 个域名的 HTTPS 信息，不过还是可以统计一下其他的信息。例如，域名的长度：

和顶级域名的分布：

在开始聊这个话题之前，先提一个我遇到过问题：假设有一个 SpinnerService，这是一个可以在进行发送 HTTP 请求等异步操作的显示一个加载动画的 Service。

这样看来，它应该是每个 Module 和 Component 中都可能用到的一个 Service，那么我们把放到 SharedModule 的 providers 当中。然后在需要这个 SpinnerService 的 Module 中导入这个 SharedModule 即可。代码看起来大概是这样的：

// app/shared/spinner.service.ts
@Injectable()
export class SpinnerService {
  show() {
    /* code logic */
  }
  hide() {
    /* code logic */
  }
}

// app/shared/shared.module.st
@NgModule({
  providers: [SpinnerService]
  // ... other staffs
})
export class SharedModule {}

// app/some/some.module.ts
@NgModule({
  imports: [SharedModule]
  // ... other staffs
})
export class SomeModule {}

代码看起来没什么问题，而且也能正常运行。但是如果你在两个不同的 Component 中分别调用 SpinnerService 中的 show() 和 hide() 函数，你会发现加载动画没有如愿的消失；更近一步，如果在 Service 中有共用的数据的，你会发现两个不同的 Component 中对数据的修改也无法同步。Component 中的 Service 是由 Module 提供的，所以问题就出在 Module 上。

有的读者的可能已经猜到了：虽然两个 Module 中会提供一个 SpinnerService，但是他们不是同一个实例。

在继续解释为什么不是同一个实例的之前，我想先粗略地说一下为什么应该会是同一个实例。这就涉及到一个概念：Dependency Injection，动态注入。

以 angular.io 上的例子为例：假设有一个 Car 类，其依赖一个 Engine 类。

于是你可以这么写（不使用 Dependency Injection）：

export class Car {
  public engine: Engine;
  constructor() {
    this.engine = new Engine();
  }
}

当然也可以这么写（使用 Dependency Injection）：

export class Car {
  constructor(public engine: Engine) {}
}

两者看起来区别不大，而且当需要调用 engine 的时候，用法也是相同的。但是后者的好处却有不少：

1. Engine 和 Car 的结构是完全独立的：传入 Car 中的是 Engine 的一个实例而不是在 Car 的新建这个实例。所以如果 Engine 的构造函数发生变化的时候也不需要修改 Car 中的构造函数。

2. 因为传入 Car 中的是一个实例，所以可以复用这个实例，减少内存占用。

3. 因为传入的只是一个实例，所以甚至可以传入一个虚假用于单元测试的 Engine。

Angular 通过 Hierarchical Dependency Injectors 实现了上述的 Dependency Injection。Hierarchical Dependency Injectors 具体的实现，例如 Service 的复用，Component的 Injectors 等都是很值得一说的，不过和本文相关性不大，这里按下不表。

我们知道一个 Module 中可以有 Components、Directives、Pipes 和 Services。前三者都是与 HTML 模板相关的，需要放在在 Module 的 declarations 中；后者一般用来处理数据，放在 providers 中。

那么 providers 和 declarations 的区别是什么呢？其中一个就是两者的作用域不同：providers 中是全局的；而 declarations 则是本地的，只有该 Module 中可以使用。

Services 为什么会是全局的呢？其实很好理解，因为 Services 经过编译之后最后都是生成一个类，在导入或是导出它们的时候都会限定在命名空间内。

所以，Services 应该只在 providers 中出现一次；而其他三者则是在需要的 Module 的 declarations 地方都出现。

当然，在所有出现的地方都需要写一遍也是非常烦杂。这时我们就可以把他们放到一个 SharedModule 的 declarations 和 exports，最后在需要的 Module 中导入该 SharedModule 即可。

对应到上面的问题，你会发现确实也只有在 SharedModule 的 providers 中出现了 SpinnerService 呀，但是问题还是存在啊。

其实不止 SharedModule，导入了 SharedModule 的 SomeModule 相当于也提供了 SpinnerService。所以在两个 Module 中就会有两个由不同的 Module 提供的，两个不同的 SpinnerService。

导入拥有提供了 Services 的 Module，相当与自己提供了相同的 Services。这样的例子这样的情况你可能早就接触过了：当你在 AppModule 中导入了 HttpModule 之后，你就可以使用 Http 这个全局 Service 来发送 HTTP 请求了。

这里的 AppModule 指 Root Module，下同。

另一方面，如果一个 Module 既有 Components 也有 Services 时则需要分别对待了：在 AppModule 中导入这个 Module 的时候需要调用 forRoot()，它返回的是一个 ModuleWithProviders；而在其他的 Module 则是直接导入这个 Module 或者调用 forChild()。例如 RouterModule 就既有 Component <router-outlet> 和 Directive routerLink，也有 Service ActivatedRoute。

至此，要解决文章开头的问题可以很简单：将 SpinnerService 放到 AppModule 的 providers 里即可。

但是，这样的简单粗暴地将每一个 Service 都交由 AppModule 提供的解决方法违反了我们一贯的原则：尽可能保持每个 Moudle 的功能和结构简单。

所以，我们确实应该将 SpinnerService 移出 SharedModule，然而也不应该放进 AppModule 而是可以考虑放进一个新建的 CoreModule 中。而这个 CoreModule 也应该作为一个纯粹的只提供 Services 的 Module，而只在 AppModule 中导入它。

当然，因为只在 AppModule 中导入，所以如果有一些只需要在 AppComponent 中使用的 Component，如 NavComponent 和 FooterComponent 等也可以考虑放到其中。

1. 文章中提到了可以使用一个虚假的 Service 用于 Component 的单元测试，这里介绍了具体应该怎么做。

2. Angular 的 Hierarchical Dependency Injectors 系统，这是一个很有趣的系统，每一个 Component 都有一个与之对应的可编辑的 Injector。具体可以查看的 Angular 的官方文档：Hierarchical Dependency Injectors。

3. 写 Angular 应用的一个原则都是保持每一个 Module 的功能和结构的简单和统一，这一点和 Unix 的哲学不谋而合：Write programs that do one thing and do it well.那么我们怎么应该这么设计一个好的 Module 呢？Angular 官方的 NgModule FAQs 中其实给出了答案。从中我们可以看出，CoreModule 这种只提供 Services 和SharedModule 这种只提供 Components，Directives 和 Pipes 的 Module 是目前来说官方认为最好的设计。

我曾经试图将我的所有课笔记转换成 Markdown 文档以永久保存。我的笔记包含了大量的数学公式，所以需要在 Markdown 里内嵌 LaTeX。

LaTeX 是对著名排版系统 TeX 的二次开发，TeX 是公认的数学公式排版最好的系统。

但是，在 Markdown 里编辑 LaTeX 简直是噩梦：编辑器不提供 LaTeX 的补全。一个公式里可能有大量重复的 \alpha、\sigama 和 \rightarrow 等符号，而它们全部需要我一个字母一个字母地输入。

此外，在 Markdown 中内嵌 LaTeX 大多是通过 MathJax 实现的，但是 MathJax 支持的宏十分有限:

所以在花费了大量时间将一本书的笔记录成 Markdown 之后，我放弃了。:)

后来在 #archlinux-cn 的 riaqn 安利下，我开始使用 Emacs 的 Org-mode 来作笔记。不得不说相比 Markdown，Org-mode 配合 Emacs 的生态，在各种体验上都上升了不止一个等级。

当然，一个编辑器想要达到最佳的输入效果，一番配置是少不了的。下面就是我的整个 Emacs + Org-mode + LaTeX 环境的配置过程，大家可以选择性观看。

Emacs(Editor MACroS) 是一个文本编辑器，著名的编辑器之战的两大主角之一（另一个是 vi 即其派生版本）。

在 openSUSE 中安装 Emacs 只需要在 root 用户下运行：

$ zypper in emacs

其他的 Linux 发行版请尝试使用包管理器安装，或者和 Windows/macOS 用户一起看看官方文档。

而 Spacemacs 是一个由社区驱动的 Emacs 的分支，它的口号是：

The best editor is neither Emacs nor Vim, it's Emacs and Vim!

正如他们的口号所言，Spacemacs 的最大的特点就是 Vim 风格中通过 Evil 实现了 Vim 的键位绑定。在 Emacs中也能使用 Vim 中独特的 insert mode 和 visual mode 了。

Spacemacs 的默认风格是 Vim，同时也提供了 Emacs 和 Hybrid 适用不同的人。

安装 Spacemacs 只需要：

$ mv ~/.emacs.d ~/.emacs.d.old
$ git clone https://github.com/syl20bnr/spacemacs ~/.emacs.d

在 Windows 下的话，不仅要将 Spacemacs 的 .emacs 放在 C:\Users\{username}\ 同时也要在 C:\Users\{username}\AppData\Roaming 里。此外，还有可能出现 packages unavailable 的情况，此时可以参考一下官方的 FAQ。

无论是什么 Editor/IDE，装好的第一步应该都是修改字体吧。Spacemacs 的默认等宽字体是 Abode 的 Source Code Pro，这曾经是我也是我的首选，不过我现在喜欢用带连字（ligatures）的 Fira Code。

Spacemacs 的配置文件在 ~/.spacemacs，打开后找到 dotspacemacs-default-font修改成：

dotspacemacs-default-font '("Fira Code"
                            :size 21
                            :weight normal
                            :width normal
                            :powerline-scale 1.4)

其中字体大小，宽度等参数见个人喜好，你可以在这里看到各个参数的含义。

英文的等宽字体配置完后，还可以选择性地配置其他的语言，例如中文（这里需要先判断一下是不是 GUI）：

;; Set Chinese Font
;; Put this inside `dotspacemacs/user-config()`
(if window-system
    (dolist (charset '(kana han cjk-misc bopomofo))
      (set-fontset-font (frame-parameter nil 'font)
                        charset (font-spec :family "Noto Sans SC" :size 20))))

如果不配置中文字体的话，在打开带有中文字符的文件时，Emacs 会出现严重的卡顿。:(

Org-mode 是 Emacs 中的一种编辑模式，支持编写 To-do list、日志和笔记等功能。其中（对于我来说）最重要的就是支持内嵌 LaTeX 了。Org-mode 从Emacs 22 开始就已经成为默认安装的部分了，所以不需要额外的安装操作，只需要打开带有 .org 的文件，就会自动进入 Org-mode 了。

不过想要有 LaTeX 的预览/导出的话，还需要安装 texlive。openSUSE 下依旧是在 root 环境下运行：

$ zypper in texlive

#archliux-cn 的 farseerfc 前辈提示我可以用 texlive 的 Unix Installer，方便管理各个版本的 texlive，不过我还未尝试过。

其他的系统也可以使用包管理器安装或者请参照一下官方文档。

Org-mode 内嵌 LaTeX 有几种方式，display 我喜欢用 \[E=mc^2\]，inline 我偏好 $E=mc^2$。预览时只需要用 C-c C-x C-l (org-toggle-latex-fragment) 即可。

默认的预览有点小，所以我在 .spacemacs 里拉伸了一下大小：

;; Enlarge LaTeX Fragment in Org-mode
;; Put this inside `dotspacemacs/user-config`
(require 'org)
(plist-put org-format-latex-options :scale 2)

到这里看来 Emacs + Org-mode 的组合相比 Markdown 似乎没有给输入太大的便利吧。所以接下来要介绍的就是 Emacs 的另外一个 mode 了，这个 mode 可以大大提高在 Org-mode 中输入 LaTeX 的效率 ——CDLaTeX。

在介绍 CDLaTeX 的工作原理之前，先说一下 Emacs 中的 mode：Org-mode 和 CDLaTeX虽然同是 Emacs 的 mode，但是地位不同的。Org-mode 是 Major Mode（主要模块）；CDLaTeX 是 Minor Mode（辅助模块）。一般来说 Emacs 是不能同时使用多个 Major Mode。

如果想在 Emacs 的 buffer 中开多个 Major Mode，参见：MultipleModes

所以 CDLaTeX 作用其实是实现了部分来自另外一个 Major Mode ——AUCTeX 的功能，让你可以在其他的 Major Mode 里快速输入 LaTeX。

相比直接在 Org-mode 里使用 CDLaTeX，Org-mode 推荐使用 Org-mode 自带的轻量版的 org-cdlatex-mode。

org-cdlatex-mode 依赖 cdlatex.el 和 texmathp.el（这个来自 AUTeX，作用是判定目前光标所在位置是否在内嵌的 LaTeX 中）。所以我们需要在 .spacemacs 加入我们需要安装的 CDLaTeX 和 AUTeX：

dotspacemacs-additional-packages '(cdlatex auctex)

然后重启 Emacs，Spacemacs 会自动帮你安装好他们。

注意全部使用小写，而且不要用 M-x package-install 来安装，因为 Spacemacs 会在重启之后删掉他们……

再次打开 Org-mode，用 M-x org-cdlatex-mode 打开 CDLaTeX。然后你就可以体验的 CDLaTeX 带来的快速输入 LaTeX 的功能了：

1. 用 <TAB> 自动补全一些 LaTeX 模板，例如：fr => ~\frac{}{} 和 lr( => \left(\right)。此外，<TAB> 也可以用于在各个 {} 之间跳跃；

2. _ 和 ^ 会自动补全 {}，不过如果 {} 里只有一个元素的话，也会自动去掉；

3. 在 ` 后加一个字母可以快速输入一些 LaTeX 的符号，例如 `a => \alpha 和 `b => \beta；

4. 在一些字母之后加上 ' 则是可以修改该字母的字体或者加修饰，例如 a'. => \dot{a} 和 a'1 => {\displaystyle a}。

经过上述配置和折腾之后，整理笔记终于成了一件不那么麻烦的事了。:)

一直有人问我为什么那么费劲的在各种标记语言里嵌套 LaTeX，而不直接用 LaTeX 写呢？嗯…其实我一直有一个想法就是建立一个属于自己的类似知识库的东西，所以我的期望是可以导出成 HTML 以便于时刻可以浏览，而 LaTeX 在这方面就比较吃力了。

不过使用了 Org-mode 之后也有一个问题：目前似乎没有现成的基于 Org-mode 的 Wiki Software，所以这意味着我可能又需要自己造个轮子了……:(