On Wed, Jul 26, 2006 at 07:45:12AM +0200, A.J.Mechelynck wrote:
> Bill McCarthy wrote:
> >Hello Vim Developers,
> >
> >I was timing the startup process by stepping though what I
> >think Gvim does (on Win XP Pro with 7.0.42).
> >
> > gvim -u NONE -N
> >
> >That starts up without _vimrc or _gvimrc or plugins and sets
> >nocp.
> >
> > :so $vim\_vimrc
> >
> >worked fine.
> >
> > :so $vim\_gvimrc
> >
> >also worked fine.
> >
> > :ru! plugin\**\*.vim
> >
> >didn't seem to do anything. Repeating the above as
> >
> > :verb ru! plugin\**\*.vim
> >
> >reports: not found in 'runtimepath': "plugin\**\*.vim"
> >
> >Hmm, when I tried again with the unixy
> >
> > :ru! plugin/**/*.vim
> >
> >the plugins were finally sourced.
> >
> >Bug?
> >
>
> IIUC, it's a feature: \* means a literal asterisk. Not a very good
> feature since IIUC, asterisks are not allowed in filenames on Windows.
> Or can they happen in long file names?
Right, as explained under
:help dos-backslash
(There is not enough detail there to predict what vim will do in this
particular situation, though.) This might also work (but I am not going
to find a W32 box to test it, sorry):
:ru! plugin\\**\\*.vim
HTH
P.S. Maybe something should be added under
:help wildcard
or
:help starstar-wildcard
to explain using \**\ on DOS-like systems. In fact, after reading that,
it seems to me as though \**\ *should* be interpreted as path separator,
wildcard, path separator in this case.