“这看起来相当愚蠢”——题记
不过我整个人都很荒诞，何妨呢？贴一张目前的效果图
看起来很舒服，不是么？即使一切都是个幌子：光标只能在最后，按一下上下左右就会退出，一行超出75个字符就会连带行号消失，打完36行程序就会奔溃——而且不能保存，仿佛一台玩具打字机。但这又怎么样？我喜欢！我想把它放到github上去——但是恐怕随时得回滚，所以算了吧。
我从来不在乎开发，我在乎的是哲学，一切空谈在我眼里都是有价值的。所以，我刚开始写的时候，我在想什么？
——我在想，我要写个命令行编辑器——那是什么东西？——就是一个命令行界面，每敲一个键就变化一点——并且按传说中MVC的做法，要有个模型，在这里唯一的参数就是包含整个文本的字符串——所以主循环就是显示字符串→接收输入→更新字符串。每一步都可谓开销巨大（以至于给人以罪恶感），但现在不是优化的时候——现在可以写个大致了。给出目前为止的代码：（某版本真实代码）
screen = ""
while True:
show_screen()
ch = getch()
update(ch)不能运行，并不重要。事实上我们发现这是一个状态机（字面义）——而这里的状态仅仅是screen字符串的状态。简单的结构是令人欣慰的。（我看了一眼代码，觉得应该在 show_screen() 和update(ch)的括号里都添上screen）
（半天过去了）
单行长文本bug解决了。（虽说我就从没写过超过一行的代码）
（又过去了一天）
重写了逻辑，依然混乱。所以先发表吧。
（2018-1-1 于地球，未完）
问题一般化：【怎样写出一个命令行程序？】
既然是一个状态机，我们当然可以列出一个状态表，屏幕每次由状态刷新（#），动作将改变状态。对于命令行，仅有的动作就是击键，而且是有限个。动作响应也是离散的，一次击键只需要变动一次屏幕（#）。我先不谈文本编辑器，此前的一个小程序很好地符合了这些思想——一个九宫格走迷宫的程序（虽然当时我还没有模型意识）。9个房间，左转右转或前进。状态是有限的，只有有限个位置可以站。所以我们可以列出一张表：
| 动作1 | 动作2 | 动作3 | …… | |
|---|---|---|---|---|
| 状态1 | 操作11 | 操作12 | 操作13 | …… |
| 状态2 | 操作21 | 操作22 | 操作23 | …… |
| 状态3 | 操作31 | 操作32 | 操作33 | …… |
| …… | …… | …… | …… | …… |
而显示与状态是唯一对应的。所以理论上填完这张表，问题就解决了。但这是不现实的，连那个走迷宫程序这张表都不适用，因为状态的“组合爆炸”。在走迷宫程序中，状态是由“所在房间”和“正对方向”2个参数组合而成的，并且一切都是临时组合，也因此有些组合不可到达。而在编辑器的例子中，组合甚至是无穷的！在我现在处理的版本中，虽然只有字符串一个参数，但足以造成无限的状态。所以……
应当看做同一个状态。
我想到了“化归”，更确切一点是“等价划分”。将若干个甚至无穷多状态看作同一状态。在编辑器中，所有的编辑都是同一个状态。当加入光标左右移动，光标在中间的时候是等价的，只有在两端才可能出现特殊情况，所以可以划分为3个等价状态……但是开发是一个过程，我们一开始当然想不到这么多，怎么处理呢？——渐进或许是个好办法。在初始版本（单行打字机）中，逻辑是这样的：
| 26字母（分大小写）和空格 | |
|---|---|
| 编辑状态 | 将接收到字符添加到字符串尾部 |
少许改进后是这样的：
| 26字母（分大小写）和空格 | 退格 | |
|---|---|---|
| 编辑状态 | 将接收到字符添加到字符串尾部 | 删除字符串最后一个字符 |
这种表无法表示实际显示，但实际显示既然是状态的唯一函数，也不用担心逻辑问题……虽说简直没有实用价值，但这么分析至少带给人好处。
（又过去一天，我要重写代码……）
（2018-1-9 于地球，未完）原文地址：http://blog.51cto.com/13535617/2059088