🔌

今年お世話になった 12 個の Vim (Neovim) プラグインを紹介します

2022/12/12に公開

はじめに

2022年ももうすぐ終わりそうですね。今年は Vim に関するお仕事がいただけたり、設定ファイルを Vim script から Lua に移行したりと、Vimmer としては非常に充実した一年となりました。これも Vim/Neovim コントリビュータの方々と、数多のプラグイン開発者のおかげです。本当にありがとうございます。
そこで本記事では、私が普段使っている Vim (Neovim) プラグインを主観強めで紹介します。私が普段メインで使っている Neovim には 2022/12/11 現在 91 個のプラグインが入っていますが、91個すべて紹介するのはさすがに無理なので、そのうち特に今年活躍したと感じるもの、印象に残った12個に絞ることにしました。自分に合いそうなものがあればぜひ導入してみてください。

1. tani/vim-jetpack

https://github.com/tani/vim-jetpack

プラグイン紹介

vim-jetpack はプラグインマネージャ、つまり Vim/Neovim のプラグインのインストール・更新・読み込み等を管理するプラグインです。2022年時点での Vim プラグインマネージャの一覧は以下の記事を参照すると良いでしょう [1]

https://qiita.com/nil2/items/ddcf23f1163d0abd805b

作者の方による解説記事が今年のアドベントカレンダーの記事としてすでに公開されているので、詳しくはそちらをご確認ください。

https://zenn.dev/dog/articles/jetpack_2022

感想

vim-jetpack 導入のきっかけは設定ファイルの Lua 移行でした。今年の4月から6月にかけて Neovim の設定を Vim script から少しずつ Lua に移行していたのですが、ちょうどその頃 vim-jp で vim-jetpack の評判をよく聞いていたこともあり、プラグインマネージャを minpac から vim-jetpack へと乗り換えることにしました。vim-jetpack には公式の Lua API が 存在していたことが決め手だったといえます。もともと使っていた minpac がシンプルだったこともあり、互換性のない機能等に悩まされることもなく、比較的楽に乗り換えることができました。

まだ公開されてから1年経っていないプラグインですが、開発が活発で勢いもあり、すでに人気プラグインマネージャの一角を担おうとしています。今後も人気は増していくものと予想されます。プラグインマネージャでどれを選ぶか迷っている方は、ぜひ検討してみてください。

2. lambdalisue/fern.vim

https://github.com/lambdalisue/fern.vim

プラグイン紹介

Vim/Neovim の両方で安定して使えるファイラです。ファイラは競合プラグインも多く、激戦区と言えます。類似プラグインについては、fern.vim の作者でもある lambdalisue さんによって整理された以下の記事を参考にすると良いでしょう。

https://zenn.dev/lambdalisue/articles/3deb92360546d526381f

なお、ddu.vim ユーザには今年新たに開発された ddu-ui-filer という選択肢もあります。こちらも気になるところですね。

感想

殿堂入り枠その1。私にとっての無人島プラグイン [2] の候補の1つです。非同期をウリにするだけあり、重たいディレクトリを開いてもカーソルの自由が奪われることはほとんどありません。Fern バッファ内での設定自由度が高く、割と自由にキーバインドやモーションを設定できるのも良いですね。4年ほど使い続けているものの、これからも使いたいと思える素晴らしいプラグインです。

今年新たに g:fern#renderer#nerdfont#indent_markers という設定用の変数が追加され、 Nerd font ユーザはディレクトリの範囲を線で描画できるようになりました。私も設定してみましたが、スタイリッシュで良い感じです。

https://twitter.com/lambdalisue/status/1582743420556087297?s=20&t=6qrwKqXushHTW8bGzsrgIQ

外部依存なし、非同期、単純な設定でも動くなど、万人にオススメできる要素の揃ったファイラだと思います。ファイラで悩んでいる方はぜひ検討してみてください。

3. lewis6991/gitsigns.nvim

https://github.com/lewis6991/gitsigns.nvim

