讓系統 (root) 的 Vim 可以用 securemodelines

自己帳號下 Vim (甚至是 Neovim) 要裝什麼都很簡單,但動到系統的時候基本上儘量維持原狀,除非是利遠大於弊的項目。

這次遇到的問題是用 sudo vimnginx 設定檔時無法判斷出正確的 filetype=nginx,這點通常可以在檔案開頭放個 # vim: typefile=nginx 解決,這個功能叫做 modelines

但這也代表在開任意檔案的時候很危險,因為他可以任意設定 Vim 的變數,所以就有了 securemodelines 這個套件,只允許某些參數被 override。(不過後來好像名稱變成有 dash 的 secure-modelines)

所以問題就變成要怎麼讓 root 吃這個 plugin... 我研究一輪後決定這樣搞:

先在 Ubuntu 上安裝 vim-scripts,這個套件裡面就有 secure-modelines,從 dpkg -L vim-scripts 裡面可以看到:

/usr/share/doc/vim-scripts/html/secure-modelines.html
/usr/share/vim-scripts/secure-modelines
/usr/share/vim-scripts/secure-modelines/plugin
/usr/share/vim-scripts/secure-modelines/plugin/securemodelines.vim
/usr/share/nvim/site/pack/dist-bundle/opt/secure-modelines
/usr/share/vim/vimfiles/pack/dist-bundle/opt/secure-modelines

接著就是到 /etc/vim/vimrc.local 裡面放設定,因為這個檔案會被 /etc/vim/vimrc 自動呼叫:

set runtimepath+=/usr/share/vim/vimfiles/pack/dist-bundle/opt/secure-modelines
packadd! secure-modelines

這樣避免了裝 package manager...

Vim 的後續計畫

在「Vim 作者 Bram Moolenaar 過世」後,Christian Brabandt 在「The future of the Vim project」這邊討論了 Vim 的後續計畫,主要是因為 Bram Moolenaar 算是主要的 coordinator,在他過世後大家需要確認彼此的權限,以及後續的共識。

目前這樣看起來是有在收斂,但我猜測在夠久的將來後會跟 Neovim 合併?至於會用誰的名字留下來就不知道了... 或是 Vim 專案後面沒有能量而被廢掉?

另外一個有趣的消息是這個:

Unfortunately, OSDN.net is apparently now being owned by OSChina and we currently do not have any support by OSDN.net or OSChina teams. @Shuji, thank you for maintaining the Vim Website since 2018 and all the best for the future!

翻了一下 OSDN 這個英文版的條目,沒寫到這件事情,是在日文版的條目 OSDN 上看到的。

Open Source Development Networkは、OSDN(オーエスディーエヌ)と略し、中国企業の开源中国(OSCHINA)が運営する、日本向けのオープンソースソフトウェアプロジェクト向けのホスティングサイト。かつてはSourceForge.netの姉妹サイトで、2015年5月11日にサイト名称がSourceForge.JPからOSDNに変更された。

翻了一下新聞,看起來是 2022 年的事情:『「OSDN」が中国企業に買収 ~日本のオープンソースプロジェクト ホスティングサービス』。

Vim 作者 Bram Moolenaar 過世

Hacker News 上看到 Bram Moolenaar 過世的消息:「Bram Moolenaar Passed Away (groups.google.com)」。

沒有提到太細節的狀況,看起來是發生某種發展很迅速的情況而過世了:

Bram was suffering from a medical condition that progressed quickly over the last few weeks.

Bram Moolenaar 留下來對我影響最深遠的東西就是他發明的 Vim 了,我從大學開始用 Vim,到現在二十幾年了,在這些年來可以看到有很多不同的編輯器推出,而市場上也有很多人一直在跳槽,而 Vim 社群的人就是「用的很習慣」而沒在動,在每年的編輯器市占率調查中總是可以看到固定的數量。

即使到了 2022 年,你還是可以看到 Vim 在 engineer 社群還是有一定的比率:(出自「Integrated development environment」)

最原始的 vi 後續有很多 fork,但後來 Vim 一統天下,直到 2015 年 Neovim 帶來更活躍的改變,才又開始分岔,也反過來推動了 Vim 社群的進步。

然後突然看到這個消息...

測試 Neovim + GitHub Copilot

如同之前在「GitHub Copilot 宣佈 GA」提到的,Copilot 有支援 Neovim,找了一下在 GitHub 上的 github/copilot.vim 這邊可以取得。

Copilot.vim is a Vim plugin for GitHub Copilot. For now, it requires Neovim 0.6 (for virtual lines support) and a Node.js installation.

主要有兩個 dependency 問題,第一個是 Neovim 版本要 0.6+,而在 Ubuntu 20.04 內的版本不夠新 (22.04 的看起來就夠),可以裝 PPA 版本解決:「Neovim Stable」。

另外一個是 Node.js 版本需要到 16+ (20.04 與 22.04 內建的都不夠),這個我是靠 nvm 解決。

