 |
哼哼，都用 Vim 那麼久惹
寫個 Plugin 來說嘴也只是剛好而已 XDDD
|
結果一覺醒來又過了四年 Orz
仔細想想，這幾年我其實沒什麼長進 ...
到了最近半年，我才覺得自己對 Vim 的掌握真的有變多一點
也難怪會想提筆碎碎念一下
#本文純粹就是閒聊 #沒什麼組織 #想到什麼寫什麼
到了最近半年，我才覺得自己對 Vim 的掌握真的有變多一點
也難怪會想提筆碎碎念一下
#本文純粹就是閒聊 #沒什麼組織 #想到什麼寫什麼
前情提要
對，我仍然還是一個用 ijkl 做移動的 Vimer ，而且活得好好的
我仍然用 ;; 離開 insert mode
我仍然還是裝一大堆 plugins
我仍然還是以 Vim 作為主要的程式碼編輯器
我仍然還是同事裡的少數派
我仍然還是同事裡的少數派
我仍然每隔一陣子就覺得自己已經覺會了 Vim 大部分的指令 😏
然後下一秒會在 Vim Tips Wiki 查到整頁都沒看過的指令來解決我日常生活會遇到的問題
是的，我已經習以為常了
說到使用 Plugin 這件事情
儘管 Vundle 沒什麼不好，我還是衝著能平行化安裝 or 更新套件這點，跳槽到 Plug
Plug 支援使用一些 lazy loading 的寫法，可以減緩一下安裝太多套件的 overhead
但是事實上，主要會拖累速度的 plugin 就那幾隻
一般的套件幾乎不會佔用多少載入時間
而套件本身如果架構上有採用 lazy loading 的設計，更加不需要用 Plug 的 hook 再加一層
近期改變我使用習慣最大的套件，大概就是渾身充滿暗黑力量的 Shougo 所寫的 Unite
讓我戒掉了 minibufexplorer ，改用搜尋的方式在數十個 buffers 中切換
同時，我透過各種 unite source 來解決找檔案、剪貼簿管理、Mark 之間跳耀 ... 等等問題
好吧，我承認我其實沒有完全戒掉 minibufexplorer 帶來的體驗
我使用 vim-airline 並且開啟下列參數
let g:airline#extensions#tabline#enabled=1 let g:airline#extensions#tabline#buffer_idx_mode=1 nmap <space>1 <plug>AirlineSelectTab1 " ... nmap <space>9 <plug>AirlineSelectTab9 nmap <space>j <plug>AirlineSelectPrevTab nmap <space>l <plug>AirlineSelectNextTab
對，我是個拿空白鍵來當作第二 leader key 的魯蛇
值得一提的是， Unite 近期已經停止功能的開發
等作者用 Python3 寫的 Denite 功能更佳完善後，我應該會遷移過去
如果只能再提幾個套件（因為懶），那我會提這三個：
- YouCompleteMe
- 很好很強大，不提到這個彷彿沒用過程式碼補齊一般 ...
- 啟動時會吃個 0.x 人類可感的秒數，之後不知道會不會好一點
- :YcmCompleter GoTo 是一個很容易被忽略的好用指令！
- EasyMotion
- 移動神器，就算你已經安裝了，還是值得再看一下他最新的文件
- 目前主要負責開發的作者 haya14busa 大約三年前才摸 Vim，而且最近還手滑送了四個 patches 給 Vim 不小心也成為 Vim 的 Contributor，堪稱 Vim 生勝利組（咦？）
- 目前我已經把 w 改成直接呼叫
nmap w <Plug>(easymotion-bd-w) - Tagbar
- 看扣都會用到，雖然有點拖累畫面速度，希望之後改版速度會變好
- 會特別提到是因為他的使用率實在太高，以及跟我手邊自己寫的另一個還沒釋出的套件在 updatetime 上有點相衝 Orz
- 希望大家多貢獻開源專案，把 Tagbar 改好啊 XD
最後，對於使用套件這件事情，我想說的是
顯然地，目前我還是沒有成為那一個傳說中 ...
使用 Vim 滿 N 年就返璞歸真把套件砍光的神人 ... 囧rz
使用 Vim 滿 N 年就返璞歸真把套件砍光的神人 ... 囧rz
將來可能也不會成為（吧？）
有空可以學個 VimScript 看看
如果你下一個十年還打算用 Vim 改點程式
那麼我認為花一個月的閒暇時間，有空就看一點笨方法學 VimScript
來學一下可愛又惱人的 VimScript 是很划算的
這麼做的好處有：
那麼我認為花一個月的閒暇時間，有空就看一點笨方法學 VimScript
來學一下可愛又惱人的 VimScript 是很划算的
這麼做的好處有：
- 邊學可以邊整理一下自己的 .vimrc
- 可以比較看懂自己的 .vimrc
- 我相信大多數的人的 .vimrc 多少都會有一些自己也看不懂的咒語
- 累積足夠的 Vim 知識去解決打開 Vim 時出現的惱人錯誤之類的 ...
- 可以順便達成你總是沒達成的年度計畫「一年學一個語言」
VimScript 有許多 function 都很有 Python 的味道
儘管如此，但還是不得不說，這個語言的行為非常的神妙啊（笑）
除了增加自動化一些事情的能力以外
其實，學 VimScript 的最大收穫是了解編輯器如何運作的概念模型
這使得在使用 Vim 及套件上，會有更加清楚的認識
也同時能帶來一些有趣的想像
寫一個 Plugin 玩玩
前陣子我看完笨方法學 VimScript 以後
我就帶著我的想像來寫了我自己的第一個套件：vim-codequery
簡單版 的故事我已經在 Taipei.py 分享過
完整版 的故事我也在 Tainan.py 分享過
要問我寫這個有什麼收穫
除了做出自己想要的東西的成就感以外，大概就是「了解更多」這四個字
要寫自己的套件前總是得看看範例，所以就跑去看看其他套件是怎麼實作的
當更認真的看其他人的套件時，才會真的了解他們在幹嘛
並領略他人程式碼的美妙（與不美妙）之處
同時，在認真向外看的時候，才會知道一些一般 User 不知道但是對套件開發者很重要的消息
例如，前陣子我才知道 Vim8 有哪些厲害的 features ，以及與 NeoVim 的 Async 愛恨情仇
自己進行比較大量的實作時，我才從學語言的狀態，前進為應用語言的狀態
雷還是要踩一踩，程式碼還是要打個上百上千行才會逐漸深刻 Orz
我就帶著我的想像來寫了我自己的第一個套件：vim-codequery
簡單版 的故事我已經在 Taipei.py 分享過
完整版 的故事我也在 Tainan.py 分享過
要問我寫這個有什麼收穫
除了做出自己想要的東西的成就感以外，大概就是「了解更多」這四個字
要寫自己的套件前總是得看看範例，所以就跑去看看其他套件是怎麼實作的
當更認真的看其他人的套件時，才會真的了解他們在幹嘛
並領略他人程式碼的美妙（與不美妙）之處
同時，在認真向外看的時候，才會知道一些一般 User 不知道但是對套件開發者很重要的消息
例如，前陣子我才知道 Vim8 有哪些厲害的 features ，以及與 NeoVim 的 Async 愛恨情仇
自己進行比較大量的實作時，我才從學語言的狀態，前進為應用語言的狀態
雷還是要踩一踩，程式碼還是要打個上百上千行才會逐漸深刻 Orz
轉換觀點
幾年前我開始讀諾曼先生的設計心理學相關書籍，近期則花了不少時間研究跟寫套件開始對於 Vim 有跟自己初學的時候比較不一樣的觀點
我現在的看法如下：
- 套件不是裝越多越好
- 被遺忘的套件就等於沒有用
- 但我也沒有嚴格到沒用到的就全刪，建議不妨設一個「觀察區」來管理新加入的套件吧！
- 快捷鍵要小心且用心設定
- 同上，忘記用的就等於沒有用
- 更糟糕的是，既有的設定會排擠未來能使用的快捷鍵組合，所以真的要小心設定
- 設定的要點在於：「增加容易記憶的程度」與「提高敲擊上的便利性」。舉例來講，我一律使用相當好敲到的 <space> 加上其他鍵來進行頁面相關的移動，這使得大腦以及肌肉記憶的負擔降到最低。
- 用滑鼠不會死
- 打開讓滑鼠捲動生效的選項其實也沒什麼不好，有時候進入輕鬆瀏覽模式時，看扣的心智負擔反而比較小
- 跟同事 Code Review 或是一起看 Code 的時候，至少對方還可以用滑鼠移動 XD
- 用上上上上上下下下下移動也不會死
- 認真！非反串 👻
- 重點是其實是當一個人在做這件事情的「心智狀態」，當你在做這件事情的時候，目的是要進行移動呢？還是只是一邊看 Code 一邊移動，而把游標當做一個「視覺提示」來使用呢？還是其實你只是想要移動到螢幕兩端進行進行捲動？
- 合理而有效率地達成你真正的目的，才是重點！
- 不用因為按了上上上上下下下下而感到羞恥，重點是認清你自己在幹嘛！
- 千萬記得要把鍵盤的連續輸入速度調高，不然我會為被你浪費掉的時間感到羞恥 Orz
- 我自己的做法是把上下改為維持游標位置但是上下捲動一格，所以要看上面或下面一點的程式碼都很方便。有 Code 有真相：（以下程式碼不負任何維護責任）
" 用 i,k,j,l 進行上下左右移動 nnoremap k gj nnoremap i gk nnoremap j h function! s:move_up_and_down() if line("$") > winheight('%') nnoremap <buffer> k gj<C-E> nnoremap <buffer> i gk<C-Y> endif endfunction augroup MoveGroup autocmd! autocmd BufEnter * :call s:move_up_and_down() augroup END - 背景主題也有重要性
- 對！這關係到可讀性與情感上用得爽不爽，所以調整好用色、字體、間距及版面是有必要的
- 我會喜歡開 Tagbar 有一個原因就是可以把程式碼區塊往右靠一些，眼睛的重心可移到比較接近螢幕中間的部分
- 有時候我甚至會用 :Goyo （或 vimroom）之類的套件來讓畫面只顯示必要的程式碼
- 回饋很重要
- 為什麼很多人覺得手邊的編輯器用起來很爽快？因為強者我朋友就是你只要快速甩幾個按鈕，Vim 就會串起一堆指令，然後把事情做好。達成你的目的這一件事情，就是編輯器給你的一個回饋
- 然而，「如何達成的」這一件事情也頗重要，這往往是一個會讓人覺得這個東西好不好用的原因。例如，許多人會用 Ack.vim 之類的套件來取代 vimgrep，而當搜索時，畫面會一閃，block 住並且進入搜尋畫面，一個一個印出找到的資料，結束後畫面又會重新 render 出來並且將結果顯示在 quickfix 內。在剛剛的例子裡，假設總共花了 0.8 秒，那麼時間的回饋就是 0.8 秒，而「一閃」、「block」、「重新 render」、「顯示結果在 quickfix」也都是各種視覺或操作回饋，都會對使用者造成一些影響
- 因此，在製作套件時並不一定只是採用最新的技術就可以達到最好的效果。例如，剛剛的 Ack.vim 假設直接套用了 Vim8 最新的 Async 功能而不做回饋的調整，那麼就可能會變成這樣：發出搜尋的指令，什麼事情都沒有發生，0.8 秒後突然跳出了一個 quickfix 出現了搜尋結果。這是一個由於回饋不足，使得行為有點出乎使用者意料的情況，而使用者就可能會覺得這個套件怪怪的
- 在對回饋機制有更多了解以後，就更加能夠「了解」一個編輯器/套件的優劣與否，甚至有比較高的機會做出好用的東西
- 讓 Vim 擁有 IDE 般的功能也沒什麼不好
- 別緊張，我並不是贊成要把 Vim 變成 Visual Studio，然而，如果 VS 有好用的功能能夠有效增加生產力，那麼為什麼不用某種形式讓他能夠在 Vim 上面實現呢？
- 當有人在說「Vim 並不是 IDE 時」，其實往往是在指「用了不那麼 Vim 的方法做事情」或是「這不是 Vim 原生該支援的功能」（沒說出來的是：「但是套件可以支援」）
- 從我的角度來看，Vim 是一個 UI 受限，但是彈性無窮的編輯器。要讓他變得如同受歡迎的 IDE 一樣強大（或更強大），我是雙手贊成的。然而，根據 The Law of Leaky Abstraction，顯而易見的是，我們得懂更多。
然後咧
其實也沒有然後了，就只是一篇五年的心得文 XD
要我再說幾句話廢話的話，大概就是：
要我再說幾句話廢話的話，大概就是：
- 請愛用 :help ooxx 閱讀 Vim 的文件，我超後悔到了今年才比較有用讀文件的習慣
- Vim8 Async 功能對於整個套件系統的影響，可能要半年一年後才會發酵，敬請期待
- 話說這個年代 VimScript 都開始有 Lambda 支援 Closure 是哪招 XDDD
- 如果想要看看大神是怎麼用 Vim 的，除了到 Github 看 dot files 以外，我強烈推薦 howivim 這個網站，裡面有許多很有意思的訪談，能夠聽到一些知名的作者的看法，對於開拓自己的想法非常有幫助
- 最後 Vim8 與 NeoVim 該怎麼辦？我也不知道 T_T
以上，歡迎試用 vim-codequery 或向我報名 Tainan.py 演講（咦）
下一篇心得文十年後見！😉