プラグイン紹介

Git の情報を表示できるプラグインです。開いたバッファの変更差分 (unstaged changes) がひと目で分かるようになります。バッファの差分を表示する方法といえば 'signcolumn' を使う方法がメジャーですが、実はそれだけでなく、以下の方法をサポートしています。

  • signcolumn: 行番号の左にある signcolumn に表示する
  • numhl: 行番号を表示する箇所のハイライトを変更する
  • linehl: diff mode で表示したときのように、バッファ本文のハイライトを行単位で変更する

その他にも、削除したハンクの内容を表示したり、特定のハンクだけステージしたりと、様々な機能があります。

感想

ゴリラさんから教えていただき、今年導入したプラグインです。それまでは vim-signify を使っていたのですが、gitsigns.nvim の UI に惹かれ乗り換えました。

差分を表示する方法のうち私が気に入ったのは "numhl" です。それまで set signcolumn=yes:2 として signcolumn に diff / diagnostics を表示していたものの、1ウィンドウあたり signcolumn が4文字もの幅を占めることがどうしても気になっていました。このプラグインを入れてからは set signcolumn=number とすることで、diff 情報を行番号のハイライトとして出し、 diagnostics を行番号表示の上に重ねるようにしました。その結果ウィンドウの左側が整理され、ウィンドウを縦に分割したときの圧迫感が軽減されました。


numhl の方法で diff を表示する例

私は Git 操作に普段 gina.vim を使うため、 gitsigns.nvim は一部の機能しか使っていませんが、それでも入れて損はないと思えるプラグインです。

4. habamax/vim-gruvbit

https://github.com/habamax/vim-gruvbit

プラグイン紹介

Vim のカラースキームの1つです。人気カラースキームの一つである gruvbox がベースとなっており、本家よりも赤が少なく、黄色が多く使われているのが特徴です。

感想

全体的に落ち着いており、黄色を目立たせた配色はどこか秋を彷彿とさせます[3]。長く使っているお気に入りのカラースキームです。ただし最近はあまりメンテされていないようで、nvim-treesitter のハイライトグループにも対応していません [4]

gruvbox 系の配色が好きなのでずいぶん長いこと使ってきましたが、最近同じ作者の habamax というカラースキーム [5] が標準の Vim (Neovim) に組み込まれました。今後そちらに乗り換えても良いかなとも思っています。

5. machakann/vim-sandwich

https://github.com/machakann/vim-sandwich

プラグイン紹介

指定された範囲を括弧で囲んだり、括弧の種類を変更したり削除したりする機能を提供するプラグインです。括弧に関わらず、名前を指定して関数やメソッドで囲うこともできます。ドットリピートにも対応しており、括弧関連の操作を大幅に簡略化することができます。

感想

殿堂入り枠その2であり、無人島プラグインの筆頭候補です。

魅力はなんといっても Vim 操作との相性の良さ、そしてカスタマイズの自由度の高さです。undo やドットリピートといった操作を違和感なく行うことができ、設定次第で対応する括弧の種類を増やしたりカスタマイズしたりすることも自由自在にできます。

特に便利なのは任意のテキストオブジェクトを関数で囲ったり、ジェネリクスで囲ったりする機能です。

foo ==[saiwfsomefn<CR>]==> somefn(foo)
i32 ==[saiwgOption<CR>]==> Option<i32>

このうちジェネリクスで囲う機能は標準では用意されていませんが、以下に書かれている方法で実現することができます。

https://scrapbox.io/vim-jp/sandwich,_textobjでGenericsを扱う

vim-sandwich の設定記述方法は全体的に辞書 (dict) ベースとなるため、Lua のテーブル記法との相性が良いと感じました。ただし、Lua から OperatorSandwichCancel 例外を投げる方法が分からず、関数で振る舞いを指定する部分については一部 Lua 化ができていません。解決法をご存じの方は教えていただけると助かります。

6. itchyny/vim-qfedit

