编辑器的自制
最近的几个月里,我一直在寻找一种合适的方式来构建底层应用。可能是 Web、App 应用已经缺乏了一些新鲜感;也可能是受受国际局势的影响,我开始思考构建底层应用架构的能力。
于是,在我学习了一段时间的 Rust 之后,我便不断地往系统的底层探索。在那之前,另外一门合适的语言大抵是 Golang,不过我偏向于认为 Golang 是一个 Web 应用或者普通应用的开发语言,而非一个系统编程语言。
这其中的一个话题就是:编辑器以及 IDE。毕竟,讨论 Emacs 和 Vim 哪一个更好,已经不能满足我的需求。程序员的乐趣应该在于如此去写一个 Emcas,便实现一个 Vim —— 毕竟 Emacs 操作系统太复杂了。
1. 无 UI 式:命令行编辑器
![编辑器的自制](https://www.isolves.com/d/file/p/2020/08-06/68d47aa44685dba988da52362a1673a2.jpg)
作为过程的第一步,我开始寻找一些合适的编辑器(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 式:进程分离
![编辑器的自制](https://www.isolves.com/d/file/p/2020/08-06/1a9843c4c0f49cffc03f87b50d83dae5.jpg)
随后,我在 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 架构(源自《架构之美》:
-
模型。程序所操作数据的底层描述,如文本属性、缓冲区等等;并与系统进行交互。
-
视图。面向用户展示数据的方法,如对于窗口增量显示更新逻辑等。
-
控制器。负责实现用户与视图的交互(如按键、鼠标事件等),并对模型进行更新(采用 Lisp 作为支撑)
至于插件部分则是由 Lisp 脚本来实现,至于是插件好还是脚本好就是另外一个问题了。
GitHub :https://github.com/phodal/stadal
IDE:IDEA 的插件化
![编辑器的自制](https://www.isolves.com/d/file/p/2020/08-06/d90de7a81ea0f1c6647582f5f5f7c780.jpg)
因为偶然地原因,我分析了一段时间的 Intellij IDEA 社区版 + Android Studio 的源码之后,我有了一些新的感受 —— 这个系统架构有点复杂,哈哈。当然,也发现了一些相似的模式。
隔离层:独立二进制
对于工具的制造者来说,开发者并不希望工具被捆绑在某一个开发工具上。因此,对于开发者而言,优先做的是提供一个可独立运行的程序,而后再封装一个针对于该工具的实现。
于是乎,这个运行的程序,它可能是:
-
C/C++ 编写的二进制应用。通过 daemon 的方式来运行,并能通过解析输出来进行错误处理。
-
Gradle 开发的插件。并借助于 Gradle Tooling API 来实现插件的调用。
-
JAVA 编写的应用。通过直接集成的方式进行。
-
……
这样一来,我们就在 IDE 中集成了这样的能力,并引入到我们的系统中使用。
语言扩展
IDEA 本身的插件体系已经设计得很完善了,如我们可以快速添加一门语言,只需要:
-
注册文件类型
-
实现 Lexer(词法分析)
-
实施 Parser(语法分析) 和 PSI(程序结构接口)
-
语法高亮显示和错误高亮显示
-
代码补全
-
查找用法
-
重构:重命名、安全删除
-
代码格式化程序
-
……
这样一来,我们就能快速地具备一个语言 IDE 应该有的能力。比如 IDEA 的 Rust 插件就是这样一个不错的示例。
![编辑器的自制](https://www.isolves.com/d/file/p/2020/08-06/b587464309f29446cb31088a0f1e76ce.jpg)
总结
一个好的编辑器/IDE 应该能:
-
滋长的特性:通过插件化支撑
-
可维护性:具备良好的可读性
-
进程分离
-
速度
讨论哪个编辑器/IDE 是一件没意义的事。
只有自己挖的坑才是好的。
我行我上。