はじめに（vim_lib）
致命的な欠陥のないプラグインマネージャー （vim_lib、vim_plugmanager）
プロジェクトレベルとファイルシステム（vim_prj、nerdtree）
スニペットとファイルテンプレート（UltiSnips、vim_template）
コンパイルと実行（vim-quickrun）
Gitを使用する（vim_git）
デプロイ（vim_deploy）
xUnitを使用したテスト（vim_unittest）
すべてが置かれているライブラリ（vim_lib）
その他の便利なプラグイン

おそらく、Vimで人気のあるすべてのプラグインマネージャーを使用し、自分に適したものを作成することを少しも望みませんでしたが、この記事で説明する小さなものがありました。

悪い他のマネージャー

Vimのプラグインマネージャーはどのように機能しますか？すべてが簡単です。エディターの開始時に、現在使用中のすべてのプラグインが宣言されている.vimrcが読み込まれます。これらの名前は、プラグインを保存するディレクトリのアドレスと連結され、結果の行がruntimepath -Vim変数に追加されます。Vim変数は、エディターが開始スクリプト、プラグイン、その他すべてを取得する場所を決定します。

最も人気のあるVimプラグインマネージャーの主な問題は、 runtimepath変数をランダムに埋めることです。これは何につながりますか？プラグインはランダムにロードされ、特定のプロジェクトのプラグイン設定をオーバーライドする方法はありません。プラグインは独自のVim設定をオーバーライドします。プラグインAを最初にダウンロードする必要があるときにプラグインのロード順序を制御できず、プラグインに依存する依存関係Bのみを制御できないため、さらに悪化します。

理想的に必要なもの

前にも言ったが、この問題については次の記事で詳しく説明しますが、今は少しだけ触れます。私が提案する構造は、Vimエディターに別のレベルの初期化を追加します。これは、Vimの構成とプラグインが3つのレベルで存在することを意味します。

システム（ $ VIMRUNTIME / ）-システムのすべてのユーザーに適用される構成とプラグイン
カスタム（ 〜/ .vim / ）-特定のユーザーの構成とプラグイン
プロジェクト（ ./.vim/）-このプロジェクトでのみ使用可能な構成とプラグイン。このレベルはVimにはありません。より正確には、そうではありませんが、実装はかなり不十分です。

これにより、たとえば、Javaクラスのテンプレートをカスタマイズし、特定のプロジェクト用にテンプレートをオーバーライドできます。特定のプロジェクトにのみプラグインをインストールすることもできます。このプラグインはVimによって他のプロジェクトに読み込まれません。これにより、メモリが節約され、エディターの生産性が向上します（たとえば、Luaでの作業を開始し、プラグインを〜/ .vim /に配置したくない場合）。想像してみてください。1人の編集者があらゆる場面に対応し、遅れはありません。

プラグイン標準

vim_libライブラリは、Vimプラグインの構造（ただし、この構造だけに制限されず、任意のプラグインを使用できます）と、それらが接続およびロードされる順序の両方を定義します。これには、それぞれsys / Pluginおよびsys / Autoloadクラスが実装されます。

sys / Pluginクラスの要件に厳密に従ってプラグインを実装すると、次の構造が得られます。

myPlugin/ plugin/ myPlugin.vim autoload/ ... myPlugin.vim doc/ myPlugin.rux

plugin / myPlugin.vimファイルには、 プラグインの初期化と接続ロジックが含まれています。

