CodeEditor UI Optimization

[nighca]

#465 (comment)

工具 / Tool

引入“工具 / Tool”的概念，它是由 Go+ / spx 预先定义的，所有可供用户使用的辅助工具的集合。

从编程角度说，“工具”对应的是以下内容：

• Go+ keyword，如 var、for 等
• Go+ 预置函数，如 println
• spx API，如 turnTo、say、onKey 等，详见 SPX APIs #483

从编辑器 UI/UX 角度看：

• 一个工具可能对应多个使用姿势，每个使用姿势对应一个 (monaco) snippet 定义
• 每个工具有自己的元信息（如归类），编辑器可以通过对元信息进行可视化以帮助用户建立对工具的感官记忆，提高理解或编写代码的效率
• 工具可以被列出 & 检索，这降低用户对代码上的 keyword、API 进行记忆的负担
• 工具会有对应的说明文档，以及辅助输入流程；这一方面帮助用户学习在代码上的使用，另一方面降低不熟悉工具的用户对工具进行使用的难度

在 Go+ Builder 中编写代码就是用户使用工具进行组合以达到目的的过程

工具的分类

我们从两个维度对工具进行分类

1. 功能，即游戏中的不同概念，如外观、造型、动作、声音等
2. 类型，接近编程语言的类型信息（但有区别），如字段（读）、方法（写）等

功能

功能是用户“检索”工具的主要依据，做细致的两级分类；比如 外观 -> 造型 -> 切换造型，动作 -> 朝向 -> 设置朝向，“外观”&“动作”是一级分类，“造型”&“朝向”是二级分类，“切换造型”&“设置朝向”是具体的工具

类型

类型是帮助用户快速区分功能概念上接近（往往意味着名字中的关键字接近）的多个工具的依据。以 nextCostume & costumeName 为例，基于定义“costumeName 表示获取当前 costume 的名字”，可能会不确定 nextCostume 是以下两个定义的哪一个：

1. 获取当前 costume 下一个 costume 的信息
2. 切换到当前 costume 下一个 costume

需要注意，为了命名上的简洁，spx 在定义 API 时，对接近的业务概念的读写操作命名上接近是很容易发生的，因此这个例子不应当视作个例。我们可以举出别的例子，比如“Up”可以被理解为“上这个方向”，或“向上移动”，如果没有“类型维度”的信息，那么用户经常会需要细心地阅读“说明文档”才能正确地理解或使用。

在类型维度上，我们将所有工具分为四类：

1. 数据，对内存中或外部信息（或常量定义）的读操作，从代码输入输出的角度说一般是输入，如 costumeName、keyPressed、Up 等
2. 动作，对内存中或外部的写操作，从代码输入输出的角度说一般是输出，如 nextCostume、say、move、broadcast 等
3. 监听，绑定监听函数，如 onKey、onStart、onMsg 等
4. 其他，如流程控制（if、for 等）、基础关键词（var 等）

相比功能维度，类型维度的定位偏辅助，因此在这个维度上不会做很细致的拆分；也因此类型维度的信息量不大，它适合通过颜色/形状/简单 icon 等方式表达

后续

• Code AST & Code Type Information (LSP?)
• Breakpoint support & execution visualization

[nighca]

跟这个 issue 一起顺便解决下：

注意看下是否还有其他类似（需要小括号调用）的函数/方法