自分の環境では、.vimperatorrcで
set editor='C:/Path/To/vim72-kaoriya-w32j/gvim.exe --remote-wait'
などと設定した状態で外部エディタとしてVimを起動すると、
たまにVimでの編集を終了してもVimperator側が復帰しない(Vimの終了を待ち続ける)ことがあって、なんだろうなあとは思いつつも、特に原因について調べるようなことはしていなかった。
で先日、2009-11-12 rrhelper.vim - KBDAHOLIC - やぬすさんとこを見て、remote-wait周りの処理がrrhelper.vimで行われていることを知り、この周りを調べれば問題の原因がなんかわかるかもと思って調べたところ、なんとなく原因がわかったので以下にメモ。
どうもこの現象は、Vimでファイルを開いた後でバッファのカレントディレクトリを変更すると起こるみたい。
(BufEnterイベントで自動的にディレクトリを変更するような設定をしていると遭遇しやすいかも)
vimで開く
↓
別のバッファに移動
↓
元のバッファに戻る(BufEnter) <- ここでディレクトリ変更が発生
↓
バルス
こんな感じで、カレントディレクトリを変更した際にファイル(バッファ)名が変わってしまって(C:/Path/To/filename -> filename)
そのせいで、rrhelper.vim内でautocmdに追加されたパターンと一致しなくなってしまっている模様。
rrhelper.vim内での処理
サーバ側でファイルを開く際、 そのファイルのバッファがアンロードされる時にクライアント側に何か応答を返すための処理がautocmd BufUnloadイベントとして追加される。
(rrhelper.vimのSetupRemoteReplies関数)
その際、autocmdに加える時のパターンがファイルのフルパスで登録される。
ところが、:lcdでカレントディレクトリをバッファのファイルと同じディレクトリに変更すると、
ファイル名が、途中のディレクトリが省略されたものになってしまう(例:/path/to/filename -> filename)
すると、BufUnloadイベントが発生した時のファイル名とパターンとの比較で合致しなくなる
↓
クライアントへの応答処理が呼ばれないまま
↓
Vimを終了するまでクライアント(Vimperator)側は待機したままになる。
