Neovim は Vim の保守構造を分け、API と非同期性を前面に出す

Vim を分割して保守しやすくするフォーク

Neovim の README は、このプロジェクトを Vim の積極的なリファクタリングを目的とするフォークとして紹介しています。目標は、保守を簡単にして貢献を促すこと、作業を複数の開発者に分けること、コアを変更せずに高度な UI を可能にすること、拡張性を高めることです。リポジトリの説明も、使いやすさと現代的な連携を重視する Vim ベースのエディターとしています。README は Introduction wiki と Roadmap を入口として示しますが、提供素材にはそのページの詳細までは含まれていません。

UI とプラグインを外から接続する API

機能面は拡張性と結び付いています。README は C/C++、C#、Clojure、D、Elixir、Go、Haskell、Java と Kotlin、JavaScript と Node.js、Julia、Lisp、Lua、Perl、Python、Racket、Ruby、Rust などの API クライアントを列挙しています。モダン GUI のほか、スクリプト可能な内蔵端末エミュレーター、非同期ジョブ制御、複数インスタンス間の shada 共有、XDG base directory をサポートします。Ruby と Python のものを含め、多くの Vim プラグインと互換性があるとも記載されています。完全な機能表は :help nvim-features で確認する位置付けです。

パッケージ導入と CMake ビルドの二つの道

Windows、macOS、Linux 向けのビルド済みパッケージは Releases に置かれ、Homebrew、Debian、Ubuntu、Fedora、Arch Linux、Void Linux、Gentoo などの管理パッケージも README に挙げられています。ソースからは CMake を中心に Makefile を使えます。依存関係を準備した後、make CMAKE_BUILD_TYPE=RelWithDebInfo、sudo make install が例示されます。場所を変える場合は CMAKE_INSTALL_PREFIX を指定します。cmake --build build --target help、CMakeCache.txt、cmake -LAH build、compile_commands.json を使えば、ターゲット、解決済み変数、コンパイル呼び出しを確認できます。

src/nvim に分かれた編集エンジン

トップレベルには cmake、cmake.config、任意依存関係を扱う cmake.deps、プラグインとドキュメントの runtime、アプリケーション本体の src/nvim、テストの test があります。src/nvim の下は api、Vimscript サブシステムの eval、イベントループの event、事前コンパイル用の generators、汎用データ構造の lib、Lua、msgpack_rpc、低レベルの os、内蔵 UI の tui に分かれます。この構成は、UI、評価、イベント、RPC、OS 差分を一枚の実装へ押し込めずに扱うための見取り図です。README は各ディレクトリの役割を列挙するところまでで、内部 API の互換保証までは示していません。

Vim から移る人が先に読む場所

移行の入口として README は :help nvim-from-vim を指し、公式ドキュメント neovim.io/doc と Matrix のチャットルームにもリンクしています。README 本文には完全な移行手順、破壊的変更の一覧、すべてのプラグインの対応表はありません。Vim の設定をそのままコピーする前に、組み込み help でオプション、イベント、プロバイダー、プラグインの依存を一つずつ確認する必要があります。対応しているという表現も、すべての古いプラグインが同じ動作をするという意味ではありません。

ライセンス表示と素材から分からないこと

README は、コミット b17d96 以降の Neovim への貢献を Apache 2.0 で扱い、Vim からコピーされた貢献は vim-patch トークンで区別して LICENSE.txt を参照するよう説明しています。一方、リポジトリメタデータの licenseSpdx は NOASSERTION とされ、今回のライセンス抜粋から実ファイルの条項を確認できません。したがって、記事だけで全体のライセンスを断定せず、対象リビジョンの LICENSE.txt と配布パッケージの表示を直接確認します。メタデータの 102,001 stars、7,059 forks、1,864 open issues は関心の規模を示す手掛かりで、品質やサポートの保証ではありません。

Neovim の導入判断では、Vim の設定を動かせるかと、外部 UI や非同期 API を使えるかを別の確認項目にします。README が挙げるプラグイン互換性は便利な入口ですが、Ruby や Python の provider、旧来の Vimscript、端末イベント、キーマッピングが個々のプラグインで同じように動くとは限りません。CMake の解決値と compile_commands.json を保存すれば、依存関係を含むソースビルドの差分を後から追えます。配布パッケージを使う場合も、nightly、stable、特定バージョンを混在させず、設定とプラグインの組み合わせを固定して更新します。README は LICENSE.txt と vim-patch の扱いに触れていますが、提示資料では実ファイルを確認できないため、Apache 2.0 と言い切る範囲を貢献物や配布物ごとに分ける必要があります。性能や保守の評価を星数だけで済ませず、自分の編集操作とプラグイン集合で測るのが現実的です。

設定移行の小さな試験では、init ファイル、plugin manager、provider、端末の表示、shada、外部 GUI を順に確認し、問題が出た項目を一つずつ切り分けます。Neovim の API と msgpack_rpc は外部クライアントを作る土台になりますが、API クライアントの名前が README にあることだけでは、特定のクライアントが対象版で保守されていると判断できません。ソースビルドでは CMake のキャッシュ、依存関係、ビルド種別、インストール先を記録し、配布版では stable と nightly を別の試験対象にします。Vim からの移行は :help nvim-from-vim が入口で、破壊的変更や各プラグインの状態は公式文書へ戻って確認します。ライセンスも対象 commit と vim-patch の扱いを分けて調べ、メタデータの NOASSERTION を無視しないことが必要です。

評価記録には Neovim の版、OS、端末、設定、プラグイン、provider の版を含めます。API やイベントの利用者は、nightly と stable の差を同じものとして扱わず、更新前後の動作を比較します。README が示すソース構成は調査の入口であって、個別のプラグインがそのまま使える証明ではありません。LICENSE.txt の実内容、vim-patch の対象、配布パッケージの表示を確認してから、組織内での再配布条件を決めます。

編集部の結論

Neovim は Vim の操作モデルを保ちながら、外部 UI、非同期ジョブ、端末、スクリプト連携を重視した編集環境を組みたい人に向きます。パッケージ導入なら Releases、ソース導入なら CMake と依存関係を確認し、Vim プラグインの互換性、移行時の差分、実際の LICENSE.txt の内容を自分の版で照合してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes