在通过各种编辑工具使用各类编程语言进行开发的过程中，我们会被大量噪音分心。

举个例子

我们为了美观性，为了代码格式和对齐，我们会大量的插入/删除Space、Tab和Enter。

对于一些同层级的操作，我们可能会手工对齐它。

举一个极端的例子，例如我写的代码就是这样的

这样的

以及这样的

为了使这些代码变得美观，变得整齐工整，无疑是一件很痛苦的事。

同时，语法节点的输入也是个带问题。

对于一颗语法树，我们需要输入它的头部。例如

match

以及我们需要输入它的词法界限来分割它的块部分，例如

with | 和 ->

——而这是完全没有必要的

据直觉性的非客观的不完全统计，在我们写代码的时候30%的部分写的就是这些东西（x

我们完全可以在我们输入语法树的头部时，就让编辑器帮你弄出整个块

我们能输入错误的源代码

这一点我是觉得是最不可思议的。

同志们，已经9102年了，我们用的代码编辑器居然还能让我们输入能让编辑器报错的代码。

Q: 所以，我们需要什么？

A: 所以，我们需要一个高度语言特化的AST编辑器——也就是结构化编辑。它应该最大程度的照顾用户体验——也就是以人为本。

注意：它不是图形化的编辑器，也不是像UE4蓝图那样的东西。

以及，一些有趣的特性

一旦我们用上了AST编辑，那么我们就可以做一些很好玩的东西了

由于编辑器的操作对象是AST，因此我们就能很轻松的指定由编辑器渲染出的代码样式——通过写插件和编辑样式文件的方式。

符号查找和定位是低开销的：对于传统的编程语言而言，符号查找的开销无疑是较高的。首先我们需要从源码中构建出AST，然后我们需要维护一个AST到源码的映射表——在这个过程中，一旦能构建出AST的Token序列被破坏，那么就我们没法从源码中得到任何可用的信息了，我们就只能猜，猜到哪个算哪个。（同时我们能够避免写编辑器的String数据结构（比如坨坨桌子（逃

降低Parser实现难度：对于这一点，大锤予以了反驳，他认为合格的编译器应该独立处理所有的语法问题。我倒是不这么觉得，首先在任何情况下，读纯ast表达式（包括且不限于json、xml）应该是成本最低的方式了。

举个小众的例子：众所周知，某些语言中提供了自定义运算符和控制流的语法。（点名批评Haskell和F#）而为了实现这种功能，我们在实现Parser的时候会用上很复杂的算法和操作。

我认为这是一种很不干净的行为，我们完全可以把这部分功能（甚至一部分宏的作用）交给编辑器前端去做。

最大程度上防止用户写出有问题的代码：

这一部分我觉得是结构化编辑最有价值的部分。

举个例子

我们使用Pigeon（目前还不存在的）语言时，我们输入了一个表达式

1 + a

——在正常情况下是这样的

但是，如果我们没有定义a呢？我们没有在任何作用域中定义这个a呢？或者说，这个a的类型和(+)这个函数不匹配呢？

我们的编辑器会对它标记一个红色下划线？不对，此时这个a是写不出来的。我们可以在intellcode的提示中直接进入重构引导。

从这一步我们就可以看出来了。整个的代码编辑过程应该是很流畅的。代码编辑器每时每刻都在和用户强交互。

必要性？

看到这里有人会问啦：那么这些东西和我们现在用的编辑器有什么本质的区别吗？

从使用者的角度来看，两者都能提供同样的功能。但结构化编辑器会带来更整体而非是零碎的体验。

未来的问题

当然，截止目前，结构化编辑器的构思还有很多问题。例如怎么选择和操作ast，例如快捷键该怎么设置，会不会让开发者更快患上腱鞘炎（逃）。诸如此类的问题。

但我们仍然选择相信下一代编辑器，能带来更好的开发体验，能够真正做到以人为本。