バグ直しました。

[h1mesuke]

パッチありがとうございます。 findfile() の使用が不適切、というのは、suffixesaddオプションの影響を受けて 意図しないファイルのパスを返す可能性があるから、という理解でいいでしょうか？

[h1mesuke]

マージしました。

[thinca]

すいません。この方法だと globpath() が複数のパスを見つけた場合にうまく行きません…。

findfile() がまずかったのは、&runtimepath がスペースを含んでいた場合にうまく探せないからです。 よって Windows XP ではデフォルトが "Documents and Settings" を含むのでほぼ間違いなく失敗します。 また、&runtimepath に ~/ などが含まれていた場合もそのディレクトリからファイルを見つけることができません。

[h1mesuke]

findfile() がまずかったのは、&runtimepath がスペースを含んでいた場合にうまく探せないからです。よって Windows XP ではデフォルトが "Documents and Settings" を含むのでほぼ間違いなく失敗します。

ああ、そんな罠が。 Windows での検証の際は Cygwin のホームディレクトリ（C:\home\hoge）を使っているので気付きませんでした。

globpath() が複数のパスを見つけた場合を考慮して split して最初の要素を取る、 みたいな処理が必要かなとは自分も思ったのですが、autoload/ 以下の部分に関してはパスが完全に指定されているし、 複数のパスが見つかった場合はエラーになってよいケースかなと判断してそのままマージしました。

[thinca]

開発中などで、&runtimepath に unite-outline が複数あったりすると問題になるかもしれません。その辺りの判断はお任せします。 ちなみに、findfile() でもスペースをエスケープすれば一応動きます。

echo findfile(file, escape(&runtimepath, ' '))

ただ、この場合でも ~/ は別途展開しないといけませんが…。

[h1mesuke]

globpath() が複数のパスを返した場合は最初のものをとるように修正しました。