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.