不過我整個人都很荒誕，何妨呢？貼一張目前的效果圖

　　看起來很舒服，不是麽？即使一切都是個幌子：光標只能在最後，按一下上下左右就會退出，一行超出75個字符就會連帶行號消失，打完36行程序就會奔潰——而且不能保存，仿佛一臺玩具打字機。但這又怎麽樣？我喜歡！我想把它放到github上去——但是恐怕隨時得回滾，所以算了吧。

　　我從來不在乎開發，我在乎的是哲學，一切空談在我眼裏都是有價值的。所以，我剛開始寫的時候，我在想什麽？

　　——我在想，我要寫個命令行編輯器——那是什麽東西？——就是一個命令行界面，每敲一個鍵就變化一點——並且按傳說中MVC的做法，要有個模型，在這裏唯一的參數就是包含整個文本的字符串——所以主循環就是顯示字符串→接收輸入→更新字符串。每一步都可謂開銷巨大（以至於給人以罪惡感），但現在不是優化的時候——現在可以寫個大致了。給出目前為止的代碼：（某版本真實代碼）

screen = ""


while True: 
    show_screen()
    ch = getch()
    update(ch)

　　不能運行，並不重要。事實上我們發現這是一個狀態機（字面義）——而這裏的狀態僅僅是screen字符串的狀態。簡單的結構是令人欣慰的。（我看了一眼代碼，覺得應該在 show_screen() 和update(ch)的括號裏都添上screen）

　　（半天過去了）

　　單行長文本bug解決了。（雖說我就從沒寫過超過一行的代碼）

　　（又過去了一天）

　　重寫了邏輯，依然混亂。所以先發表吧。

（2018-1-1 於地球，未完）

　　問題一般化：【怎樣寫出一個命令行程序？】

　　既然是一個狀態機，我們當然可以列出一個狀態表，屏幕每次由狀態刷新（#），動作將改變狀態。對於命令行，僅有的動作就是擊鍵，而且是有限個。動作響應也是離散的，一次擊鍵只需要變動一次屏幕（#）。我先不談文本編輯器，此前的一個小程序很好地符合了這些思想——一個九宮格走迷宮的程序（雖然當時我還沒有模型意識）。9個房間，左轉右轉或前進。狀態是有限的，只有有限個位置可以站。所以我們可以列出一張表：

　　而顯示與狀態是唯一對應的。所以理論上填完這張表，問題就解決了。但這是不現實的，連那個走迷宮程序這張表都不適用，因為狀態的“組合爆炸”。在走迷宮程序中，狀態是由“所在房間”和“正對方向”2個參數組合而成的，並且一切都是臨時組合，也因此有些組合不可到達。而在編輯器的例子中，組合甚至是無窮的！在我現在處理的版本中，雖然只有字符串一個參數，但足以造成無限的狀態。所以……

　　應當看做同一個狀態。

　　我想到了“化歸”，更確切一點是“等價劃分”。將若幹個甚至無窮多狀態看作同一狀態。在編輯器中，所有的編輯都是同一個狀態。當加入光標左右移動，光標在中間的時候是等價的，只有在兩端才可能出現特殊情況，所以可以劃分為3個等價狀態……但是開發是一個過程，我們一開始當然想不到這麽多，怎麽處理呢？——漸進或許是個好辦法。在初始版本（單行打字機）中，邏輯是這樣的：

　　少許改進後是這樣的：

　　這種表無法表示實際顯示，但實際顯示既然是狀態的唯一函數，也不用擔心邏輯問題……雖說簡直沒有實用價值，但這麽分析至少帶給人好處。

　　（又過去一天，我要重寫代碼……）

（2018-1-9 於地球，未完）

用python實現一個命令行文本編輯器