Benji Fisher wrote:
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.
Morality: Whenever possible, use / as path separator in Vim, even on
Windows. There are a few exceptions (where they don't work).
Best regards,
Tony.
