8年ぶりに vimrc を書き直した
2013年にEmacsの使いすぎで小指が痛くなってからVimユーザーをやり始めて、かれこれ8年が経つ。 当時書いたvimrcを秘伝のタレ的に使い続けてきたが、正直あんまりまともにプラグインの更新とかをやっていなかったせいで、ある日突然、普通に使ってるだけなのにエラーが出まくって困る状態になった。
Vim の寿命
後ろめたさを感じつつも NeoBundle.vim、neocomplete.vim、Unite.vim といった一世代古いShougoさんウェアを使い続けていて、特に Unite.vim は後述の都合により2014年のバージョンに固定して更新をサボっていたのだが、Unite関係の何かがVim 8.2で動かなくなった*1。macOSではsystem Vimを使うようにしてみたところ、system Rubyが何か壊れているせいでif_rubyで書いている自作のUniteプラグインが常にバックトレースを吐く状態になった。
Linuxでも、neocompleteが特定のバージョン以上だと動かないという警告を見てからその直前のバージョンのVimを手動コンパイルすることで耐えていた。仮にその問題がなくとも、if_rubyを使っているせいでそれと+clipboardがついてるVimがapt installで入れられず、よくVimを温かみのある手動コンパイルをするハメになり、不便だなあと思っていた。
何かと不便な点を直したかったのと、仕事で使っているmacOSのマシンでVimが全く使えない状態が致命的だったので、思い腰を上げて vimrc を書き直すことにした。
NeoVim 移行
@giginet が昔 neovimが実用段階になったようなのでvimを置き換えてみた話 を書いてたのを見てからずっと気になっていたので、今回試してみることにした。 vimrcを読みにいく場所が違うので、(Linuxでは) ちゃんと動く普通のVimでスクラッチの設定ファイルを書きNeoVimでそれをテストするというのにちょっと便利だった。
Shougoさんの新しいプラグインのサフィックスが.nvimなことや、roxma/vim-hug-neovim-rpcというNeoVimのRPC (MessagePackを使っているらしい) をVim用に変換するというワークアラウンドっぽい方法でVimがサポートされているのを知っていたので、それらのプラグインを使う以上はNeoVimにしておいた方が筋が良さそうと思っていたというのもある。挙動は大体同じで、あともしかしたら速いんじゃないかと期待したけどそこはあまり変わらなかった。
プラグインの廃止と更新
まず、Shougoさんのプラグイン3つを新しくした。それから、そもそもmacOSでヒットした2つのエラーはどちらも出所は自作のプラグインっぽい感じだったが、いろいろ調べたところ自作すべき理由がもうなさそうだったので、それらは使わなくて済むようにした。
Shougo/neobundle.vim
最初にneobundle.vimを後継のdein.vimに移行した。設定はNeoBundleみたいにVim Scriptで書くこともできるが、TOMLで定義することもでき、僕はTOMLを使うことにした。neobundle.vimは2018年でメンテが止まっていて、かつdein.vimの方が速いらしい。
Shougo/unite.vim
後継のdenite.nvimにしようとしたのだが、2014年のUnite.vimとはあまりにも挙動が違いすぎる上、結構時間を使っていろいろ調べたがなかなか自分の期待通り動くように設定できなかったので、一旦これに移行するのは先送りにすることにした。
fzf.vim というのも一瞬試してみたけど、denite.nvimよりも更に期待から離れる挙動だったのでこれも保留にした。思ってたよりファンシーなUI。
諦めてunite.vimのバージョンを2014年のものから最新のものに更新して一旦凌ぐ方針に変えた。そもそもneobundle.vimと違ってunite.vimはバグフィクスの範囲で現在もメンテが継続しているため、古いバージョンに固定などしていなければ、ある日突然壊れるリスクはneobundle.vimより低い感じがする。
適当にmasterに更新してみたところ、見た目が自分が元々使っていたものと大分異なるため違和感がある状態だった。カーソル行ハイライトの挙動が変わったのが原因だなとわかったが、パフォーマンスの都合により、これは戻されることはないらしい。元のハイライト方法がシェルで愛用しているpecoのそれと一緒だったのが気にいっていたので、どうにかして戻したかったので、forkしてリバースバックポートした。まあ2014年のものに固定し続けるよりforkの運用の方がマシとはいえ、本質的には何の解決にもなってないので、そのうちdenite.nvimに移行する予定。
Shougo/neocomplete.vim
後継のdeoplete.nvimに移行。設定のインターフェースがneocompleteそのままっぽい感じだったので移行は一瞬でできた。
k0kubun/vim-open-github
Vimで開いているファイルのGitHub URLをブラウザで開く奴。元々tonchis/vim-to-githubにPRを送りつつ使っていたのが、GitHub Enterpriseに対応させたりなどのために自分で書き直したのだった。で、これがif_rubyを使っていて、Vimをインストールするとif_python3が有効なことは多いがif_rubyは大体ついてなくて面倒なので、このプラグインは捨てたいなと思っていた。
tyru/open-browser-github.vim がよく使われていてメンテもされてそうだったので、これに移行することにした。OpenGithubFile 以外にもOpenなんとかコマンドがいっぱい定義されるせいで :Op<Tab> で一発で補完できないのが不便だなと思ったけど、使わないやつをdelfunctionとdelcommandしていくことで解決できた。
k0kubun/unite-git_files
Gitリポジトリ内では git ls-files を使い、それ以外の場所では file_rec を使うUniteソース。元々yuku/unite-gitに高速化のためにLua対応のPRなども送りつつ使っていたが、多分 file_rec へのフォールバック部分が欲しくてforkした。LuaがなければVim Scriptで動くようにしたとはいえ、このプラグインのためにif_luaに気を使わないといけないのもちょっとなあ、と思っていた。
で、これはdenite.nvimのドキュメントで推奨されている finddir('.git', ';') != '' ? 'file/rec/git' : 'file/rec' がUniteでも同じ感じで設定できるので、このプラグインも不要になった。finddir('.git', ';') だとGitリポジトリトップじゃないと期待通り動かないんじゃないかと心配だったが、それは杞憂だった。
追記: ファイルが多いと file_rec/git が結構遅いことに気付いた。Luaなしなら最新のUnite.vimとNeoVimで問題なくこのプラグインが動くし、別にLuaなしでも file_rec/git よりは大分速いという感じだったので、ひとまずこのプラグインの利用は継続することにした。
Language Server Protocol
あとは使ってそうな設定を持ってきて整理するだけで大体準備できたけど、NeoVimも特にVimと変わった感じしないし、Uniteも無理やり元の挙動に合わせたことで何も変わり映えしなくてつまらんなという感じがしたので、気になっていたLSP連携*2を試すことにした。
deoplete.nvim に移行したことで、どうやら deoplete-vim-lsp と vim-lsp をいれるだけでLSP連携が動くらしいと @giginet 先輩に教えてもらった。
deoplete-vim-lsp のREADMEにあったGoの例を試そうとしたが、そこにあったbingoはgolspがあるのでメンテが停止していたとのことだったので、mattnさんの記事を参考にgopls*3を試した。なんか型に応じて補完されたり、使われてない変数がハイライトされたりとか、IDEっぽい感じに使えて面白かった。
まあ、IDEみたいに起動してから長い時間インデックスに待たされることもなく、インデックス用のバックグラウンドプロセスが壊れるのを直したりするのに時間を使わされることなくスイスイ書き始めたい時にVimを使っているみたいなところもあるので、実際VimでLSP使いたいかどうかはまた別の話なんだけど。
最近のタイムラインに関する余談
今はemacsが滅んでvimが生き残ったのは誰の目にも明らかだけど、これは自分には結構驚きなんだよな。
— karino2@平民階級 (@karino2012) February 27, 2021
冒頭に昔EmacsやめてVimに移った話を書きはしたが、Emacsが滅んだと思ったことはなかったので、いつのまにかそういう風潮になっていることに驚いた。同僚や同世代にEmacsを使っている人は今でもいっぱいいる*4し、Emacsを使ってることで知られている僕が尊敬する人たちも今でもEmacsを使っていそう、というくらいの認識だった。LispハッカーのPaul Grahamが (Lispで設定できるEmacsではなく) vi使いらしいという話が出てたのはちょっと面白かった。
vim-jp に入らないのはそもそもvim使ってないこと以前に、内輪ノリ感が強すぎてウッとなるからです
— OSSタダ乗りおじさん (@mizchi) March 2, 2021
僕はこれまでvim-jpに入ってなくて雰囲気を知らなかったのでこの内容に関してはニュートラルなんだけど、ちょうどvimrc書き直してるところにこれが流れてきて質問とかするのに便利そうだなと思ってvim-jp Slackに入り、「mizchiさんのツイートを見てvim-jp Slackにジョインしました」というボケをかましたらこのツイートでちょっと盛り上がっていた。
