在寫一本書或課程時,你需要處理成百上千的字而Vim能夠幫助你有效地管理這些內容.
當我就快要完成我正在忙的一門課程時，我會嘗試想出方法來改善我的工作流為了能更容易地創建下一個課程。
這意味著要評價從音頻和視頻硬件到代碼編輯器甚至操作系統的幾乎所有東西。
這篇文章專注於大量文本的組織和處理．這可適用於書籍，課程，筆記或者實際上可以是任何東西。
過去的兩週在Windows 的 Linux 子系統中配合使用了終端 Vim+tumux 之後，我已經比之前的 VSCode 配置更有生產力了。
tmux 對於任何想要玩轉多個項目的用戶尤其有用。我總是在自由作家與開發工作，博客，開源項目，業餘項目，課程間不停轉換。能夠點擊一個tmux熱鍵翻到任何一個給定的項目並讓所有的東西都立即被加載和準備好開始工作是非常棒的。
我之前是通過 tmux 和 VSCode 來完成工作，但是打開並將 VSCode 移動到正確的尺寸總是需要我去手動完成。
那也許聽起來很平凡，但是實際上並不是。每次你做的時候，它會將你置於一個負面情緒中，你會想"唉，現在我必須要手動再組織一遍"。
對於 Windows 來說最大的缺點就是，要去管理窗口 (windows) 佈局是非常冗雜的，有趣的是這個操作系統居然也被稱為 Windows。自從我在 Linux 上嘗試過使用 i3 作為窗口管理器以後，我就再也不能夠回到其它任何工具上了。
因此，在過去的幾周裡我一邊為我的課程寫作一邊尋找能夠在 Windows 中儘可能複製 i3 的方法，我發現在 WSL 中使用終端 Vim 和 tmux 使得我接近於可以在一個終端中做任何事情。
為此那也是我選擇嘗試 Vim 的一個主要原因。其並不一定是由於 VSCode 作為一個編輯器太過於侷限，儘管在考慮改善我的課程創作工作流後我最終發現它的確是不合適的。
創作課程會涉及到什麼?
它是一個可以與寫一本書相比的幾個月的投入，而且還會有額外的複雜度，因為你不僅僅要寫下人們將要讀的內容。
例如，對於一本書，你需要有一個目錄，章節以及屬於每個章節的內容。你可以以任何你喜歡的格式來寫作一本書並在你將完成時將其導出為PDF格式。你僅僅需要關心PDF是什麼樣的。
一個課程與其很相似。 它有一個目錄，小節和課程內容。小節只是一個組織課程內容的方式，而課程內容是你計劃在視頻上發表的內容的文本手稿。
例如，我當前忙於的課程具有24個小節以及158個課程內容。每個課程內容具有大約2000個字。粗略算共有300000個字的文本而這門課程還沒有完成。
每個課程內容最後都將被轉換為介於2到20分鐘長的視頻，具體時間實際上取決於該門課程字數的多少。
因此，現在讓我們來談一些我在組織課程內容時遇到過的一些問題。
下面的所有問題都是我在開始使用Vim之前的情況下遇到的的問題，而在最後我將重溫我如何使用Vim來處理它們。
處理文件名
當時我針對這些問題的解決方式是為一個特定的課程創建一個 scripts文件夾並在那個文件夾內為每一個小節創建一個單獨的文件夾，在小節文件夾內每一個課程都有其獨立的文件。
它看起來像這樣:
換句話說，我用一個數字對每個小節的課程內容進行排序，而對於每一個小節課程內容號碼不會進行清零。它會從1開始編號，一直到最後一個課程內容。
有趣的是，我還有一個含有被編號的文件夾且能與特定的課程內容匹配的單獨的git倉庫。真正重要的是課程內容編號和git倉庫文件夾編號最後會在一起編號。
但是，正如你可能已經發現，這個方式對於你需要在課程中途添加一個課程內容的情形來說是非常糟糕的。想象一下你在編號50後需要加入一個編號為51的課程。這意味著你需要為新添的51號後的所有課程內容編號手動增加1，而這是非常糟糕的。
關於這一點，要去預先為一個課程想出最終的目錄編排幾乎是不可能的，因為你不大可能去提前預測所有的課程內容。
我需要編寫腳本並且在過程中使用它。我甚至可能寫作完成後才想出課程內容的名稱，而且由於視頻的時長非常重要，課程內容的字數實際上決定了什麼時候一個課程內容需要分割為下一個課程。
現在為了與該問題進行鬥爭，我所做的就是為每個小節創建一個文件，併為該小節寫出所有的課程內容腳本，而在我很高興時才會將其分解為手動編號的文件。
那是我現在的處理方式。我會手動對它們進行編號並試圖減少在之後不得不添入課程內容的可能性。如果我不得不添入(這在這個課程中目前發生了兩次)，我就像吞下一個子彈一樣感到急躁，然後還是得手動重命名所有的東西。
這種方式的另一個痛點是，如果我想要改變一個課程內容名稱，我需要進入文件系統並手動改變文件名。這似乎看起來是一個小事情，但是它會為寫作過程添加阻力。它真的會！
最後，有一個規則是，我總是要確保一個課程內容很漂亮的過渡到下一個課程內容，因此如果我正工作於課程內容5，我通常會打開課程內容4，滑到文件的底部，閱讀我過去寫的內容來確保我以一個自然過渡的方式開啟課程內容5。這會涉及到許多在文件之間的跳躍。
利用我現有的工具解決這些問題的潛在的方法
我嘗試不對課程內容進行編號而是準備好一個分開的YAML目錄。那麼我就可以編寫一個小的Python腳本來讀入該目錄文件並在課程完成後以編程的方式為小節和課程編號。
我確認那能夠工作，但是現在我需要保存一個與實際文件同步的單獨的目錄文件。處理文件名字本身就足夠煩人了而這個解決方案並沒有真正解決它。它就像在火上澆油一樣。
然而值得提到的是，不像一本書，一個課程不僅僅是一個單獨的導出的PDF文件。我想要人們能夠在我的網站中進入課程，這意味著需要在課程平臺後端創建一個目錄。
最終要與其交互的是人類，而不僅僅是這些腳本文件，因此實際上在我的開發盒子裡面的這些小節文件夾和課程內容文件是沒必要存在的。它們的存在僅僅是為了我能夠在一個git倉庫中將它們與文件夾編號關聯在一起。
完美世界中的理想解決方案
如果我不需要考慮小節和課程內容在代碼編輯器中出現的順序外的排序將會非常棒。
基本上，如果我有一個如下的課程內容列表:
Welcome
Downloading the Starter Files
Tooling Setup
我僅僅想要以一個人類可讀的方式來處理課程內容名字而不是去處理數字。如果我想要重命名一個課程內容，它僅僅在那個部位被重命名，而如果我想要將一個課程內容往下移，我僅需要進行下移而課程內容號會同時被自動更新。
關於這一點，如果在某處中間添加一個課程內容，所有其後的其它課程內容將會使他們的編碼自動調整。這對於節編碼同樣適用。但是記住，課程內容編碼將會在所有小節中進行檢索。每個小節都會有起自己的單獨的課程內容檢索。
我也不願意去手動處理創建 tooling-setup.txt文件。
另一個重要的事情是課程內容的分離。如果我點擊進入或者展開Tooling Setup課程，我僅僅想要看見該課程內容的文本，但同時，為了能夠快速查看它們如何開始和結束，我有時也許想要查看之前或者下一個課程內容的文本。
實際上，不僅僅只有課程內容的分離可以幫助我保持專注。能夠跳躍到課程內容的開頭，中部或者尾部並不將其應用於整個小節或者課程也是非常棒的。尤其是在搜索文本時。
但是關於那一點，有時能夠在整個課程文本上進行操作是超級便利的。例如，我能夠搜尋像"for example"這樣的短語來看我說過它多少次，並嘗試使用可替代的其它詞來使得它聽起來不過於系統化。
事實上我不會在發佈視頻的時候逐字地讀這些腳本。他們主要是為了幫助我組織我的思緒，但是我的確需要在錄製視頻時用它們作為指導。
用Vim解決這個問題
我是在我知道我將要使用什麼編輯器和工具前寫下的上面的理想的解決方案。我認為這不僅是一個很棒的發現問題是什麼的方法，也是一個如何解決它的方式。
我僅有的曾閱讀過的技術書籍是SICP(Structure and Interpretation of Computer Programs)。在該書中他們談論了一個叫做"wishful thinking"的概念。
在書的內容中，他們談論了在假設已經有特定的庫或者函數存在的情況下設計你自己的軟件的場景。這使得你能夠專注於設計你的應用的API並在之後填入細節。
那是我這裡所做的，但是是一個不同的場景。
創建一個巨大的300000字的文件:
我開始參考我的理想解決方案並考慮這個問題。總的來說，問題的一個大的部分是關於處理單獨的文件名字。
所以為什麼不首先消除文件並使用一個大文件呢?
我沒有一個巨大的文件來對其進行測試，但是隻需要幾秒鐘就可以基於我已有的文件來創建一個。我只需要在WSL中打開一個Bash命令提示符並運行cat */*.txt > all.md。
現在我有一個300000字的markdown文件，其大小大約是1.5MB。我決定嘗試用我現有的VSCode設置和Vim來打開它。在兩種情形下我都保證啟用插件且兩個編輯器都有處理markdown的插件。
令人足夠吃驚的是VSCode非常快地打開了文件。其只花了3秒，而且往文件中輸入時就像在一個小文件中輸入一樣快。
然而，僅僅在沒有做任何事情的情況下，打開文件就佔用了我的3.2GHZ四核i5 CPU的50%，並且在輸入的時候跳躍到了65%.
這並不能解決問題。這是一個我將要在幾個月內每天都要打開的文件。它不能佔據我的整個CPU資源。同時，它也使用了800MB的RAM，雖然坦白地說由於我有16GB的RAM我並不介意那個。
因此我在Vim中打開了同樣的文件。Vim花了大約一樣的時間來打開文件，但是它使用了少於10MB的RAM以及在打開時佔用0%的額外的CPU，在文件中部輸入時額外的CPU佔用僅僅跳至3-4%。
我感到就像我在一個更小的文件中進行輸入一樣輕快。它甚至會處理輸入 ** 來開始使用markdown加粗文本並且是即時的，甚至它在對300000個字進行加粗時也是這樣。
那是一個我能夠尋求的更好的結果，尤其是當Vim是直接在被認為是非常慢的WSL中直接運行。我認為在原生Linux系統上其肯定會運行地更快。
設置一個顯示的最差的情景:
如果我有一個900000字的文件會怎麼樣? 實際上在我一個課程中有500000個字是不大可能的，但是我認為看看會發生什麼是一個好主意。
900000個字Vim花了10秒來打開，但是一旦完成後，就像操作只有300000個字的文件一樣棒。在進出插入模式間大約有半秒的延遲，但那是僅有的差異。RAM和CPU佔用幾乎是一樣的。
如果你很好奇，我告訴你VSCode在處理300k字的時候也會表現如此良好。在這種情況下，VSCode實際上比Vim更快地打開文件，但是，再一次地強調，這肯定是由於Vim是運行於WSL中，而VSCode是直接在Windows中運行。
在一個單獨大文件的小節和課程內容之間導航:
由於我不將使用VSCode，所以去比較它是沒有意義的，這將會專門專注於Vim。
vim-markdown 插件絕對是超級棒，並使得所有這一切都可以進行。
我是一個典型的不喜歡代碼摺疊的人，但是代碼摺疊被證明是有史以來的最好的東西對於這種方式來說，而且vim-markdown插件具有對基於markdown的標題處理摺疊的一流支持。
這意味著我能夠保證在打開文件時所有的摺疊都是關閉的，然後跳躍到某一個我想要在上面進行工作的課程內容，並在幾秒內它就展開。它工作得非常完美。
這個插件也支持使用[[和]]在標題間跳躍，因此我可以很容易地跳躍到之前的或者下一個課程內容。
Vim也意識到了如何使代碼摺疊工作，你可以僅為那些打開的摺疊執行文本搜索和操作。這給了我理想的解決方案中想要的所有的功能。因為如果我想要在整個文件上進行工作，我可以敲擊一個熱鍵來展開所有內容。
此外，還有fzf.vim插件，它可以讓你模糊搜索緩衝區中的行。它是一個極佳的用於尋找短語的選擇。嚴格地說，junegunn是一個令人吃驚的開發生產工具的作者。他製作了FZF和一些其它的工具。
為小節和課程內容編號:
vim-markdown插件碰巧也有一個手動命令叫做:Toc，它能夠為你的標題創建整個目錄。這個TOC是在一個分離的緩衝區中創建的，而且你甚至可以點擊標題來跳至markdown文件中的對應區域。
這個行為完全是我所需要的。我不需要總是知道課程內容編號。只是在我想要知道計數或者想要在Vim外將一個課程內容編號關聯到一個git文件夾號碼的時候才需要。
目前這個插件沒有支持在TOC輸出中對標題編號，因此我在GitHub上打開了一個issue。但是這個問題目前是可解決的，就是一點點進行集成的工作就可以了。
例如，我所有的小節都使用#，而我所有的課程內容都使用##，因此所有需要做的就是一個小的Bash魔法來解析這個文件。例如，你可以在文件中進行grep並取出所有的以#開始的行然後你就有了一個所有小節的列表，等等...
我還沒有想出一個完美的腳本，但是我100%確認那是可能實現的，而且那是我現在所有需要擔心的。在我完成了我當前的課程以後，也許vim-markdown的作者就將這個功能構建到他的插件了。誰知道呢!
改善大文件中的滑動速度:
在WSL中，我注意到甚至在具有100行的小文件中滑動時的相對行數更新也是非常緩慢的。我們在滑動中花了幾秒的延遲才看見光標移動。
結果是相對行數是最常被譴責的糟點，但是我並不想因此放棄。在應用了下面的設置以後，滑動再次變得迅速了，甚至是在一個具有900000字的文件中。查看一個超過100000行的文件是非常有趣的。
加速代碼摺疊:
在300000字文件中，默認的代碼摺疊是難以忍受的慢。甚至僅僅打開這個文件也使得它很難使用，但是經過一點研究後，我找到了一個可以完美地工作的插件。
添加FastFold插件到我的vimrc中立刻解決了這個問題。它從無法使用變為非常的棒。當摺疊被更新的時候它就基本上跟著變化了。
為截屏視頻添加潤色而不用編輯視頻
當我錄製的時候，我通常會使用一個非常大的字體和一個顯著的光標，因此去緊跟我正講到的內容會更加容易。但是我最近開始做的的一件事情是在錄製完視頻以後通過添加特效來強調文本。
例如，在我錄製視頻以後，在編輯階段我將經常經常使屏幕的大部分變得暗淡並突出代碼的某一個特定區域，這是為了使我正在講的內容更加清晰。
我聽到許多人說他們真的很喜歡這個效果，並且一些人說我的深入Docker課程是他們所見過的產品質量最高的課程。
然而，產品質量的提升也是有代價的。它花費了非常長的時間來遍歷視頻並手動高亮我想要高亮的區域。
碰巧的是有一個叫做limelight.vim的插件，它可以讓你實時地做這個事情。它是由創造FZF的同一個作者編寫的。
它會自動高亮你的光標所在的區域，而且你可以調整諸如顏色暗淡和不透明度等參數。因此你可以使用任何顏色主題讓它看起來非常棒。
這意味著我能夠打開灰光燈，並且不需要在後期產品編輯中手動添加暗淡和高亮屏幕。只是這個功能就能夠省下幾個小時。目前VSCode沒有提供類似的功能，但是我認為這是可以被完成的。我知道它有一個Emacs的接口。
我將會在我錄製下一個課程的時候嘗試一下它。
最後，我真的非常高興給了Vim第二個機會。我很久以前忽視了它，但是現在它成為了我用於寫代碼和創建課程的工具鏈中最重要的工具。期待將來能有更多的Vim帖子產生。
英文原文：https://nickjanetakis.com/blog/vim-is-saving-me-hours-of-work-when-writing-books-and-courses
譯者：青蒿素