vim-pukiwiki を autload 化した

vim plugin のディレクトリ構成

だいたいこんなかんじ.

plugin-directory/ - doc/
                  - plugin/
                  - indent/
                  - syntax/
                  - ftdetect/
                  - ftplugin/

私の理解では, 基本的な構成はこんな感じ.

  • doc/ ヘルプを置く場所
  • plugin/ プラグイン本体
  • indent/, syntax/ ファイルタイプ依存だと思うのだけど, indent/syntax の定義
  • ftdetect/, ftplugin/ ft=filetype のこと. ファイルタイプ固有の処理を定義する. "set filetype=hoge" とやると ftplugin/hoge.vim などが読み込まれる.

autoload

plugin/ などにおかれた *.vim ファイルは起動時に読み込まれる. これだとプラグインを追加していくとだんだん起動が遅くなる.
そこで plugin/ には必要最小限の処理だけをいれて, autoload/ の *.vim は実行時に読み込まれるようになった.

  • 利点
    • vim 本体の起動がはやくなる
  • 欠点

autoload 化

1) plugin/ ではコマンドの定義, キーマッピングのみにする.
コマンドで呼び出す関数は hoge#function の形にする.

-command! -nargs=* PukiWiki :call PukiWiki(<f-args>)
+command! -nargs=* PukiWiki :call pukiwiki#PukiWiki(<f-args>)

2) autoload/hoge.vim に plugin/*.vim にあった内容をコピーする.
3) global な関数名を hoge#function に変更する.

    • function は小文字はじまりでもいい.
    • s: な関数は変更しなくてもいい.
-function! PW_fileupload() range "{{{
+function! pukiwiki#fileupload() range "{{{

4) テストする.

サブディレクトリ掘ってるときとかあるけど, いまは気にしない

余談

autoload は vim script をわかりにくくしている原因の一つだと思う. とはいえ, # の意味さえわかればついていけるのか.

それより, 私にとって vim script のとっつきにくい原因は printf デバッグのやりかたさえわからなかったことだった.
というか未だにデバッグ方法は良く分かっていない.

hatena ダイアリなんでこんな編集しづらくなってるの.