https://github.com/itchyny/vim-qfedit

プラグイン紹介

QuickFix/LocationList ウィンドウを編集できるようにするプラグインです。

感想

このプラグインはいつ入れたかも覚えていない [6]、自分にとってはまるで空気のようなプラグインです。しかし、QuickFix を編集できるのは地味ながら便利で、一度 QuickFix に流したものを再度絞り込んだり、対応したものを消していったりすることができます。

ちなみに、QuickFix で指定された行を一括で編集・修正することのできる vim-qfreplace も便利です。

https://github.com/thinca/vim-qfreplace

7. nvim-telescope/telescope.nvim

https://github.com/nvim-telescope/telescope.nvim

プラグイン紹介

Lua 界隈で(おそらく)最も高い人気を誇るファジーファインダープラグインです。ファジーファインダーはファイラ以上に種類がたくさんあり、ここではとても説明しきれないので、以下の記事をご覧ください。

https://zenn.dev/yutakatay/articles/vim-fuzzy-finder

感想

Lua で実装されているため、本体については外部依存がないというのは嬉しい点ですね。たいした設定を入れなくても動くため、重宝しています。

機能が多く、telescope の拡張もたくさん存在するため、未だにちゃんと使いこなせてはいません(全貌すら把握できていません)。来年はもう少し使いこなしたいものです。

今年は「telescope.nvim の結果を QuickFix に流す」術を覚え、応用の幅が広がりました。QuickFix という UI は便利ですね。

8. nvim-treesitter/nvim-treesitter

https://github.com/nvim-treesitter/nvim-treesitter

プラグイン紹介

Neovim ユーザであれば使っている人も多いでしょう。Neovim の tree-sitter 連携機能を使うためには必須、と言っても過言ではないプラグインです。

感想

私は去年の秋頃に nvim-treesitter を使い始め、その設定の自由度の高さとポテンシャルに虜となりました。ちなみに去年のアドベントカレンダーにも記事を1つ投稿しています:

https://zenn.dev/monaqa/articles/2021-12-22-vim-nvim-treesitter-highlight

nvim-treesitter プラグインは変化が激しく、今年も互換性を破壊する変更をいくつも入れています。そのため、今まで動いていた設定が突然動かなくなったり、いきなりハイライトが消えてしまったりといったトラブルも珍しくありません[7]。うかつにプラグインを更新すると壊れるかもしれない今の状態は、プラグインを常用するという意味では決して理想的とはいえませんが、裏を返せばそれだけ開発が活発ということでもあります。早く stable 版が出るに越したことはありませんが、今後も積極的に開発が進み、どんどん便利に発展していくと良いなと思います。

なお、今年はクリスマスにもう1つ記事を投稿する予定ですが、そちらは nvim-treesitter の内容にしようと思っています。クリスマスツリーですね。

9. stevearc/aerial.nvim

https://github.com/stevearc/aerial.nvim

プラグイン紹介

開いたバッファのアウトライン(目次)を表示するための Lua 製プラグインです。類似プラグインに vista.vim があります。

感想

今年見つけたプラグインですが、2020年時点ですでに存在していたようなので、Lua プラグインとしてはそれなりに年季があるかもしれません。

私が特に気に入ったのは以下の2点です。

  • アウトラインのウィンドウの開き方・設定方法が充実している点。
    • README の Options を見れば分かりますが、実に様々な設定があります。
    • Lua の API も整備されており、キーバインドも比較的自由度高く設定できます。
  • nvim-treesitter に対応している点。
    • query ファイルを書くことで、どの構文要素をアウトラインに表示するか自分好みにカスタマイズできます。
      • query ファイルの書き方さえ知っていれば、tree-sitter パーサのある言語なら何でも自由にアウトラインが設定できてしまうということです。
      • query ファイルの書き方については去年私がアドベントカレンダーで書いた記事などを参考にしてみてください。
    • なお、当初は新たに設定を書くとき aerial.nvim 本体のソースコードをいじる必要があったのですが、私が先日出した PR をマージしていただいたことにより、query ファイルの編集だけで済むようになりました。快くマージしていただいた stevearc さんに感謝いたします。

