學習 Text Editor 開發

我最近已經有點受不了這樣的狀況:

當我在 Vim 底下,打開 NERDTree 的時候,由於游標還在 NERDTree 的 window 內,所以只要我操作 :edit 或 :bnext, :bprev 指令時,檔案就會被 Vim 在 NERDTree 的 window 內打開它所屬的 buffer,而非我預期的「編輯區」window 裡。

於是我必須把 NERDTree 的 window 關掉,而且得用 :q 指令,因為在當下這 window 的 buffer 已非 NERDTree,所以熱鍵對應的 :NERDTreeToggle 指令只會再分割出一個新的 window 來叫出 NERDTree。

成也 Vim 的彈性,敗也 Vim 的彈性,Vim 沒有「側欄」、「編輯區」的概念,而我想要的只是一個單純的檔案管理員而已。

轉頭望去,用 Sublime Text 的快樂同事們沒這個困擾,遑論 App 組的同事用全功能的 IDE (XCode, Eclipse) 搞定「真正基於專案 context 的 auto-complete」與「即時檢查程式問題」。

而我還堪自誇的也只剩下「就算 SSH 到遠端也能看似輕鬆寫意」、「看起來好像很 geek 的虛榮」。

但是,遠端作業通常也只是維護機器設定檔當中關鍵的寥寥幾行,Vim 熟手宣稱的高生產力在這裡佔不了多少優勢。符合「一般需求」的 Pico, Nano, Joe 等「簡易型」編輯器就夠用了。

前幾天試用了 Visual Studio CodeAtom,以及再讀一次王垠的〈怎样尊重一个程序员〉,更讓我覺得,我長期這樣折騰自己究竟是為什麼?而且我還是一個使用傳統上下左右鍵,根本沒習慣 hjkl 過的 Vim 使用者,日常工作用的那幾個按鍵也沒發揮過人的高效率。

簡單說,就是裝逼而已,根本就是個空心大老倌。

我還深深反省了,之前某新進同事問我們 Rails 開發是用什麼 IDE,我為此輕蔑不屑地想:「科科,又是一個沒 IDE 就不會做事的」。但是若仔細想想,如果我們的 Rails 開發,可以用個幫我們提供「真正基於專案 context 的 auto-complete」與「即時檢查程式問題」的 IDE,那之前有多少低級錯誤,其實是可以避免的?

於是,除了尋覓一個更適合我的編輯器或 IDE,我開始翻起 [The Craft of Text Editing] 這本電子書,並對照幾個編輯器專案,去驗證書中所說的開發概念與方法:

(我挑這幾個「使用比較現代的系統程式語言 (Go, Rust)」實作的編輯器,是想要摸蜆仔兼洗褲、看看別人是怎樣運用這些新語言的。)

一開始讀到這本書的 1.1 User Categories 時,介紹 Neophyte 型使用者那段,就讓我深切反省,自己在做產品時,對 UX/UI 的投入還是遠遠不夠的,甚至悖離了「應該是你要去適應與滿足用戶,而不是挑用戶」的原則與初心。

CC BY-SA 4.0 This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

387 thoughts on “學習 Text Editor 開發

  1. 用 :edit 主要是為了編輯新檔案。

    目前這個問題我是設定 Vim 當前游標所在行反白提示,這樣至少我在視覺上能察覺到我的游標是否停在 NERDTree 內。

Leave a Reply

Your email address will not be published. Required fields are marked *