接續前一篇。
Mike 在 SPDX License List 這邊提出的問題則是，為什麼會有 Vim 要替換，但是 Vim Maintainer 不要替換這樣特別的情形，所以我就是認真的解釋，並且說明這是跟原作者 Bram 確認過的細節並附上討論，還有舉我前面提過那個最極端的例子，然後我猜最重要的是現實世界有沒有人這樣使用過，還好我還真的找到幾個專案有認真的把條款內的 Vim 替換掉（當然是連 Vim Maintainer 也換掉了），像是 Tagbar；我的 PR 是 2019/07/11 提的，然後一直來回到 9/25 回了最後一個回應之後就沒人回我了，之後到了 10/19 就突然被合併了（其實 SPDX 有定期的會議，應該是在其中有討論過要不要合併這個 PR 吧），接著等到 2020 一月我發了 PR 到 choosealicense 把 vim.txt 加進去，這次就蠻順利就合併了。
閱讀「Vim License 的故事（下）」全文
這篇是我去年 COSCUP 分享的文字版，拖稿許久終於寫出來了，以下正文開始。
Open Source Software 一直是 GitHub 的心頭肉(?)，也因此 GitHub 一直都有在各方面協助 OSS 開發者，其中也包括了對 Open Source License（開源授權）相關的協助。在 2013 年，GitHub 發佈了一個小網站 叫 choosealicense.com，用簡單的條列介紹各開源授權條款的特色，並且藉由一些問答互動來幫助開發者挑選開源軟體授權條款。
而到了 2016 年，GitHub 更進一步提供了授權條款的偵測功能，只要你的程式庫裡面有正確的授權條款資訊（像是 LICENSE 檔案），然後使用的條款也在偵測的範圍內，那在 GitHub 上就會顯示該專案所使用的授權條款，也會同時提供該授權條款的特色給訪客參考，不過這個偵測功能，能偵測到的授權條款只有一些，更精確的說，就是只有 choosealicense 網站上的那些。
在 GitHub 推出授權條款偵測功能後沒多久，我就發現到 Vim 所使用的 Vim License 並不在偵測的範圍內。Vim License 是一個很特別的授權條款，是 Vim 的作者 Bram Moolenaar 專為 Vim 使用而寫的，雖然內文是針對 Vim 本身寫的，不過其實有很多的 Vim Script 也是標注使用 Vim License，甚至常常是寫 "Same as Vim"，所以實際上使用的專案並不少，所以我就一直想著，是不是有可能讓 GitHub 可以支援偵測 Vim License 呢？
閱讀「Vim License 的故事（上）」全文
Vim 的作者 Bram Moolenaar 在月初過世，消息出來至今大約已經過了一週，Vim 官網也在兩天前有了正式公告，現在除了各方的緬懷之外，Vim 的未來也是令人非常在意，這陣子也都大概有些方向了，目前狀況是 Vim 的另外一位維護者 Christian Brabandt 在負責，包括了維護 Vim 本身、網站主機和網站修改、各種使用到的服務的統整（像是 binary 放哪）、未來捐款的處理方式等等，其實事情很多，而我這篇文章則是要紀錄一些這幾天看到的東西。
Bram Moolenaar 之前其實在 Google 工作了很久，到 2021 年十月才退休，在 The Register 的報導中，有當時的訪談的部分內容，只不過當時因為種種原因沒有成為一篇報導刊出，其實看內容也感覺的出來他當時還有些退休計畫，然後接著一年後，2022 年十月，Bram 有在 mailing-group 裡面提到自己有健康問題，當時就已經有中斷 Vim 的維護工作了，然後就是今年過世的消息了，講真的，措手不及，而且 Bram 也才 62 歲，歐洲國家的預期壽命其實都有七八十的。
回到我與 Vim 之間的關係，除了我早期花很多心力在 html5.vim 之外，其實我目前還是 runtime 裡面csscomplete.vim的維護者，剛剛查一下才發現我也好久沒更新了，然後就是去年 COSCUP 我分享的 Vim License 的事情了，在 Vim License 的文本裡面的那一個特別的條文，就是開源與否的爭議是交給 Vim 的維護者決定，文本內還直接寫了現在的維護者是 Bram，然後現在就有個問題是這個條文需不需要修改，除此之外還有一個就是 vim.org 的 mail server 不知道有沒有辦法轉移，不然 maintainer@vim.org 也會無法繼續使用；其實就我所知，那個條文好像沒有真的發揮效用過，我覺得未來會用上它的機會應該也是很小，而且未來也不知道會不會有單一的 maintainer，我自己判斷社群應該會傾向維持條文不動吧。
最後就是，其實 Git 的每個 commit 的作者（author）和提交者（committer）可以是不同人的，而 Vim 早期，一直走的是老派的發 email 提交 Patch 給 Bram，然後由 Bram commit 進去 repository 裡面的流程，我當年想要用 Gmail 提交還發生過檔案內容太長，Gmail 無法發送這種信件的問題，後來是用 cli 的工具來發信，後來才開始有收 GitHub PR，但是 Bram 並不是直接用上面的功能來 merge，而是一樣拉 patch 下來，保留 author 資訊後 commit 進 repository，所以以前在 GitHub 上就很容易看到文章一開始那張圖那樣，全部都是 Bram 頭像的樣子，現在新的 commit 也開始進來了，所以最新的地方已經看不到這個樣子了。
Next Vim version is decided in Tokyo: Vim 2000! #vimconf pic.twitter.com/lt83pgnxkH
-- Ruslan Osipov (@antistatuquo) November 25, 2018
11/24 不但是台灣的大日子，日本還舉辦了 2018 年度的 VimConf，這次比較特別的是 Vim 的作者 Bram Moolenaar 也有去講 Keynote，我雖然今年依然無法去參與，但是 Twitter 上已經可以挖到不少東西了，其中有官方的投影片收集，我想在這介紹其中三個分享，第一個是 Effective Modern Vim scripting，這篇主要是做一點 Vim script 入門，另外還介紹了 Vim 8 開始的 synchronous/asynchronous process 機制的程式要怎麼寫，有興趣寫 Vim8 asynchronous script 的人可以參考一下，要找整理好的範例其實不是很好找。
第二個想介紹的是 mattn 的 What is the next feature? 這段分享主要是在介紹 vim-jp 社群，也是 VimConf 的主辦社群，這個社群還蠻活躍的，而和一般的社群比較不一樣的地方是他不只是使用者社群，也是個開發者社群，有在協助幫忙日本想貢獻 Vim 的人，包括像是資源整合、避免重工、協助轉發 bug report 和 patch，還有翻譯文件和一些文件撰寫等，接著就介紹了一些 vim-jp 貢獻的東西，像是 color emoji、lambda 之類的
最後一個就是 Bram 的 From hjkl To a plaform of plugins，介紹了 Vim 的一些發展史，主要是 plugin 相關的，也提到 Vim scripts performance 的問題（有個建議是換台更快的電腦），最後一段還提到一些未來可能的新功能，其中兩個我很有興趣，第一個是 Bram 打算處理 Plugin dependency 的問題了，投影片中有一些目前可能的解決方法，當然看起來都是走 Vim8 的 package 機制。另外一個則是 text properties，就是可以給一段文字 meta data，這個功能我非常的感興趣，因為這可以用來改善現在的 syntax highlight 機制，理想上，我可以非同步的把程式碼丟給外部的 JS parser tokenize，然後利用結果來加上 text properties，syntax highlight 再根據這個資訊來決定用那個 Highlight Group，這可以解決我的 yajs 一直無法解決的 arrow function 的判斷難題，不過還沒預計何時會出來，只能慢慢等了。
最近才注意到 Language Server Protocol （官方中文介紹）這東西，微軟為了 Visual Studio Code 所定的一個協定，專門用來輔助程式開發用的，像是 VSCode 的 IntelliSense 提供的自動補完就可以基於這個協定支援更多語言，這協定其實在 2016 就發表了，感覺我 lag 很久，不過其實我也好奇 VSCode 怎麼處理這問題一陣子了，最近在 TernJS 的 issue 裡面看到 LSP 這個詞，好奇之下才去看到底是什麼東西。
LSP 的設計理念是開發 Editor 的不可能每種程式語言都花時間心力去把它們的編輯輔助功能做起來（還不一定做的好），所以不如就把這塊拆出來，讓分析程式碼、提供輔助功能的部分（Language Server）拆出去給各自領域的人開發，然後透過一個公定的介面來做溝通，這個介面就是 Language Server Protocol 了。
LSP 是架構在 JSON-RPC 這個 protocol 上，只要你的 Editor 可以透過 JSON-RPC 發送請求並接收結果，就可以利用 LSP 來提供功能，現在支援 LSP 的編輯器也不少，不是只有 VSCode 有支援，其它還有 Eclipse、Vim、NeoVim、Sublime Text 3 都已經有方案可以支援了，在社群維護的網站 langserver.org 上有一份清單介紹各個 client 的支援狀況。
送到 Language Server 的指令，目前 Protocol 可以提供以下功能：
其它還有一些是檔案、工作區相關的操作指令，另外由於現在 Language Server 實做和 LSP 是分開的，也沒有限制一定要所有功能都有支援，所以有些 Language Server 可能是沒有支援特定功能的，目前可以找到兩份 Language Server 的列表，一份是 LSP 官網的，另一份則是 langserver.org 上的，社群維護的版本才有標示不同的 Language Server 對應支援的功能，不過說是社群維護，其實 langserver.org 是另外一間公司 Sourcegraph 在維護的，該公司做的東西和 LSP 相關性看起來還蠻大的，也提供了很多 Language Server。
然後我就很感興趣，VSCode 現在內建的 JavaScript 用的 Language Server 是哪一套呢？畢竟仔細一看，兩個列表裡面，都沒有列出內建由微軟維護的 JavaScript 的 Language Server，只有 Sourcegraph 的版本，不止 JavaScript 沒有，TypeScript 也沒，只有 TypeFox 的版本（TypeFox 也是做程式碼相關工具的公司，我有找到一些研討會演講介紹 LSP 的講者就是這間公司的人）。總之兩個語言都沒列這真是太不尋常了，實在引起了我的好奇心，後來到處尋找總算在 JavaScript in VS Code 這頁找到蛛絲馬跡，這頁內文第二句話就有個連結連去 JavaScript Language Service 在 GitHub 的介紹，位置是 TypeScript 專案下的 Wiki 頁面，也有找到 TypeScript 專案內的相關程式碼，實際上 VSCode 對於 JavaScript 和 TypeScript 的編輯輔助功能都是依靠這個 TypeScript Language Service 提供的，或是也可以叫它 tsserver，TypeScript 的大架構可以參考 Architectural Overview 這篇文章；由於 tsserver 比較早推出，所以用的不是 LSP 用的 JSON-RPC，而是 STDIO 然後傳輸 JSON 加上 header，指令也有些落差，不過其實整體而言沒差距很大，因為 VSCode 那些輔助功能幾乎都是從 Visual Studio 來的，TypeScript 的支援也早就都透過 tsserver 來實現了，事實上，Sourcegraph 的 TypeScript Language Service 就是個 tsserver 的 proxy，底層還是 tsserver，不過實際上要用的話應該是 TypeFox 的比較好；然後當然也有人提出來說 TypeScript 是不是應該直接提供 LSP 版本的開發工具支援，在 GitHub 上的 Issue 11274，不過目前看來是沒打算樣子，這點我也是蠻意外的，畢竟 LSP 和 TypeScript 同公司的，沒打算支援自家公司定的標準，也是十足的霸氣，也看的出來各開源專案自治度其實蠻高的。
補充：另外有個 debugger 用的 Debug Adapter Protocol
因為用 Dank Mono 字體的關係，最近開始有想要讓 Vim 支援斜體的 syntax highlight，於是又花了不少時間測試，過程中想起在 Twitter 上看到有人說過有一款付費的 Sublime/VSCode 佈景主題（印象中是 @yorkxin），叫 Monokai Pro，因為可以免費評估，可能是用幾天後才會出現 popup 吧，就一時興起就裝來玩玩看，結果還蠻滿意的。
雖然我主力是 Vim，但是 Sublime 和 VSCode 都還是有用，後來又繼續研究了一下，原來 Monokai 是在 Textmate 2 的佈景主題，還蠻有名的，也很多人 port 到不同環境，Vim 那邊比較多人用的應該是 molokai，然後 Monokai Pro 是同個作者做的，如果有 Vim 版的我會支持一下吧～
然後弄一弄發現我用 jellybean 的配色用到 256 色的，結果把 True Color 支援打開之後發現有點難看，又開始我的探索之旅了，目前暫時是用 tender：
整理一下各種多單字 identifier 命名慣例（規則）：
CamelCase 應該是最有名的了，單字的首字母大寫，其它字母小寫，然後其實還分為 UpperCamelCase 和 lowerCamelCase，UpperCamelCase 是指第一個單字的首字母大寫；lowerCamelCase 則相反，其中 UpperCamelCase 又稱為 Pascal Case，因為是 Pascal 語言當中常用的命名慣例，而因為有 PascalCase 這名稱代表 UpperCamelCase，所以也很多人直接用 camelCase 代表 lowerCamelCase；此外，也有 Dromedary Case 的講法，不過現在應該只要只剩下 Pascal Case 和 Camel Case 的說法比較有人用吧，Lower Camel Case 在 JavaScript Standard 裡面是命名變數用、Upper Camel Case 則是大部分語言推薦的建構函示和 Class 的命名慣例。
CamelCase 應該也是最早有名稱的，而且其實還有很多的別名，而除了 CamelCase 外，其它命名慣例都是有用個符號分隔單字，其中最常見到的就是 snake_case 了。
snake_case 是用底線符號_做分隔，通常是全小寫，名稱應該由其外觀而來，是 Ruby 社群那邊出來的，應該可以算是象形文字的一個分支。在 Python 的 PEP 8 和 perlstyle 是用 snake_case 來命名 function。
snake_case 的另一種形式是全大寫字母，因為 C 語言的 MACRO 使用，所以稱為 MACRO_CASE，偶爾有人稱之為 ALL_CAPS（不過其實全部大寫就可以稱為 ALL CAPS 了），也有一種說法叫 SCREAMING_SNAKE_CASE，通常是常數使用的命名慣例，另外像是 Bash 的環境變數、C 語言的 MACRO 等也是這個形式。
以底線為分隔的，在 perlstyle 裡面還有定義一種不常見的形式，首字母大寫加上底線分隔的 Some_Caps_Snake_Case，作為模組內的 global/static 變數，另外在 wikipedia 上有看到 Ada 語言也是用這種命名慣例，這種形式目前似乎沒有慣用的稱呼方式。
lisp-case 則是用連字號（hyphens）-做分隔，也一樣通常是全小寫，和 PascalCase 一樣因為程式語言 lisp 而得名，其實大部分語言都不支援 lisp-case，因為-同時是運算符號， parse 起來會蠻有問題的，除了 lisp 外我看過支援的還有 livescript，好像都還蠻偏 functional language 的，除了程式語言外，其實 URL 的路徑很常用，雖然主要是為了 SEO 效果，另外就是 HTML、XML 裡面的 attribute、id、class 也蠻容易見到用 lisp-case 的，而除了 lisp-case 這個名字外外，還有一個也很知名的稱呼是 kebab-case，和 snake_case 一樣是外觀而來的名稱。
用連字號做分隔，但是全大寫的則是叫 COBOL-CASE，一樣是從 COBOL 語言而來。
以 hyphens 為分隔的，在 wikipedia 上還有看到首字母大寫的形式叫 Train-Case，不過沒有標註名稱出處，不多人用這個名稱，不過也沒其它名稱，以後應該也只有這個名稱吧，不常在程式語言內見到，Windows Power Shell 的指令是用這種規則命名的，另外一個比較常見的地方就是 HTTP Header 的 field name 了。
我自己其實是最喜歡 lisp-case，編寫 HTML 的時候 id、class 我都是用 lisp-case，次之是 snake_case，偏偏 JavaScript Standard 是用 camelCase 的，其實掙扎了一陣子，不過現在已經比較習慣一點了。
這些不同命名規則間的轉換其實有不少工具可以協助，Ian Storm Taylor 在 NPM 上有一整個系列的工具，支援很多種規則的轉換，還包括了書寫用的 Title Case，講到這個就要提一下 CSS 裡面的 text-transform 的 capitalize，其實這個屬性只處理每個單字的第一個字母，也就是說，如果你本來是全大寫的 TITLE，用 capitalize 轉換後，還是 TITLE，如果要純 CSS 方案的，其它字母轉小寫，一個單字的話勉強可以配合::first-letter來辦到，不然就是輸出到 HTML 之前要先處理過，而且，capitalize 不是 Title Case，精確的 Title Case 是不會把一些介係詞、冠詞轉大寫的，例如「I Have an Apple」裡面的 an，這問題目前就是沒有 CSS 解法，有搜尋過一下發現，沒做的主因應該是因為 Title Case 幾乎只有英語用的上。
在 Vim 上如果要轉換一個變數名稱的命名規則，我是用 switch.vim 然後加上一組自訂的轉換設定：
let g:switch_custom_definitions =
\ [
\ {
\ '\<\(\l\)\(\l\+\(\u\l\+\)\+\)\>': '\=toupper(submatch(1)) . submatch(2)',
\ '\<\(\u\l\+\)\(\u\l\+\)\+\>': "\\=tolower(substitute(submatch(0), '\\(\\l\\)\\(\\u\\)', '\\1_\\2', 'g'))",
\ '\<\(\l\+\)\(_\l\+\)\+\>': '\U\0',
\ '\<\(\u\+\)\(_\u\+\)\+\>': "\\=tolower(substitute(submatch(0), '_', '-', 'g'))",
\ '\<\(\l\+\)\(-\l\+\)\+\>': "\\=substitute(submatch(0), '-\\(\\l\\)', '\\u\\1', 'g')",
\ }
\ ]這組設定是MACRO_CASE、lisp-case、camelCase、PascalCase、snake_case這樣的順序循環切換，還蠻方便的，不用花大腦思考要轉成哪種規則然後下不同指令，就一直連打-就好。
其實一開始只是在想有多少種組合才開始查的，結果幾乎一般組合都有地方使用，只差符號分隔單字加 camelCase 的兩種形式吧，最後放一些參考連結：
Vim 8 有兩個我覺得比較大的新功能，一是開始有 Asynchronous I/O，二是開始有官方的 package 機制了，這篇主要想介紹這官方的 package 機制，眾所周知，以前 Vim 實在很難管理自己裝的 Vim script 和 plugin（後文以 plugin 為主），因為原始的設計是自己把檔案丟到 runtime 目錄下的對應位置，裝的東西一多，就會開始混亂起來，最常發生的就是越來越多垃圾，不知道還需不需要用，再來就是可能會有檔名重複的情形，所以升級某個 plugin 遇到有檔名重複時，直接覆蓋過去可能也會出錯，這個問題直到 Tim Pope 推出 pathogen.vim 後才被解決，pathogen 是藉由修改runtimepath變數（有點像是系統的PATH環境變數，可以有多個路徑）來讓不同的 Vim plugin 可以放在各自的子目錄內，從此一舉解決了 Vim plugin 的管理問題，當然現在很多人用的 Vundle、neobundle、vim-plug 等，基礎原理應該都是一樣的。
Vim 8 推出的 package 機制，雖然其基本原理也是增加 runtimepath，不過它其實定位和 pathogen 不一樣，設計上是再高一個階層，不過也因此和 pathogen 的路徑設計不相容，pathogen 之類的都是把 plugin 分目錄放到~/.vim/bundle這，例如：
~/.vim/bundle/html5.vim
~/.vim/bundle/yajs.vim然後會去把這些路徑加到runtimepath內（有些 plugin 是全自動、有些要設定、有些可以加條件），寫成 glob 型式大概是~/.vim/bundle/*，不過新的 package 定義上是數個 plugin 的組合，所以一個 package 下是可能有多個 plugin 的，放 package 的路徑一樣在~/.vim下面，預設在~/.vim/pack，也可以修改packpath來換位置，不過東西不是直接放進去就好了，一開始會被加進去 runtimepath 的路徑實際上是~/.vim/pack/*/start/*，在這個 glob 表示式中，第一個*是 package 層，第二個*則是 package 裡面的 plugins，例如我可以建立一個自己在編輯 JavaScript 時用的 plugin 組合，就先叫 my-js 好了，我就把東西都丟到~/.vim/pack/my-js/start/*，大概像是：
~/.vim/pack/my-js/start/yajs.vim
~/.vim/pack/my-js/start/javascript-libraries-syntax.vim
~/.vim/pack/my-js/start/simple-javascript-indenter至於中間的start則是表示啟動就會去讀進來的意思，類似於以前 pathogen 的流程，而除了start之外，還有一個路徑是opt，是 optional 的意思，放在opt下面的 package 不會在啟動時就讀進來，而是要下packadd指令，例如packadd foo就會去找~/.vim/pack/*/opt/foo/這些位置有沒有東西可以用，文件上提供的一個使用情境是根據 Vim 版本決定要讀入哪一個 optional plugin，可以用 Vim script 做一些判斷來決定要讀那些，或是使用者自己執行 packadd，不過我思考一下是覺得後者的情境似乎不太有用，所以這個設計主要的目標應該還是做一些自動化判斷並讀入 plugin 為主吧。
當然，package 也可以只包一個 plugin，理論上可以直接這樣發佈 Vim plugin，不過現在這樣發佈，就會不相容於目前使用量最大的 pathogen 架構，所以我也還沒看過有人這樣直接發佈的，像 vim-css3-syntax 就還是用舊的資料匣架構，但是在 README 內加上對應 Vim package 的安裝方式，這是我目前覺的對於 Vim package 普及化的最大阻力；另外還有一個缺點是，如果完全用 Vim package 機制來裝 plugin，那其實也沒有地方紀錄你安裝了那些東西，和最早的時候，或是單純只有 pathogen 時一樣，要裝新機器什麼的就有點麻煩。目前我是覺得 Vim package 還不會很快普及，它比較像是出來取代 pathogen 的功能，應該接著要等有基於 Vim package 的 package manager 出來才會開始有普及的機會吧。
Vim 有一個內建的自動補完功能是針對檔案名稱的，使用的方法是<C-X><C-F>，我目前在維護的 autocomplpop 也有支援這種補完模式，只要輸入./後就會自動幫忙觸發，不過我比較有機會觸發到是在使用 ECMAScript 6 的 import 和 CSS 的 import 時，不過常常就是發現他查看的路徑不太對，不是拿目前編輯檔案的位置做為起點的，研究過後發現是因為 Vim 找檔案的起點是看他的工作目錄($PWD)，加上我會使用 ctrlp 這種工具，所以實際上在編輯的檔案通常是不在工作目錄下，對於這個問題，其實我覺得最理想的解決方式是 Vim 應該要提供兩種模式來決定要從那邊開始找，不過目前似乎沒這個計畫，唯一在文件是有提到的是未來可能會支援 path 的設定，理論上，如果有支援的話，應該就可以解決問題了，因為預設的path值包括了.，不過目前還沒有相關時程，就只能自救了。
最簡單的方法，其實就是開啟 autochdir，這個選項打開後就會自動在切換 window 時也更改工作目錄，不過這個選項是為了相容早期系統才提供的，文件也有說可能會和部分 Vim Script 不相容，實際上我也有找到一些不相容的 Vim Script，所以想避免，就搜尋了一下其它可能的解決方法，在 StackOverflow 上有看到一篇，裡面有兩個人提供了解法，第一個是用autocmd，然後在進入 insert mode (在這時候才有機會用到檔名補完的功能)時自動開啟autochdir，離開時自動關閉autochdir，不過這樣的方式（感覺上）還是不太安全，因為還是用到autochdir，所以下面有另外一個方法改用 lcd，作法是改成修改 Key Mapping 的方式，改的 mapping 是./<C-X><C-F>，不過這樣對我來說又不合用，因為我用 autocomplpop 的話，不會真的打<C-X><C-F>，所以基本上觸發不到這事件，所以我就決定把這兩種解法合併起來，改成用autocmd加上lcd：
:autocmd InsertEnter * let save_cwd = getcwd() | execute 'lcd %:p:h'
:autocmd InsertLeave * execute 'lcd' fnameescape(save_cwd)進入 insert mode 時改變該 window 的工作目錄，離開 insert mode 時把工作目錄還原。這是我目前認為影響最小的調整方式，不過其實可能執行一次lcd換工作目錄就夠了，沒深入研究 autochdir 所產生的問題，不過我推測是影響到 Vim Script 建立的 window 的工作目錄，像是 NERD Tree 之類的側邊欄那種，總之目前這樣運作還算正常，接下來就是等 Vim 加上path的支援吧（或是有人送 patch）。
因為最近 Vim 8 發佈了，所以就又研究一下現在最新的 True Color Vim 安裝方法，結果發現已經併進 master branch 許久了，然後從 7.4.1784 開始，也不用加特別參數來編譯，只要--with-features的值是big或是更大的huge就會把這功能編譯進去，所以現在就不用 ZyX 維護的版本了，目前用的編譯指令為：
git clone https://github.com/vim/vim.git
cd vim
cd src && make autoconf && cd ..
./configure \
--enable-gui=no \
--without-x \
--enable-multibyte \
--with-tlib=ncurses \
--enable-cscope \
--with-features=huge \
--disable-nls \
--enable-perlinterp \
--enable-pythoninterp \
--enable-rubyinterp
make
make install然後現在也不需要guicolors的設定，好像直接就生效了，顏色畫出來和之前的 ZyX 的版本似乎有一點差異，我想應該現在新的版本是比較正確才是。追蹤這功能追了這麼久，總算也是告一段落了，感覺...好像也沒什麼特別的感覺...