以前入れていた vista.vim はそこまで頻繁に使っていなかったのですが、aerial.nvim を入れてからかなり頻繁にアウトラインを表示するようになりました。検索が大変な、行数の多いファイルで特に重宝します。

現時点では以下のように半透明の floating window でアウトラインが出るように設定し、表示・非表示を簡単にトグルできるようにしています。


aerial.nvim によるアウトラインの表示

10. monaqa/dial.nvim

https://github.com/monaqa/dial.nvim

プラグイン紹介

<C-a> / <C-x> を用いた増減操作を拡張できるプラグインです。数値だけでなく、日付、 true / false などの定数、カラーコードなど、設定次第で様々なものを増減できます。
dial.nvim は Lua 製のため Neovim でしか用いることができませんが、denops を用いて実装した dps-dial.vim もあります(こちらは最近メンテナンスしていませんが)。

https://github.com/monaqa/dps-dial.vim

似た機能を持つプラグインとしては tpope/vim-speeddatingAndrewRadev/switch.vim などがあります。

感想

手前味噌シリーズその1です。ありがたいことにそれなりに多くの(主に海外の)ユーザの方に使っていただいているようです。ユーザの希望で実装した(当初入れる予定のなかった)機能もいくつかあるため作者自身が全機能を使いこなしているわけではないものの、日付・ true/false のトグル・マークダウンのヘッダレベルの変更などが手軽にできるのはやはり便利です。過去の自分に感謝ですね。

今年は少し日付周りの実装を頑張って整備し、より便利に使えるようになりました。

  • ユーザの好きなフォーマットが自然な形で指定できるようになりました。
    たとえば 2022/12/12(月)2022年12月12日 月曜日 といった文字列も、簡単に増減対象にできてしまいます。
  • 「1月31日の1ヶ月後は何月何日か/2月28日の1ヶ月後は何月何日か問題」の解決策の一つとして、新たに clampend_sensitive の2つを追加しました。
    • clamp オプションを有効にすれば、はみ出た日付が切り捨てられるようになりました。たとえば 2022/01/30 の1ヶ月後は以下のようになります。
      • clamp = false のとき: 2022/03/02(今まで通り)
      • clamp = true のとき: 2022/02/28
    • end_sensitive オプションを有効にすれば、増減対象の日付が月末のとき増減後の月の月末に移動するようになりました。たとえば 2022/02/28 の1ヶ月後は以下のようになります。
      • end_sensitive = false のとき: 2022/03/28(今まで通り)
      • end_sensitive = true のとき: 2022/03/31

将来的には nvim-treesitter との連携もしたいと思っていますが、実現の目処はまだ経っていません。そのあたりのサポートも実現して安定してきたら v1.0.0 を切ろうかなと思っています。

11. monaqa/modesearch.vim

https://github.com/monaqa/modesearch.vim

プラグイン紹介

Vim の検索を直感的に行うことができるプラグインです。生文字列で検索クエリを記述できる rawstr モードと、正規表現で検索クエリを記述できる regexp モードの2種類の検索プロンプトを提供します。

  • rawstr モードではすべての記号がその文字自身にマッチします。
    • つまり特殊文字が存在せず、 \/ も通常の文字として扱われます。
  • regexp モードでは多くの文字が正規表現パターンを表す特殊文字として扱われるようになります。
    • /\v で検索するのと同様に扱われます。

2つのモードは簡単にトグルできるため、途中から正規表現モードに切り替える、といったことも難しくありません。


modesearch.vim が動作する様子

なお、こちらは Vim script で書かれているため、Vim からも使用できます。

感想

手前味噌その2です。

