2016年11月2日 星期三

閒聊:使用 Vim 編輯器的第五年


哼哼,都用 Vim 那麼久惹
寫個 Plugin 來說嘴也只是剛好而已 XDDD




記得前陣子才寫了一篇「心得:使用 Vim 編輯器的第一年
結果一覺醒來又過了四年 Orz

仔細想想,這幾年我其實沒什麼長進 ...
到了最近半年,我才覺得自己對 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

將來可能也不會成為(吧?)



有空可以學個 VimScript 看看

如果你下一個十年還打算用 Vim 改點程式
那麼我認為花一個月的閒暇時間,有空就看一點笨方法學 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 有跟自己初學的時候比較不一樣的觀點
我現在的看法如下:


  • 套件不是裝越多越好
    • 被遺忘的套件就等於沒有用
    • 但我也沒有嚴格到沒用到的就全刪,建議不妨設一個「觀察區」來管理新加入的套件吧!
  • 快捷鍵要小心且用心設定
    • 同上,忘記用的就等於沒有用
    • 更糟糕的是,既有的設定會排擠未來能使用的快捷鍵組合,所以真的要小心設定
    • 設定的要點在於:「增加容易記憶的程度」與「提高敲擊上的便利性」。舉例來講,我一律使用相當好敲到的 <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 演講(咦)
下一篇心得文十年後見!😉



1 則留言:

  1. Joe.Dev 的 Loser 部落格: 閒聊:使用 Vim 編輯器的第五年 >>>>> Download Now

    >>>>> Download Full

    Joe.Dev 的 Loser 部落格: 閒聊:使用 Vim 編輯器的第五年 >>>>> Download LINK

    >>>>> Download Now

    Joe.Dev 的 Loser 部落格: 閒聊:使用 Vim 編輯器的第五年 >>>>> Download Full

    >>>>> Download LINK

    回覆刪除