使い込んで厳選したNeovimプラグインたちをご紹介します
はじめに
筆者はこれまで、定期的にVimのプラグイン紹介の記事を定期的に投稿していたのですが、2019年のVim AdventCalenaderに投稿したNeovimでモダンなPython環境を構築するv2(LSPを添えて)以降、ほとんどプラグイン紹介記事を執筆していませんでした。
他のかたの記載されるNeovim環境構築記事を見るたびに、筆者も自分の環境を紹介したいと常々思っていました。
- ワシの使っているNeovimプラグインは200個近くあるぞ
- vim沼: NeovimのReact、TypeScript、Tailwind CSS用セットアップ
- Neovimでのフロントエンド開発環境 2022
しかしNeovim v0.5のリリース以降、増え続けるluaプラグインの洪水に飲まれ、筆者のNeovim環境はプラグインを入れては消しを繰り返し、安定しない日々を過ごしていました。
最近になって筆者のVim熱が急激に高まったこと、lua製の新プラグインの登場もある程度おちついてきたことなどがあり、ようやくある程度煮詰まったなという状態になったため、ここで紹介いたします。ただし、この記事執筆中もプラグインを入れたり消したりしているので、一ヶ月後にはまた違う構成になっているかもしれません。
前提条件
筆者のNeovimの用途及び前提条件は以下の通りです。
- Neovimの導入プラグイン数は記事執筆時点で81プラグイン
- 基本的には80前後になります。筆者が認識できるプラグインの限界が70~80程度と推察されます
- Neovim以外のエディタは使わない
- 基本的にブラウザとSlackとターミナル(Wezterm)以外のアプリケーションは利用しない
- 業務ではフロントエンドとバックエンド両方を書きます
- フロントエンドはTypeScript+React
- バックエンドはGolang
- 作業メモのためにmarkdownを編集することが多い
今回紹介するプラグインについて
- Neovimのプラグイン紹介ということでLua製のプラグインを多めに紹介します
- プラグインを選ぶ過程で、筆者が選ばなかったプラグインも併せて紹介します
- 筆者の用途にはアンマッチという意味で優劣の指標にはなりません
UI拡張プラグイン
Vim標準のUIを拡張するためのプラグインです。
筆者はUI系のプラグインはVimをかっこよくするためではなく、視認性を高めるために入れるというポリシーでいます。また設定が肥大化すると他のプラグインへの移行などが困難となるため、過度なカスタマイズをしないようにしています。
nvim-lualine/lualine.nvim
筆者のステータスラインの見た目
lualine.nvimはステータスラインをカスタマイズするプラグインの中で大きなシェアを得ており、もしステータスライン系のプラグインを入れていなければ、ここから始めることをおすすめします。速度は早く、機能は充実しています。
多くのユーザーが利用していることには大きな利点があります。lualine.nvim導入後、さらに拡張するための豊富なレシピがコミュニティによって作成される点です。例えば私は非同期ランナーのoverseer.nvimの実行ステータスをlualine.nvimで表示するようにカスタマイズをしていますが、表示用のスクリプトを自分で考えるということはしていません。overseer.nvimの公式サイトに、lualine.nvimで表示するならこうすると見られるという既存のレシピが存在しているからです。
lualine.nvim以外のlua製の類似プラグインには以下ものがあります。これらのプラグインはlualine.nvimを使った上で、もっとこういうものがあれば、という気持ちを持った作者が作ったものもあるので、以下のプラグインのほうがマッチするという方もいらっしゃると思います。
nvim-neo-tree/neo-tree.nvim
ファイラーを表示している様子
neo-tree.nvimはlualine.nvim同様にNeovimのファイラープラグインの中でも人気の高いプラグインです。IDEやVSCode備わっている以下のような要件のファイラーをVimに導入したいユーザーは、neo-tree.nvimを使えば満足をするはずです。
- 左側に常駐するファイラーが欲しい
- ファイルをツリーのように展開する挙動をしてほしい
- Gitによる差分を表示してほしい
- 構文エラーなどがあったら表示してほしい
もっとミニマルなものを使いたいという方はoil.nvimなどがマッチするかもしれません。筆者もoil.nvimのバッファー操作の結果を実ファイルに反映する。というファイル編集方法には興味があり、近日試してみたいと考えています。
shellRaining/hlchunk.nvim
hlchunk.nvimでchankを表示している様子
hlchunk.nvimはインデントガイドを表示するプラグインです。同ジャンルではindent-blankline.nvimが長らく人気を博しており、筆者も長らくindent-blankline.nvimを使用していました。
しかしインデントガイドを導入しても、まだ見づらい。言語化はできないという状態が続いていました。そんなときhlchunk.nvimのchunk表示を見たとき衝撃をうけました。
筆者が欲しかったのはインデントガイドではなく、カーソル下にあるインデント位置を即座に確認できる目印。ということに気が付きました。また対応カッコがないなどのエラーが発生したときに赤く表示されるのもGoodです。
導入して1,2ヶ月経過しましたが、効果は大きく、ひと目で今いるインデントがどこなのか、対応するカッコがどこなのかが見えるようになりました。
これ関係で視覚を強化するプラグインですとrainbow-delimiters.nvimなどがあります。こちらも合わせて確認してみてはいかがでしょうか？
kevinhwang91/nvim-hlslens
nvim-hlslens導入した状態で検索している様子
nvim-hlslensは/(スラッシュ)や*(アスタリスク)による文字列検索のとき、ヒット総件数と選択中の結果が総ヒット件数中何番目か(以下ヒット件数と略)を表示してくれるプラグインです。
すこし分かりづらいかもしれませんが、Vimのヒット件数は、検索実行時にコマンドラインの右に表示されています。しかしこの表示は、検索をまさに実施しているコード中からかなり離れた位置になってしまうため、ヒット件数を確認するには視線の移動が大きくなりすぎてしまいます。
バニラ状態のNeovimで検索している様子。右下にヒット件数が表示されている
nvim-hlslensを導入すると、ヒット件数がヒット文字列の右端にVirtualText(編集できない文字列をエディタ中に表示させるNeovimの機能)で表示されるようになります。その程度と思われるかもしれないのですが、この効果はかなり大きく、使ってみればヒット件数の視認性が格段に上昇することがわかります。
標準のキーバインドを上書きするようにキーバインドを設定する必要があるため、vim-asteriskが使えなくなるという懸念があるかもしれませんが、併用もできるように設計されているため、ご安心ください。
romgrk/barbar.nvim
barbar.nvimによってバッファがタブ表示されている様子
barbar.nvimは現在開いているバッファー(Vimがファイルを開いたときにメモリに編集用に保持する情報)をタブとして常時表示するプラグインです。
おなじ思想をもつプラグインはVim script製のプラグインでもvim-bufferlineを始めとしてかなりの数があります。
lua製だと他にはbufferline.nvimがあります。
またlualine.nvimなどのステータスライン装飾系のプラグインおいても、同様の表示をするための機能があります。つまりかなり需要の高い機能であるということです。
barbar.nvimとbufferline.nvimはそれらの類似の機能に比べて非常に多機能になっています。
- ファイルの拡張子に合わせてdev iconが表示される
- マウスによる操作ができる
- Gitの差分をタブに反映できる
- Diagnostics(lintエラーなどプラグインを横断して使うためのNeovimの機能)を反映できる
barbar.nvimとbufferline.nvimを比較するとbufferline.nvimはカスタマイズ製において軍配が上がる印象です。細かく設定を変更する方や機能拡張をするという方はこちらをチョイスすると良いと思います。
筆者の場合、凝ったカスタムをしないため、デフォルトの時点で好みの見た目のものという観点で選んでいます。
kazhala/close-buffers.nvim
close-buffers.nvimでバッファを閉じる様子
close-buffers.nvimはバッファを一括してとじるコマンドを提供するプラグインです。Vimのバッファ操作コマンドをより便利にしたものです。
barbar.nvimのようにバッファをタブに常時表示するようになると、バッファを整理したいタイミングがあります。筆者は表示バッファが12個あたりをこえると、開いているバッファを把握できなくなるため、Vim自体を終了させてバッファをリセットしていました。しかし、Vimを閉じれば、再度Vimを起動したとき、開いていたファイルを再度開いたり、LanguageServerの起動を待ったりとロスが大きいのです。
close-buffers.nvimを使うことでバッファの整理を快適に行えます。と言っても筆者が利用するのは2通りだけで、現在開いているバッファーを閉じる。現在開いているバッファー以外をすべて閉じるという操作だけです。
kevinhwang91/nvim-bqf
nvim-bqf導入した状態でQuickFixにカーソルを合わせている様子
nvim-bqfを導入すると、Quickfixのカーソル下にある要素をプレビュー表示するウィンドウを追加できます。これによりQuickFixの該当箇所を開くことなく確認できます。
筆者はgrepした結果をquickfixに表示し、<C-n>および<C-p>にキーバインドしたquickfix移動でコードを眺めるということをよくするのですが、この操作をすると検索結果のファイルが軒並みバッファになってしまうという欠点があります。前述したとおり、編集する必要のないバッファが増えると認知負荷になるため、close-buffers.nvimで消す必要があります。
しかしそもそもとして、編集しないものをバッファに乗せないで確認するという方法があれば、この問題は解決できます。
folke/which-key.nvim
which-key.nvimのナビゲーションを表示する様子
which-key.nvimを導入することで、複数キー(２打のストロークが必要な)のキーバインドのナビゲーションを表示できます。
おそらく多くの方が<Space>や<Leader>、gや[]などに自分の独自キーを組み合わせたキーバインドを割り当てしていると思いますが、設定したキーバインドを忘しまう。さらに入れたままプラグインを使用していない。という経験はないでしょうか？
筆者も80近くプラグインを入れており、なかには3日に1回程度しか使わないキーバインドがあり、いざ使おうとしたとき、キーバインドを忘れたのでコマンドから呼び出すことがままあります。そんなときこのwhich-key.nvimがあれば安心です。
プラグインによってはセットアップ時、デフォルトのキーバインドを設定しますが、そういったキーバインドを含めて把握できるため、導入済みのプラグインの利用の促進に繋がります。
UI拡張プラグイン他に紹介したいプラグイン
以下のプラグインはどれも有効なものですが、比較的新しいNeovimのオプション利用しが前提になっていることや、Vimのデフォルトから離れた挙動になることから、これまでのVimの当たり前であった挙動がかわります。
そのため筆者としては導入のハードルが高く見送ったものです。もっとVimの外観を突き詰めたいという方は一度チェックしてみてはいかがでしょうか？
petertriho/nvim-scrollbar
nvim-scrollbarはVimにスクロールバーを追加するプラグインです。スクロールバーを表示することに加えて、検索結果のヒット箇所や、Diagnosticsの位置表示などもできます。
筆者がこれを外した理由は、シンプルに現在位置を視覚的に把握することのプライオリティが筆者にとって高くなかったため、スクロールバーがあってもなくても編集に影響がなかったからです。
また、FloatingWindowなど、スクロールが不要はバッファーなどについてもすべてスクロールバーが表示されるため、個人的にはノイズになることが多かったこと、ノイズを減らすために、個別に非表示にするための設定が煩雑になったことも要因の一つです。
folke/noice.nvim
noice.nvimはVimの下部コマンドラインビューに表示されるメッセージをvscodeライクな通知ウィンドウで表示するしたり、コマンドモードの入力をvscodeライクなコマンドパレットにできます。
通知ウィンドウはこれまで作業をブロックしていたメッセージ表示を通知ポップアップで視覚的にわかりやすくなりますし、コマンドモードの入力がウィンドウ中央に表示されるのは視覚的に実にメリットがあり、おしゃれでありつつも実益のある非常に優秀なプラグインです。
しかし筆者にはこれまでコマンドウィンドウに表示されていて目立たなかった各種メッセージが、ポップアップ表示されることと、不必要なメッセージをフィルタリングする設定が必要になってしまったことや、コマンドモードの入力が中央になったことに馴染めずに外すことにしました。
余談ですが、cmdheight=0とこのnoice.nvimを導入すればコマンドウィンドウを全く必要としないcoolなVimが完成します。
b0o/incline.nvim
incline.nvimの説明のためには、:set laststatus=3の話をしなくてはなりません。このオプションは、これまでウィンドウごとに表示されていたステータスラインを一つに統一するためのオプションです。
「今NeovimのHEADに入った :set laststatus=3 でステータスラインが１つになるのむっちゃいい！ 画面がシンプルになってむっちゃかっこいい！！」 / X
とある PR のおかげで Neovim がもはや VSCode な件について
ステータスラインのグローバル化によってzenの心に目覚めたVimmerたちによって、シンプルなVimが追求されてきました。そんな中、やはり現在開いているウィンドウにファイル名が紐付いている方が見やすいという要望が新たに生まれました。そんなプラグインの一つがこのincline.nvimです。ウィンドウにFloatingWindowによるファイル名を付加するというもので、その見た目はcoolの一言。
しかし、筆者は最終的にそうするなら普通にステータスラインを個別につけたほうが良いのではという結論に至り、:set laststatus=2に戻し、incline.nvimを外しました。
コーディング
コーディング。つまりプログラムを書く上で必要になるプラグインを紹介します。
numToStr/Comment.nvim
Comment.nvimでコメントを付け外ししている様子
Comment.nvimは現状のコメント系のluaプラグインで最も人気の高いプラグインです。個人的に、コメントプラグインでできることに大きな差分はないと考えているため、特段のこだわりがなければComment.nvimを利用するのが良いと感じています。
筆者の場合、このプラグインに加えてtsx形式のコメントをするためにnvim-ts-context-commentstringを導入し、Comment.nvimと連携するようにしています。
stevearc/overseer.nvim
overseer.nvimは汎用的なタスクランナーです。makeなどのビルドツールを実行し、失敗などがあればQuickFixやDiagnosticsとして表示するという機能を備えています。またタスクの実行履歴を備えており、一番最後に実行したタスクを再実行するといった操作も可能です。
筆者はVimデフォルト組み込みのgrepコマンドとmakeコマンドをよく使っており、プラグインなしで実行できる点は大きなメリットでした。
しかし、実行中にVimがブロックされるのはあまり良い体験ではありません。grepは数十ミリ秒で終わるのでいいのですが、makeで呼び出しするbuildやlintは2,30秒程度Vimをブロックします。長らく我慢しながら使っていたのですが、重い腰を上げてoverseer.nvimを導入したところ、格段に体験が向上しました。また基本的に非同期でプログラムを実行するだけのもののため、プログラム検証用のランナーとしても活用できます。
非常に便利なプラグインなのですが、入れれば使えるというタイプのプラグインではなく、かなりカスタマイズが必要なプラグインになります。公式に豊富なレシピが公開されているとはいえ、とりあえず非同期でプログラムを実行したいといった要件であれば、他により適したプラグインがあると感じます。
例えば書いたコードの動作確認であれば以下のプラグインのほうが簡単に導入できると思います。
自動補完(Auto Compelte)
hrsh7th/nvim-cmp
lua製の自動補完のプラグインはnvim-compeおよびその後継であるnvim-cmpが長らく高い人気を誇っています。一方で関連するソースをプラグインするという発想や、スニペットを展開するための選択肢が多数存在しているという点から、複雑に見えるかもしれませんが、必要に応じてカスタマイズできる柔軟性を持っていると言えます。cmp-cmdlineによってコマンドライン上で自動補完がなされているのをみて筆者は感嘆したものです。
以下に筆者が導入しているcmp関連およびcmpのソースのために導入しているプラグインを例示します。こうして見てみると多いですね。
| プラグイン | 説明 |
|---|---|
| f3fora/cmp-spell | 英語入力時のスペル補完ソース |
| hrsh7th/cmp-buffer | バッファ中に存在するキーワードの補完ソース |
| hrsh7th/cmp-cmdline | コマンドライン入力中の補完ソース |
| hrsh7th/cmp-nvim-lsp | LSP経由で提供される関数や変数などの補完ソース |
| hrsh7th/cmp-path | ファイルパスの補完ソース |
| onsails/lspkind.nvim | 補完候補にアイコンを追加するプラグイン |
| saadparwaiz1/cmp_luasnip | LuaSnipから取得したスニペットの補完ソース |
| L3MON4D3/LuaSnip | スニペットの取得およびスニペット展開後の編集制御をするプラグイン |
| rafamadriz/friendly-snippets | LuaSnipから読み取りするスニペット集 |
| zbirenbaum/copilot-cmp | Copilotの出したコードを補完として提供する補完ソース |
| birenbaum/copilot.lua | Copilotクライアント |
スタイルによりますが、オールインワンでIDEのような操作を可能にする。LSクライアントと補完は完全に同一で良いのでとりあえずVimをIDEのような強力な補完を備えたエディタにしたいという方であればcoc.nvimが有力な候補になります。
LanguageServerクライアントはnvim-lspを使いつつ、補完をしたいという方であればnvim-cmp以外には以下の選択肢があります。
- ms-jpq/coq_nvimは高速。かつ単体で普段使いするのに十分なソース(LSP補完やバッファ補完、スニペットなど)を予め備えています。単体で済ませたいという方にはマッチする可能性があります。
- mini.completionはよりマイクロな実装で良いという方にマッチするかもしれません。
- ddc.vimは暗黒の力が得られます。
編集強化
ソフトウェアエンジニアがするべき仕事は本質的には思考することであると筆者は考えます。コードを書く時間は短ければ、思考する時間が増えます。つまりコードを書く時間を短縮することはソフトウェアエンジニアの仕事をより本質に近づける行為なのです。
machakann/vim-sandwich
vim-sandwichはテキストオブジェクトの拡張プラグインです。
Vimの設定をVim scriptからluaに書き換えした際に、lua製のプラグインをできるだけ採用にするようにしたのですが、このプラグインは今でも利用しているVim script製プラグインの一つです。saから始まるキーバインドが体に染み付いている。かつ動作に不満がほぼないため、使い続けています。
lua製の類似プラグインだとnvim-surroundが挙げられます。
RRethy/nvim-treesitter-textsubjects(以下textsubjectsと呼称)
textsubjectsで選択する様子
textsubjectsはtree-sitterを活用して、コード文脈に沿って選択範囲を拡大することができます。
nvim-treesitter-textobjectsは設定するキーバインドが大量にあることや、選択されるスコープが直感的でないと感じており、それと比較したときtextsubjectsは覚えるキーバインドも2,3個で済むうえ、選択されるスコープも直感的であるため、非常に使いやすいプラグインです。
他の類似プラグインとしてはwildfire.nvimがあります。textsubjectsと両方を使用してみましたが、textsubjectsのほうがスコープの広がり方が筆者の好みであることから採用しています。人によってはwildfire.nvimのほうが好みという方もいらっしゃると思います。
Wansmer/treesj
treesjでsprittingとjoiningする様子
コードを書いているとき、とても人間がやるべきではない編集に出会うときがあります。splitting/joiningはまさにその典型で、コードの意味を変えずに複数行を一行に、一行を複数行にすることを指します。
treesjはそういったsplitting/joiningをコマンド一つで実行する機能を提供します。tree-sitterにて文脈を考慮して編集するため、正しく動作します。
monaqa/dial.nvim
dial.nvimでtrueとfalseを切り替える様子
dial.nvimは通常の<C-a>と<C-x>の拡張です。
デフォルトに備わっている数値のインクリメント、デクリメントに加え、年月日や曜日など人間ならこれインクリメントできるものをVimでもインクリメントできるようにしてくれます。
筆者としてはtrueとfalseの切り替えは管理便利で、それだけのために入れても良いと感じます。
またマイナス付きの数字を<C-a>と<C-x>するとVimのデフォルトは符号を考慮したインクリメントとデクリメントします。一方でdial.nvimは符号を無視して処理をするのが、さりげないですが嬉しいポイントです。
Git
仕事としてプログラムを書く行為とGitの操作は不可分といえます。それだけにGitのプラグインにおけるプログラミング作業の影響度は非常に大きなものになります。
lewis6991/gitsigns.nvim
gitsigns.nvimによるGitの差分表示
gitsigns.nvimはGitの差分をgutter(ウィンドウごとに表示される左端の表示)に表示するプラグインです。lua製のプラグインの中で言えば圧倒的なシェアを誇っておりディファクトスタンダードといって差し支えないと思います。
また表示だけではなく、ステージやアンステージなどのGit操作が可能です。筆者の場合、表示バッファのGitの差分を移動するnext_hunkとprev_hunkはかなり利用しますし、時点で差分を意識から外すためにVim上から差分をステージ(stage_hunk)したり、不要な差分をリセット(reset_hunk)します。
sindrets/diffview.nvim
diffview.nvimによる差分表示
diffview.nvimはGitの差分表示を確認するための特殊ビューを提供します。筆者は過去消したコードを復元するときなど過去のコードからコピーするシチュエーションでよく利用します。
筆者は多くのGit操作をtigコマンドに行いますが、前述したシチュエーションでstarge/unstageの差分のコードや、過去参照したコードをtigのようなTUIアプリケーションから取得するのは難しいからです。なぜなら表示のための余分な付加情報もまとめてコピーしてしまうためです。
tigによる差分表示
筆者は主にDiffviewOpenコマンドでstarge/unstageの差分のコードを、DiffviewFileHistoryコマンドで過去差分のコードを参照およびコピーします。
akinsho/toggleterm.nvim
toggleterm.nvimでtigを表示している様子
toggleterm.nvimは、現在開いているウィンドウの上にFloatingWindowでターミナルを重ねて表示するプラグインです。Git関連のプラグインではありませんが、筆者がtigコマンドVim上でレイアウト変更せずに実行するために利用しているため、このカテゴリに置きました。
筆者はGit差分のstageからcommitまでのワークフローをtigで行うのですが、toggleterm.nvimを使用することで、Vimから離れずにtigを使えます。筆者はターミナルでtigを利用するときtmuxのpopupを使っているのですが、toggleterm.nvimを使えばでVimでtigを起動したときとターミナルでtigを起動したときで、ほぼ同じ見た目になる点も気に入っています。
tmuxのpopupでtigを表示している様子
VimからGitを利用するという観点では、以下のようなプラグインが存在しています。もしVimだけでGit操作を完結させたい。という方がいらっしゃれば、これらのプラグインが適合するかもしれせん。
余談ですが、筆者は速度面の問題からtigコマンドをlazygitないしgituiに変えようと何度か試していますが、 操作感が馴染めず必ずtigに戻ってきます。もう少し高速なtigがあれば、乗り換えるのですが。
もしlazygitをお使いの方がいらっしゃれば、lazygit.nvimが似たようなワークフローに適用できるかもしれません。
ahmedkhalf/project.nvim
project.nvimはgitのプロジェクト配下のどこで開いてもgit rootに自動でcdしてくれるプラグインです。
linrongbin16/gitlinker.nvim
gitlinker.nvimはVimで開いたコードをベースにGitHubなどのGitホスティングサービス上のリンクを取得するためのプラグインです。
筆者はレビュー時に参考コードを例示するシチュエーションなどでGitHubのURLを取得して共有します。gitlinker.nvim導入以前。以下の3ステップでリンクを取得していました。
- Vimで該当コードをヴィジュアルモードで選択する
- open-browser-github.vimでGitHubのページを開く
- ブラウザからURLをコピーする
これがgitlinker.nvimの導入により以下の2ステップになります。減ったのは1ステップですが、ブラウザのページローディングを待たなくてよくなったため、速度的には2倍以上早くなっています。
- Vimで該当コードをヴィジュアルモードで選択する
-
GitLinkコマンドでGitHubのURLをクリップボードにコピー
lsp
neovim/nvim-lspconfig
nvim-lspを使う上で必須のため、省略します。
nvimdev/lspsaga.nvim
lspsaga.nvimでcode actionを使用している様子
lspsaga.nvimはnvim-lspの標準機能の拡張コマンドを提供します。
筆者は可能なかぎりnvim-lspconfigに組み込みされているコマンドで対応するポリシーで設定をしていますが、nvim-lspconfigの挙動で使いづらいと感じるものが2つあります。それがCodeActionとGotoDefinitionです。
CodeActionは複数候補があるときに番号をコマンドに入力する必要性があり、直感的ではありません。
nvim-lspのデフォルトでcode actionを使用している様子
GotoDefinitionは一見問題がないように見えますがtypescript-language-serverのジャンプの場合、複数のジャンプ対象が表示される場合などがあり、そのようなとき、QuickFixないしLocationListに表示するという挙動になるため、テンポが悪くなっています。
また現在カーソルがどのスコープに位置しているかを判断するためにsymbol_in_winbarを使っています。
類似のプラグインとしてnvim-lsputilsなどがあります。
j-hui/fidget.nvim
fidget.nvimのローディング
fidget.nvimはLanguageServerの起動など処理中を表示するためのプラグインです。LanguageServerはVimが起動してから動作するまでの間、数秒かかるため、LS依存の操作がいつ可能になるのかを確認するのに役立ちます。
このプログレス表示がおしゃれかつ実用的なため、バックグラウンドで動かす系統のプラグインのISSUEでfidget.nvimのようなプログレス表示はできないのかという要望があるのをしばしば見かけます。
stevearc/aerial.nvim
aerial.nvimでアウトラインを表示している様子
aerial.nvimはコードのアウトラインナビゲーションを提供するプラグインです。
コード中に存在するクラスや関数などのシンボルの一覧を表示するビューや、シンボルジャンプなどを提供します。
aerial.nvimはシンボルを取得するためにLSP以外にもtree-sitterなども参照するため、様々な環境において柔軟にアウトラインを提供することが可能です。
筆者はaerial.nvimのアウトラインビューはもちろんのこと、シンボルジャンプのAerialNextとAerialPrevやTelescopeのソースを使っています。
類似のプラグインとしてはoutline.nvimがあります。筆者はシンボルジャンプの挙動がaerial.nvimのほうが好みであるため、aerial.nvim使っています。
stevearc/conform.nvim
LanguageServerによりますが、textDocument/formattingに加え、更にツールで追加のフォーマットをするシチュエーションがあります。筆者も実際にJavaScript/TypeScriptはフォーマッターとしてPrettierやBiomeを利用しています。
conform.nvimの嬉しいポイントはLanguageServerのフォーマットを実行した上で、それらの外部フォーマッターを適用してくれるという点です。
mfussenegger/nvim-lint
conform.nvimのケースと同様にLanguageServer単体のdiagnosticsですべてのLintは実行せず、追加でLinterを実行するというシチュエーションは少なくありません。筆者の場合も、JavaScript/TypeScriptであればESlintやBiomeを実行するでしょうし、Golangであればgolangci-lint.を実行しています。
Formatter/Linter系プラグインで他に紹介したいプラグイン
nvimtools/none-ls.nvim
私はnvim-lintのほうが挙動が好みだったため、nvim-lintにしていますが、筆者のこのチョイスはマイノリティの部類にあると感じているため、ここは逆にnone-ls.nvimをおすすめします。
nvimdev/guard.nvim
markdown
私は作業メモなどをすべてmarkdown形式で残すようにしているため、いくつかmarkdown編集を便利にするためのプラグインを入れてます。
ixru/nvim-markdown
nvim-markdownでbulletが自動挿入される様子
Vim script製でvim-markdownというmarkdownのSyntaxとキーマップの拡張をしてくれるプラグインがあったのですが、それのlua版です。
Vimのデフォルトだとmarkdownを操作しづらい要素がいくつかあり<Plug>Markdown_NewLineAboveや<Plug>Markdown_NewLineBelowなどbullet(-ハイフンや*アスタリスクなどのリスト表示の接頭語)入力中に改行したとき、インデントを揃え、かつ自動でbulletを入力してくれる機能は欲しいところです。
vim-markdownにない機能だと、<Plug>Markdown_FollowLinkなどリンク形式になっているURLにジャンプする機能は多用します。ノーマルモードgxでもジャンプできますが、gxはURL自体を選択する必要性がある
のですが、このコマンドはリンク形式のタイトル部分からもジャンプできるのがGoodです。
MeanderingProgrammer/markdown.nvim(render-markdown)
Vimでmarkdownで開いたとき、最終的なレンダリング結果と違い若干の見づらさを感じることはあると思います。そういった見づらさを軽減するためのプラグインです。
類似のものにheadlines.nvimがあります。もともと私はheadlines.nvimを使っていたのですが、インサートモードでもおしゃれレンダリング状態になるため、編集しづらさを感じていました。特にヘッダー。もしかしたら設定でいじることもできたのかもなのですが、そのオプションを探すより先にrender-markdownを見つけ、こちらに変更した次第です。
telescope
telescope.nvimについて、ほぼNeovimにおける選択的フィルターのディファクトなので今更紹介する必要性があるかと思ったのですが、一つあまり知られていなさそうなものを入れているのでここでご紹介します。
prochri/telescope-all-recent.nvim
筆者にとってのTelescopeは、UIや速度という面において十分に完成された選択的フィルターでした。
絞り込みの対象となるソースについてもデフォルトの時点で必要十分なものがあり、追加のソースを入れる必要性もありません。不満があるとしたら、ユーザーの使用頻度が高いものを優先度つけし、優先度順でソート変更できるようなものがないという点のみです。
Vim駅伝の2024/03/27にtadasi-aikawaさんが投稿されたあまり紹介されていないけど かけがえのないNeovimプラグインたちの中にあるsmart-open.nvimの紹介にある以下の一節があることから、他にも同じ意見を持っている方がいそうです。該当記事は面白いため、閲覧を推奨します。
:Telescope find_filesはカレントディレクトリ配下をファイル名で検索する機能ですが、現在開いているファイルの場所や最後に開いた/編集した時間などが考慮されないと思います。ファイル名で検索したいときは便利ですが、『最近開いたアレ』とか『このファイルと同階層のアレ』みたいなときは少しもどかしいときがあります。
このユーザーの使用頻度に応じたファイル一覧を見たいという要望から、telescope-frecency.nvimというソースも開発されています。このプラグインはFrecencyアルゴリズムを用いて、閲覧ファイルにスコアリングをし、そのスコアをもとにファイルをソートするというものです。
telescope-frecency.nvimを導入して試したものの、筆者のGitプロジェクトのファイルのソートにFrecencyアルゴリズムでつけたソート順を適用したいという要望を叶えるためには:Telescope frecencyにworkspace=CWDオプションを追加する必要性がありました。このオプションを適用すると、数秒程度のラグが発生するため、私が試した時点では実用的ではありませんでした。
そんななかで見つけたのが、telescope-all-recent.nvimです。
telescope-all-recent.nvimが優れている点は、git_filesなどの現状のtelescopeのソースに対してそのままrecency/frecencyソートを適用してくれるという点です。これにより、既存のキーバインドを変えないまま、ソートアルゴリズムの恩恵を得られます。
Discussion