“這看起來相當愚蠢”——題記
不過我整個人都很荒誕，何妨呢？貼一張目前的效果圖
看起來很舒服，不是麼？即使一切都是個幌子：光標只能在最後，按一下上下左右就會退出，一行超出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 於地球，未完）