标签:而在 images src 单行 vpd 变化 git code size
“这看起来相当愚蠢”——题记
不过我整个人都很荒诞,何妨呢?贴一张目前的效果图
看起来很舒服,不是么?即使一切都是个幌子:光标只能在最后,按一下上下左右就会退出,一行超出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 于地球,未完)
标签:而在 images src 单行 vpd 变化 git code size
原文地址:http://blog.51cto.com/13535617/2059088