例

 " Date Create: 2015-02-23 22:45:56 " Last Change: 2015-06-07 18:21:15 " Author: Artur Sh. Mamedbekov (Artur-Mamedbekov@yandex.ru) " License: GNU GPL v3 (http://www.gnu.org/copyleft/gpl.html) "  use  VimLanguage let s:Plugin = vim_lib#sys#Plugin# let s:System = vim_lib#sys#System#.new() let s:p = s:Plugin.new('vim_write', '1') "          "   "" {{{ " @var bool          . "" }}} let s:p.preplace = 1 "" {{{ " @var bool     . "" }}} let s:p.aw = 0 "" {{{ " @var string|array ,    ,      .      'all',      . "" }}} let s:p.awTypes = 'all' if !exists('g:vim_write#replacement') "" {{{ " @var hash  ,        .    : {: [regexp, ...]}.  'all'    . "" }}} let g:vim_write#replacement = {} endif "   ,       function! s:p.run() " {{{ call s:System.au('BufWritePre,FileWritePre', function('vim_write#_writePre')) call s:System.au('CursorHold', function('vim_write#_autowrite')) endfunction " }}} "    .    Plugins.. call s:p.menu('Aw_start', 'awstart', '1') call s:p.menu('Aw_stop', 'awstop', '2') "    call s:p.comm('VimWriteAwStart', 'awstart()') call s:p.comm('VimWriteAwStop', 'awstop()') call s:p.reg() "  ,

autoload / myPlugin.vimファイルにはプラグインメソッドが含まれています。経験豊富なVimユーザーは、プラグインのメインコードがエディターの起動中ではなく、最初に使用されたときにロードされることにすぐに気付くでしょう。これは、プラグインメソッドのグローバルコールを通じて行われます。たとえば、前の例のVimWriteAwStartコマンドを実行すると、 プラグイン名＃awstart（）メソッドが呼び出されます。

例

 " Date Create: 2015-02-23 22:48:37 " Last Change: 2015-06-07 18:21:15 " Author: Artur Sh. Mamedbekov (Artur-Mamedbekov@yandex.ru) " License: GNU GPL v3 (http://www.gnu.org/copyleft/gpl.html) "  use  VimLanguage let s:Publisher = vim_lib#sys#Publisher#.new() let s:Content = vim_lib#sys#Content#.new() "" {{{ "    . "" }}} function! vim_write#awstart() " {{{ let g:vim_write#.autowrite = 1 endfunction " }}} ...

doc / myPlugin.ruxファイルには、プラグインのドキュメントが含まれています。

なぜこれがすべて必要なのですか？最初は標準化です。プラグインの作成、変更、および理解が容易になります。第二に、それらは無効にする方が簡単です。

詳細はこちら。

オートロード

ライブラリのsys / Autholoadクラスは 、Vimエディターとそのプラグインの両方の初期化順序を定義します。初期化はいくつかの段階で実行されます。

メインエディター構成ファイルの接続（ $ VIMRUNTIME ）
システム全体のプラグインの接続（ $ VIMRUNTIME / plugin / ）
ファイル依存の構成の接続（ $ VIMRUNTIME / ftplugin / ）
基本的なユーザー設定ファイルの接続（ 〜/ .vimrc ）
カスタムプラグインの接続（ 〜/ .vim / plugin / ）
ファイル依存のユーザープラグインの接続（ 〜/ .vim / ftplugin / ）
メインプロジェクト構成ファイル（ ./.vimrc ）の接続
プロジェクトプラグインの接続（ ./.vim/plugin/ ）
ファイル依存のプロジェクトプラグインの接続（ ./.vim/ftplugin ）

これはおなじみのruntimepath変数を使用して行われますが、プラグインのロード順序、ローカリゼーション（システム、ユーザー、またはプロジェクト）を考慮し、各レベルでエディターとプラグインの両方の構成を再定義するメカニズムもサポートします（プロジェクトレベルが最優先です）。

一般に、 sys / Autholoadクラスを使用すると、3つのステップだけでなく、ネスト階層と構成の優先順位を実装できますが、新しいレベルを追加する必要はありませんでした。

sys / Autholoadクラスが提供する自動ロードを使用するには、次の行を.vimrcファイルに追加します。

 filetype off set rtp=~/.vim/bundle/vim_lib call vim_lib#sys#Autoload#init('~/.vim', 'bundle') "    ~/.vim/bundle Plugin 'vim_lib' "   filetype indent plugin on

これは、ユーザーレベル（ 〜/ .vimrc ）だけでなく、システムレベル （ $ VIMRUNTIME / .vimrc ）またはプロジェクト（ ./.vimrc ）でも実行できますが、起動ロジックはこのレベルと「下」からのみ配布されます。すべての下位レベルでは、このレベルでのみ使用可能な新しいプラグインを接続するだけで十分です。

 filetype off call vim_lib#sys#Autoload#init('.vim', 'bundle') "      Plugin 'myPlugin' filetype indent plugin on

プラグインを無効にするには、プラグインの 'name'行をコメントアウトします。

接続中にプラグインを直接設定できます：

 Plugin 'vim_deploy', { \ 'options': {'adapter': 'shipit'}, "    \ 'map': {'deploy': '<Leader>d'}, "    \}

下位レベルでは、これらの構成をオーバーライドできます。

 let g:vim_deploy#options = {'adapter': 'gradle'}

すべてが非常に柔軟で便利です。

プラグインマネージャー

他のプラグインマネージャーに、必要なディレクトリ（システム、ユーザー、またはプロジェクト）にプラグインをインストールすることを強制するのが難しくなるように思えますか？ここでの問題は、他のマネージャーがサードパーティのプラグインをインストールするだけでなく、初期化から順序を決定することであり、それは必要ありません（すでにライブラリのsys / Autholoadクラスによって実装されています）。前の記事で説明したのと同じVimプラグインの非互換性の問題。決断を書かなければなりませんでした。

vim_plugmanagerのインターフェースは非常にシンプルで、現在の場所に応じて、GitHubからシステムディレクトリ、ユーザーディレクトリ、またはプロジェクトディレクトリにプラグインをインストールできます。

プラグインリストウィンドウ

図からわかるように、vim_plugmanagerはウィンドウとして実装されており、現在インストールされているプラグイン（インストールされている、接続されていない）のリストをレベルごとにグループ化して表示します。新しいプラグインを追加するには、 aキーを押し、削除するには、プラグインの上にカーソルを移動してddを押します（ご存知ですか？）。

新しいプラグインをインストールしたら、接続する必要があります。これを行うには、前述のように、現在の.vimrc （現在のレベル） プラグインレコード'Plugin name'に追加するだけで十分です。これが必要なのは、プラグインのインストールがプラグインを含むディレクトリにプラグインをコピーし、接続がそれをvimruntimeに追加し、その後エディターでロードできるためです。

詳細はこちら。

さようなら

この記事では、Vimプラグインを使用したときに発生したすべての問題について説明しましたが、説明したソリューションのすべての可能性については説明していません。公開されているドキュメントをコピーする価値はないと思います。

おそらく、既存のソリューションをうまくやり取りし、それらを相互に交差させることもできましたが、この場合、より多くの時間を費やすリスクがあり、その結果、必要なものが手に入りません。

完全なVim：致命的な欠陥のないプラグインマネージャー

目次