相信不少人最早接觸Vim，都是因為使用Git的時候出現Merge Conflict會突然進入Vim的編輯器裡，這時候大家如果不熟就會不知道怎麼離開Vim，於是就開始被迫要理解一些Vim的操作。一開始筆者也是差不多這個路線，平常就是使用 Git或者修改遠端機器上的一些設定檔時會使用到Vim。
多少透過自學知道Vim的命令，但就只是零碎的使用命令，不了解為何h, j, k, 'l'左下右上的移動。也不知道為何Vim的模式被這樣設計。
到後面是為了深入研究編輯器的操作，所以請教了公司裡的後端工程師Ryan大大，他習慣使用Vim和VSCodeVim。
第一次請教了在VSCode裡使用Vim的觀念與技巧以後，筆者開始練習《Vim CheatSheet》的各種用法。使用過一會之後，發現不見得可以在VSCodeVim裡使用出CheatSheet上的幾個操作，於是再請問了一兩次，大概把一些VSCodeVim上的指令掌握。之後，筆者主要就以CheatSheet和《Boost Your Coding Fu With Visual Studio Code and Vim》作為主要的學習資源。
這個時候的觀念還並沒有被真正建立，但VSCodeVim是一個你隨時可以離開Vim Mode的Extension，所以在動手操作時，如果太卡，還是可以先切回原本的VS Code裡操作，無形中減少了許多轉換工具的成本。
之後，為了進一步掌握VSCodeVim，筆者挑選了一些市面的相關書籍，最後找到了《Practical Vim, Second Edition: Edit Text at the Speed of Thought》這本經典好書，後面也實際購買書籍支援作者。
書裡之後介紹了使用各模式轉換的觀念，讓筆者一開始就掌握了學習Vim所需的基本觀念。
另外很重要的是，它在前言裡一開始就跟讀者們講解了學會「盲打」（Touch Typing)的重要性，雖然沒有介紹如何盲打，但已經讓筆者有了方向，知道應該往何處尋找資源掌握這們技術。
Touch Typing讓我熟悉並且對於一些基本的Vim中的h、j、k、l操作感到親切，熟悉後使用的非常自然。
雖然後面也看到一些網路上前輩分享使用底下的鍵位圖學習並熟悉Vim。
但筆者自己的經驗是熟悉盲打以後，鍵盤的英文位置已經爛熟於胸。看不看這張圖差異其實不大。遇到有操作就看《Vim CheatSheet》或相關網站熟悉命令即可。
在自行找資源補齊了相關的基本知識後，筆者發現但仍有一些跟Vim重要部分是空白的，與實際在VS Code使用上的一些難點
這些問題並未從外部資源直接得到解答，還沒有一本書可以解答相關的問題，於是筆者開始嘗試去探索相關議題。
後面，筆者開始接觸一些VSCodeVim的使用者，也到官方群組幫忙回答問題，順便觀察一下Extension社群的生態，可以把一些好的部分分享給讀者。
結果實際上讓筆者很失望，大部分的使用者會想解決自己的問題，並沒有深入Extension是怎麼運作的，在社區參與上的貢獻與交流也比較少(相比筆者在國外看到的一些社群的活躍狀況)。真正的社群回答問題、貢獻程式碼的，還是少數人。因為VSCodeVim是一個非常多人使用的工具，文件已經非常豐富，每隔一段時間就有高手幫忙貢獻一些程式、解決一些問題，所以許多使用者可能並沒有意識到這點。
國內的社群筆者疫情底下參與的社群數量不多，但走過，遇到有Feedback可能是提議筆者說，這個東西可能有需求，你可以往這個方向做這個工具，或是遇到現成問題就抱怨、評價工具不好的人。多數人都在使用現成的工具，不關心相關議題。
實際上，一些筆者覺得應該可以很早被解決的Issue，沒有太多人提出來，或動手解決。
以VSCodeVim在settings.json中的鍵位對應為例，讀者們知道在VSCodeVim v1.23中，我們是沒有辦法使用或這兩個Key Notation綁定「Ctrl+s」與「Ctrl+z」這兩個快捷鍵的嗎？
這是在Vim的環境可以做到，也很常見的一個需求啊（Ctrl+z有網友提議說可以新增這個Key notation，但Ctrl+s一直都沒有）。大部分的讀者可能就會在這裡綁定、發現設定沒有生效，之後疑惑這樣做到底對不對，最後可能使用繞路的方式在keybindings.json中定義對應的快捷鍵，但不會比較方便。
新增這兩個快捷鍵的Key Notation一點也不難，筆者提了相關PR，確定可以在VSCodeVim v0.1.24中使用。另外在寫書的期間，筆者考察了Vimrc的使用方法，整理出穩定可用的部分介紹。後面發現有兩、三個相關問題，也提出PR解決，不過此點讀者並不會知道這點，因為書裡並沒有特別寫到這一部分。
總之，這些我們可能覺得理所當然應該要有的東西，從來都不是自然地出現的。
至於，開源專案的開發者、維護者知道這些嗎？就我自己的觀察，我認為有人知道，而且他們動個手就可以解決了，只是他們沒有什麼理由幫使用者做到這些事。開源的工具是需要使用者加入、feedback才會成長的，讓專案變好從來就不是一個人的事情。
當時一些PR是在寫書期間提出的，開源專案Pull Request等待的時間許多都很漫長。為了確定哪些功能確定可用，筆者承受了時程壓力(有寫書的人應該更能體會這點)，也感受到現實。
總之，筆者後面一邊探索的工具可以處理到哪個程度，探索時間成本是相當高的。
也可能是為了一些熱情，筆者嘗試讓不同作業系統的一些快捷鍵跟鍵位的配製方法，Windows和MacOS都有，期間為了Windows的一些配置無法跟MacOS上一樣順利設定感到費神。後面有和一些使用者接觸，但時間成本昂貴。雖然後面總算對齊了Windows跟MacOS上的一些設定，但也因此花了不少時間。原本計畫探討下Linux的環境的快捷鍵設定的，在前面為兩個作業系統消耗了不少時間後，筆者花了一天處理Linux上的環境，因為相關進度的書稿落後了被編輯責備，Linux的設定方便就再也無法探討了。
至於否入花費Vim的時間是否真的值得呢？單看金錢，遠遠不夠。寫書的稿費是比不上筆者一個月的薪水的。
寫書會讓作者處在一種類似長期加班的狀況，但工程師作者是沒有辦法因此領以勞基法而言要比正常工時還高的時間或加班費的。
在寫書跟探索相關問題時，一直感覺有一堵堵牆在前頭。但在越過後面這道牆翻躍過去解決相關問題後，回頭一看，並沒有人幫助自己解決相關的技術問題。牆壁依然在那頭，只是自己跳的過去了。
跳過去以後，回過頭看到一些群組裡使用者過去抱怨的問題，自己都有解法。不過沒有什麼情境或理由讓筆者多花時間談論、改變這些人對工具的印象，每個人平常也都有自己要做的事情。
當時會去寫書的動機有多種，筆者自己也喜歡挑書、買書跟看書，所以也會挑書，嘗試自己寫一本書看看。
說實在，過程中比自己想得費功夫多的多，有很多排版、校對、格式轉換、大陸用語之類的問題要處理。但如果選初學者可以自學起來的題目，卻又不會給筆者帶來太多下筆的動力。因此選擇了介紹靠自學難以學會的技術，並介紹一些思想、觀念還有一些獨創的內容。
事後來看，就以鐵人賽的系列書來講，如果要賣得好，寫給初學者的系列，其實就夠了。一本書畢竟也只有幾百塊，所以如果是為了銷量，讓書賣得好的一個重點其實是行銷與曝光。
回頭看，寫這類書或做這類教學，到底值不值得呢？
說實在，只有其中一個讀者能從書籍或相關文章中因此自我學習、有所啟發，進而改善現在的環境，對作者來說才能說可能比較值得。
真正會去改變環境的人，也許100人中也只有一個。書再多賣100本，對作者的收入來講其實增加有限。但只要出版書有其中一本或多本被放到圖書館去，就有機會有更多人閱讀。或許有一個人有些點子想法或思維，因此被啟發，那是能夠有更大的影響的，雖然筆者不知道這些正向的影響會不會回到自己身上。
缺乏咖啡因的韋恩
iThome鐵人賽
看影片追技術