Neovimへのラブレター
(caio.ca)- Neovimは、コード編集を単なる高速タイピングではなく、移動、変更、削除、再構成、テスト確認へと続く反復ループとして扱えるようにする
- Vimの編集文法は、
ci\"、dap、.、マクロ、テキストオブジェクトのように意味単位の操作を組み合わせ、反復編集の摩擦を減らしてくれる - Neovimはエクスプローラー・ターミナル・Gitパネルを強制せず、バッファを中心に Telescope、Fugitive、LSP などをユーザーが選べるようにしている
- 設定はGitに入ったファイルとして所有でき、シェル・tmux・ripgrep・git・language serverと連携するシステムの一部として残る
- Lua、内蔵LSP、Treesitter、Lazy.nvimによって現代化されたが、核となる価値は、学んだ動作が長く積み重なり、ワークフローそのものが自分で進化していく点にある
VimからNeovimへと続く作業感覚
- Vimを使い始めたのは2011年で、最初の頃は
.vimrcをコピーしたり、jが文字を入力せずカーソルを動かす理由すら理解していなかった - 最初の1週間はつらく、最初の1か月は違和感があったが、Vimのモデルに慣れてからは、他のエディタはコードと自分の間に緩衝材があるように感じられた
- VS Code、JetBrains IDE、Sublime、Atom、Zed など多くのエディタを使ってきたし、JetBrainsのツールは非常に強力で、VS Codeはほとんどの人にとって十分によく、拡張しやすいため成功している
- それでもNeovimを使い続ける理由は、自分の作業の進め方に合わせて動き、コード編集の反復ループを直接支えてくれるからだ
編集をショートカットではなく言語として扱う方法
- コード編集は速くタイピングすることではなく、移動、小さな変更、まずい抽象化の削除、関数の再構成、ファイルの移動、テストや診断の確認を繰り返す作業に近い
- ほとんどのエディタはテキストを文書として、キーボードを入力装置として扱うが、Vimは編集を文法 (grammar) のように扱う
ci\"は引用符の中身を変更し、dapは段落を削除し、.は直前の変更を繰り返す- マクロは小さな手順を一度教えればファイル全体に繰り返し適用でき、テキストオブジェクトは文字数ではなく意味単位に対して操作を行えるようにしてくれる
- Vimの文法が手になじむと、マウスでコードをドラッグしたり、サイドバーをクリックしたり、毎日何十回も行う作業のたびにコマンドパレットを開いたりすることが減る
- よく行う作業は小さく直接的な動きになり、エディタのノイズも減っていく
ワークフローを強制しないNeovim
- GUI中心のエディタは、エクスプローラー、ターミナル、Gitパネル、デバッガの位置や形に対して固定的な見方を持ちがちで、時間がたつとエディタがコックピットのようになっていく
- Neovimはバッファから始まり、その周囲に何を置くかはユーザーが決める
- ファイルツリーが必要なら追加できるし、あいまい検索は Telescope や fzf-lua のように自分に合うツールを選べる
- Git統合には Fugitive を使えるし、LSP、診断、フォーマット、スニペット、Treesitter、テストランナー、自動補完も、重いElectronダッシュボードのように変質することなく扱える
- 速度は起動時間だけではなく、信頼の問題でもある
- キーを押したら即座に反応しなければならない
- 大きなファイルを開いてもUI全体が引っかかってはならない
- SSH接続、tmuxでのペア作業、小さなターミナルウィンドウでの修正でも、毎日使うエディタとしての感覚が保たれていなければならない
- ローカルのプロジェクトでも、リモートサーバーでも、素早い設定変更でも、大きなRailsアプリでも、小さなシェルスクリプトでも、Markdownの執筆でも、同じ移動、同じコマンド、同じ筋肉の記憶を使える
- この一貫性はキャリア全体を通して蓄積されていく
所有できる設定と、システムの一部として残る道具
- Neovimの設定はGitに入ったファイルなので、自分で読み、壊し、不要なプラグインに気づいたら半分を削除することもできる
- 謎めいた設定データベースや、半分しか理解していない同期アカウントの状態、数リリース前のチェックボックス変更のせいでバックグラウンドで妙な動きをする拡張機能に依存しない
- 現代のエディタの多くは、あらゆることが起こる場所になろうとするが、Neovimはより大きなシステムの鋭い一部であることに満足している
- シェルを置き換えようとはせず、tmux、ripgrep、git、language server、formatter、linter、test runner と連携して動作する
- 机全体を支配する必要がないことも、Neovimが長く続いてきた理由の1つだ
- 2011年以降、多くのエディタ、拡張エコシステム、テーマ、マーケットプレイス、AIパネルが現れたが、Vimはすでに古い道具であり、Neovimは人々が重要だと考えた理由を捨てることなく、必要な部分だけを現代化した
現代化と、長く続く学習への報酬
- Luaは設定をより良くし、プラグインエコシステムも大きく改善した
- 内蔵LSPはIDEの機能をエディタにもたらしつつ、肥大化した感じを与えない
- Treesitterはシンタックスハイライトとコード認識を現代的なものにし、Lazy.nvimはプラグイン管理を高速かつシンプルにした
- Neovimの中核的な魅力は、時間がたっても学んだことが使い続けられる点にある
- 1つの motion を覚えれば、ずっと役に立つ
- マクロを書けば、退屈な編集が消える
- テキストオブジェクトを知れば、面倒なリファクタリングが簡単になる
- 1つのコマンドを調整すれば、手の一部になる
- エディタは、会社が新しいサイドバーを出したから良くなるのではなく、ユーザーがよりうまく扱えるようになることで良くなる
- 生産性は「ここで5秒節約した」だけでは測りにくく、何千回もの小さな編集で摩擦が減ることにある
- コード、テスト、git diff、検索結果を行き来しながら、別の部屋に移動したような感覚なしに問題へ集中できる
- Neovimは高いプログラマビリティを持ち、既定値を受け入れるのではなく、ワークフローを自分で形作るようにしてくれる
- 不便なことが2回繰り返されたら、マッピング、コマンド、小さなLua関数、より良いプラグイン、あるいはプラグインの削除でたいてい解決できる
- 設定は実際の作業の仕方に合わせて進化し、欲しい変更が明確なときには、思考と編集のあいだに入るものはほとんどなくなる
- 15年のあいだに、言語、フレームワーク、マシン性能、業界の流行は変わったが、VimとNeovimは今も、最良の仕事が行われる中心的なエディタであり続けている
1件のコメント
Lobste.rsのコメント
12〜14年前にvimを使い始めたのは、コードを目の前にそのまま表示してくれる軽量なエディタが必要だったから
マウスを使わずに操作することを学び始め、その後でMitchell Hashimotoも似たようにvimを学んだと知ってうれしかった
neovimはTJ DeVries(https://www.youtube.com/@teej_dv)と彼のYouTubeチャンネルを通じて知り、彼がneovimやtelescopeなどさまざまなプロジェクトをハックしている様子を見ていた
Luaへの移行は自然に感じられ、もともと好きだった小さな言語でもあったので気に入った
最初に使ったプラグインはtreesitterとtelescopeで、今もいくつかの小さなプラグインと一緒にneovimを使っている
neovimが自分の環境で壊れたことはなく、ただ普通にちゃんと動く。LLMプラグインは使っておらず、そのエコシステムはエディタの外にあってもいいと思っている
チームには今後も軽量で集中できるコードエディタだけを提供し続けてほしい
だからneovimがLuaを追加したのはとても魅力的に見えた
20年ほど前、単に生産的であることとは別に、日常を楽しくしてくれる要素は何かを考えたことがある
そのリストの最上位にはlinuxとvimがあった
どんな仕事をしていても、どんな技術スタックを使っていても、この2つが人間工学的で、しかも慣れ親しんだ居心地のよい作業環境を保証してくれた
2009年、面接を受けていた頃に
:wq以上のvimを学び始めた。社員がみんなvimを使っていて、一緒に働くにはそれしか方法がなかったからだ中には矢印キーまで無効化している人もいた
それ以前のターミナルエディタ経験といえば、大学時代に
picoを使ったくらいで、普段は当時流行していたGUIエディタを使っていた幸い採用され、それ以来ずっとvimを使うようになった
最近では、vim的な考え方がソフトウェア生活のほかの部分にも染み込んでいることに気づいた
macOSでHammerspoonを使ってウィンドウ管理用のサブマップのための仮想キーボードを作ったのが始まりだった気がするし、去年の終わりにArch Linuxを試してからはタイル型ウィンドウ管理がとても簡単になった
しばらく前にneovimへ移行したが、本当に素晴らしいと思う
エディタに関する冗談や論争が多いのはわかっているが、いくつかの例外を除けば、コードを書くことを仕事にしている人がvim、emacs、または似たようなエディタを使わないというのはいまだに理解しがたい
どんな職業でも仕事に合った最良の道具を選ぶことは重要であり、編集を言語のように扱えることはソフトウェアにおいて大きな利点だ
上の「理解しがたい」という部分について言えば、VS Codeのようなエディタの挙動、ショートカット、プラグインも非常に有用だ
VS Codeのドキュメントはきちんと読んでみる価値があり、実際かなり多くのことをしてくれる
そして私を含む一部の人にとっては、マウスでバッファ内の任意の位置にカーソルを移動し、任意の範囲を選択するのは単純で十分に速い
KISSでいい
他のエディタのほうがその作業に適した道具であることが多いからだ
最近最もよく使うPythonでは、PyCharmのほうがそれらより優れた道具だと感じる
幸いIDEAVimという非常に良いプラグインがあり、筋肉記憶は維持できる
macで使うとシステムショートカットがviのショートカットと衝突しないので、状況に応じてどちらを使うか選べるのも利点だ
C++を書くときはCLionのほうが優れた道具だと思うが、そこでもIDEAVimは動く
分類しにくい雑多な作業にはzedをよく使っていて、vimエミュレーションもかなり良い
リモートシステムに接続するときに優れたターミナルエディタがあるのは確かに良いことだが、完全なGUIが使えるならターミナルエディタはあまり好きではない
モーダル編集そのものは好きだが、筋肉記憶を捨てる必要がないならGUIエディタを使う十分な理由もあると思う
VS Codeは標準状態のままでも多くの用途に十分優れている
すでにctrl-pによるファイル検索、分割ウィンドウ、構文ハイライト、人気言語のサポートがある
neovimにも少なくとも標準でctrl-pくらいはあってほしいし、セキュリティ上の懸念や設定の障壁を下げたvim系エディタ版Linux Mintのような存在になってほしいと思っていた
SSHで接続したマシン上のtmuxセッションでペアプログラミングをしたり、小さなターミナルウィンドウで問題を修正したりするとき、普段使っているのと同じエディタ感覚を使いたいという点には共感する
SSH越しのscreen/vimで有償のコードをたくさん書いてきたし、Slackがいつでも鳴るような常時妨害の時代の前だったので、実際かなり生産的だった
Visual StudioやJetbrains IDEのCLion、Riderのような視覚的デバッガは、どのvim系エディタでも良い代替を見つけられなかった数少ないもののひとつだ
cgdbのようなものより、もっと手が届きやすい強力さがある
速度は起動時間だけの問題ではなく、neovimもその点では良いが、標準状態のneovimの終了はvimより目に見えて遅い
非常に長いわけではないが、自分の環境では約1秒ほどかかる
vimのモデルが好きだ。モーダル編集はその一部にすぎず、helixや一般的なIDEよりvimを高く評価しているのは、段階的に学べることだ
最初はキーバインドやオプション設定を理解し、Windowsで何かがうまくいかなければ設定に条件分岐を入れ、その次にautocmdや関数を書き、先に学んだことを使って小さなプラグインにまで広げていける
とはいえ、vimやneovimを心から愛しているわけではない
vimには何十年も同じ奇妙なバグが修正されないまま残っているし、neovimは多くのバグを直した一方で別のバグを持ち込んだ
neovimの最大の罪はアップデートのたびにLua APIを壊すことだ
起動するたびに非推奨の警告を見て、やりたいことをする前に設定を直さなければならないのにはうんざりしている
新機能の一部がLua専用でなければ、まだましだっただろう
そうでなければvimscriptを使い続け、20年以上続いてきた互換性に満足できただろう