编辑器的自制 _编辑器

最近的几个月里，我一直在寻找一种合适的方式来构建底层应用。可能是 Web、App 应用已经缺乏了一些新鲜感；也可能是受受国际局势的影响，我开始思考构建底层应用架构的能力。
于是，在我学习了一段时间的 Rust 之后，我便不断地往系统的底层探索。在那之前，另外一门合适的语言大抵是 Golang，不过我偏向于认为 Golang 是一个 Web 应用或者普通应用的开发语言，而非一个系统编程语言。
这其中的一个话题就是：编辑器以及 IDE 。毕竟，讨论 Emacs 和 Vim 哪一个更好，已经不能满足我的需求。程序员的乐趣应该在于如此去写一个 Emcas，便实现一个 Vim —— 毕竟 Emacs 操作系统太复杂了。

1. 无 UI 式：命令行编辑器

文章插图
作为过程的第一步，我开始寻找一些合适的编辑器（PS：主要是简单），以作为我的编辑器和 IDE 生涯的第一步。然而，这并不是一件容易的事，毕竟我先前构建 Client 端的经验，都是使用现成的 UI 组件，如 WebView 的 Textarea、Android 框架中的 EditText 组件。
于是乎，我模仿 + 复制 Iota 项目的一部分代码，形成了一份最小可工作的代码，以了解命令行编辑器如何运作的整体原理：
字符移动
对于终端编程来说，并不存在组件可以使用，所以我们所要做的事情是：在特定的位置显示特定的字符，如：

rustbox.print_char(1,1,RustBoxStyle::empty,Color::White,Color::Black,'A')

这样一来，它就在屏幕上的 1,1 的位置画了一个 A，它的前景是白色，背景是黑色。嗯，没错，这种体验就是我大学玩的嵌入式编程。
于是，第一步我们要做的就是读取文本，然后渲染。这里用的库是 RustBox，它封装了 C 语言下的 Termbox 。对于一些人来说，更为熟悉的名字可能是 curses，又或者是 GNU 里的 ncurses 。在另外的一个 Rust 编写的编辑器 [amp] 中，使用的是 termion 。
快捷键识别随后，我们可以启动起编辑器，而后做各种事件轮询，等待用户的交互，如快捷键。同样的，这个功能也是由底层的 Termbox 提供了支持，我们只需要创建行为与快捷键的绑定即可。
状态栏 + 命令模式。有了上面的基础之后，这个也不会遇到什么困难。
语法高亮。这里我就被 iota 这个项目坑了，项目的截图上是有语法高亮的，但是代码上已经删了。回溯了一下过程，发现这部分的功能删了，因为原先的设计并不合理。合理的方式应该是使用 syntect 这种现成的方案，它使用了 Sublime Text 的语法定义格式。
理解了原理，快速画了个瓢之后，我就转向 UI 式的文件编辑器。
GitHub: https://github.com/rapilab/rinput

2. UI 式：进程分离

文章插图
随后，我在 Awesome-rust 项目中，物色到了第二个可以项目：xi-editor 。Xi Editor 是 google 员工开源的一款用Rust 语言编写的文本编辑器。从之前的新闻来看，像是火了一段时间，但是好像已经没有那么活跃了。
它最主要的特点有：
前后端分离。编辑器分为两部分，后端和前端。后端（即核心部分）负责保存文件缓冲区，并负责所有潜在的昂贵编辑操作。你可以将等价为前后端分离应用的关系，又或者是 Electron 应用中：Electron 的 Node.js 和 WebView 部分的区别。
JSON RPC 。xi-editor 提供了 JSON 形式的 RPC（远程过程调用）用于前后端之间进行通讯。采取 JSON 的主要原因是减少开发插件的成本，更好的扩大生态。如，我从 UI 上修改编辑器的主题，将通过 RPC 的方式通知后端，并将对应的配置存储到系统中。并且诸如于 IDEA 的索引模式，它应该也会在后台运行，而不占用 UI 进程，影响用户体验。如此一来，我们所面临的卡顿问题，会进一步得到缓解。
不限 UI 。因为 xi-editor 本身只提供 core 模块，所以，我们可以看到有各种各样的 xi-editor 的前端，如原生 macOS 实现、基于 Electron 实现等等。
所以，我尝试基于这种架构模式，开发了一个基于这种架构模式的系统状态应用 Stadal 。有了这样的模式，我们就可以分离 UI 进程，提供更好的用户体验。
顺便一题，在这种模式之后，编辑器的模型都统一由后端管理（PS：这一点与 Web 应用是相似的，笑~）。

Emacs 架构：M-V-C 架构这样一类比的情况下，Emcas 的架构就好似一个大单体一样。毕竟这是 M-V-C 架构（源自《架构之美》：