先在 GitHub 網站上開通 Copilot,再照著說明,回到 Neovim 裡執行 :Copilot setup,跟著步驟跑授權流程就可以了。

接下來隨便開個 test.py 或是 test.php 檔開始寫,就會發現有 suggestion 跑出來了。

這邊拿 feedgen 測試會不會動,輸入 feed. 後就會出現灰色的 subtitle(title)

這時候按 tab 就會展出來了。

用顏色區分程式碼裡面的括弧

Hacker News Daily 上看到 VSCode 改善了 bracket pair colorization 效率的文章,才想到我的 Vim 好像沒裝這個功能:「Bracket pair colorization 10,000x faster」。

VSCode 這邊主要是引入了新的資料結構改善了計算量,有興趣的可以看一下:

Efficient bracket pair colorization was a fun challenge. With the new data structures, we can also solve other problems related to bracket pairs more efficiently, such as general bracket matching or showing colored line scopes.

我這邊則是去找 Vim 上的套件,目前看到是「Rainbow Parentheses Improved」這個,裝起來拿 PHP 程式碼看了一下還行,這樣就不用在那邊算哪個左括弧對應到右括弧...

Neovim 在選擇檔案名稱時的操作按鍵

Neovim 時操作檔案名稱時會是下拉選單,在 insert mode 時的畫面是這樣 (進到 insert mode 後 Ctrl-X + F):

這時候可以用上下鍵選擇檔案名稱。

在 command mode 下也有類似的功能,像是 :sp 後按 tab 選擇檔案名稱:

問題在於只能用 Ctrl-N 與 Ctrl-P 移動,而不能用上下鍵操作,兩者的 UI 類似但是操作的方式不一樣,於是就翻了翻 manual,找出對應的模式,得到是 command mode,然後用 <expr> + pumvisible() 判斷是否是在 popup menu,接著把上下鍵對應到 Ctrl-N 與 Ctrl-P:

cnoremap <expr> <Down> pumvisible() ? "\<C-n>" : "\<Down>"
cnoremap <expr> <Up> pumvisible() ? "\<C-p>" : "\<Up>"

這樣就搞定了...

給 Vim 的進階使用者看的教學

Hacker News Daily 上看到「A Vim Guide for Advanced Users」這篇,寫給 Vim 進階使用者的教學,教你怎麼更順暢的操作 Vim,對我來說還是有不少內容是不熟悉的...

先提到作者的另外兩篇文章,其實也還是很值得翻一下,是給初學者與給中階使用者的教學:「Is Vim Really Not For You? A Beginner Guide」、「A Vim Guide for Intermediate Users」。

這類文件可以隔幾個月回來看一次,每次都可以學到一些東西,不需要一次把裡面的技巧都看懂學完。

Terminal 的 Dark Theme

在「Automatic dark mode for terminal applications」這邊看到讓 terminal 的一些程式支援 Dark Theme 的方式,裡面引用的是「Automatic dark mode for terminal applications」這篇。

可以看到因為 terminal 下沒有標準,所以得 hack 事件發生時要送出的指令,文章裡面給出了 Vim (以及 Tmux)、Alacritty 這幾套程式的 hack。

不過這些 hack 過程算詳細 (而且有說明整個原理),如果有其他 terminal 下的程式有支援 Dark Theme 的話也可以用類似的邏輯套進去。

vim-polyglot 把預設的 tabstop 改成 2

發現 VimMakefile 類的檔案 (包括 GNUmakefile) 的 tab 都變成 2 格,交叉測了一下發現是 vim-polyglot 造成的:「Polyglot is wrongly setting tabstop to 2 on several file types #648」。

目前先用作者提到的方式 let g:polyglot_disabled = ["autoindent"] 解 (在首頁也有提到這個)。

目前看起來正常一些了...

Vim 的 virtualedit 與 GNU Make 內的 .PHONY

在「Writing a Book with Pandoc, Make, and Vim」這邊看到作者在講他怎麼用 Pandoc + GNU Make + Vim 寫書,不過我這邊看到兩個有趣的東西 (標題提到的那兩個),拉出來寫一下...

一個是 Vim 的 set virtualedit=all,可以不受限制的移動,等到實際編輯時再產生出對應需要的空白,這對於畫表格會方便不少:

另外一個是 GNU Make 的用法,平常我們都是在 .PHONY 裡指定實際上不會存在的 target:

.PHONY: clean
clean:
        rm -rf ./output

這邊作者提供的方式是產生一個叫做 phony 的 target,然後就不需要在 .PHONY 裡條列,而是各自在自己的 target 裡面引用 phony

.PHONY: phony
clean: phony
        rm -rf ./output

不過作者有提到效能問題:

Note that this trick can slow down huge Makefiles.

另外作者又提醒我 draw.io 這個好用的工具,之前用過幾次後就忘記了...