不成熟的思考

像Vim、Emacs这种，必须依赖组合键或者模式去工作。工作的复杂度落实在按键组合的维度。

有一些程序比如 tig 他的交互围绕着简单的按键，这跟他的工作模式单一有关，不需要处理复杂交互。像编辑器需要不断的填充功能，所以在键盘映射上尤其混乱。

这个角度从命令行过渡到图形界面，其实是必然的，因为不论是哪种模式的按键没有真正带来效率的提升。鼠标确实是一个更伟大的发明。

而有了GUI的软件之后，命令行的角色，可能也更加明确，适合模式单一、即用即抛、开发、生产环境中固定场景的工具。

命令的设计其实和图形界面非常相似，但是多媒体展示部分只能以文字为主。这只对这种特征的程序利好。

因此命令行程序的现状除了 Emacs、Vim 之外，都保持在一个非常小众、小型，依赖于 lib 编写的情况。不再有大规模像网站一样的复杂 TUI 应用。

我做一个不恰当的比喻，这就像游戏开发。我们依然可以命令行绘制像素点方式编写游戏，自己绘制游戏引擎。但是一旦出现了解决复杂问题的游戏引擎 —— 真正的效率断崖就被制造出来了。人们再刻意通过刀耕火种的方式构建复杂程序，实际上是在时间上自杀。

自制

有段时间对命令程序比较感兴趣，研究了一些做了记录。

在 https://github.com/maerch/ruby-drawille 部分的example有一个例子可以打印小乌龟路径。结果依然是一个椭圆。命令行这个方面就算是换成unicode点阵输出图案，依然是失真的。这个角度我比较放弃了。

一上午在看从编辑器从命令行到scintilla成为众多现代编辑器的底层。这个难题一直在解决之中。

从目前来看，TUI 也不适合做复杂的交互，即使是 Tig 这样的程序，我个人也不会真正的用它提交代码，只能单游标输入，并且受限于命令行界面确实是非常简陋。但是适合简单的程序。比如脚手架，或者 repl 用于纯数据展示。这也是符合目前使用的。

我之前有个计划就是把 MVVM 的思想带到命令行里，这样可以构建复杂的程序。但是我想了想，浏览器这种复杂的软件，开发过程中的debug需要完善的报错机制帮助debug才得以进行下去。使用命令行，在开发的过程中刀耕火种，这也会是压死自己的稻草了。