かつて使っていた Atom というテキストエディタが、生文字列検索と正規表現パターンによる検索を一手で切り替えられて便利だったため、同じことを Vim でも実現したいとの思いで実装しました。去年の9月頃に作ったものですが、今も検索時にはこのプラグインを使っています。開発は1年以上放置してしまっていますが、まだ少し追加したい機能もなくはないので、ヘルプを追加して万人向けのプラグインとしたいと思っています。いつになるやら。

12. thinca/vim-partedit

https://github.com/thinca/vim-partedit

プラグイン紹介

Vim バッファの一部分を別のバッファに切り出し、自由に編集できるようにするプラグインです。

たとえば、以下のような markdown のテキストがあったとします。

以下の Python スクリプトを実行する。

```python
def main():
    pass


if __name__ == "__main__":
    main()
```

行ビジュアルモードでコードブロックの内部を選択し、その状態で :Partedit -filetype python とすると、コードブロックの中身だけが書かれた新たなバッファが開かれます。開いたバッファの filetype は python となっており、Python のシンタックスハイライトやインデントの設定はもちろん、各種プラグインや言語サーバも使える点が特徴です [8]。切り出したバッファは自由に編集でき、:w で保存するとその内容が自動的に元のバッファに反映されます。prefix 機能を使えばインデントやコメント開始文字などの共通部分を無視して切り出すことも可能です。

感想

実はそれなりに長い間「一部分を別のバッファに切り出し、自由に編集できたらいいな〜、そんな感じのプラグインを作ってみようかな」と思っていました。そんな折、vim-jp で partedit というプラグインがあることを教えていただき、使ってみたところまさに自分の需要にドンピシャで刺さりました。

上で挙げた例に限らず、様々な場面で使えます。以下は私が実際に使っているユースケースです。

  • いろいろな言語 in Markdown
    • Markdown のコードブロックの中身を編集できます。
  • Markdown (or reStructuredText) in Python
    • Python の docstring を Markdown や reStructuredText で書く際に役立ちます。インデントを揃えるのに腐心する必要はもうありません。
  • Markdown in Rust
    • Rust の doc comment は Markdown で書かれるのですが、こちらも同様にストレスなく記述することができます。

ちなみに私は現在上のプラグインをフォークし、g:partedit#prefix_pattern というオプションを追加して使っています。

https://github.com/monaqa/vim-partedit

作者の thinca さんに「もうすぐ PR 出します!」と言ってしまったんですが、師走の忙しさによってまだ出せていません(主にアドベントカレンダー)。すみません、クリスマスまでには出すのでもう少しお待ち下さい。

終わりに

紹介しなかったものの中にも毎日のように活躍しているプラグインはたくさんありますし、オープンソースで公開されている全てのプラグインはあまねく素晴らしいものです。皆さんもぜひ、様々なプラグインを使ってみてください。来年も素敵なプラグインに恵まれますように。

脚注
  1. Neovim では下の記事で紹介されているプラグインマネージャに加え、 packer.nvim や paq.nvim といった Lua で記述する前提のものもあります。 ↩︎

  2. 「無人島に Vim と Vim プラグインを1つだけ持っていけるとしたら何を持っていきたい?」という、ベタな話題の回答候補となるプラグインのこと。皆さんも一度は考えたことがあると思います。 ↩︎

  3. 個人の感想です。 ↩︎

  4. ただし、これについては個人の設定ファイルで定義すればよいのであまり困っていません。 ↩︎

  5. GitHub のアカウント名がそのままカラースキーム名になっているようです。 ↩︎

  6. というよりも、入れていたことを最近まで忘れていました。 ↩︎

  7. README に大きく "Please consider the experience with this plug-in as experimental" と書いてあるのでそれ自体を責めるつもりはありませんが、ハイライトグループ変更の一件についてはもう少しユーザの混乱を防ぐ道もあったのでは、と思わなくもありません。 ↩︎

  8. 実際にファイルとしてどこかに保存されるわけではないため、言語サーバによっては使えないものがあるかもしれません。そこは言語サーバ自体の実装にもよるため注意が必要です。 ↩︎

Discussion