On 21/03/2011 14:56, Mike Williams wrote:
On 21/03/2011 00:57, Gary Johnson wrote:
On 2011-03-21, Andy Wokula wrote:
Am 18.03.2011 15:33, schrieb Mike Williams:
The Win32 file search functions search both the long and short
versions of
file names. When the short version of a file name is created any
extension
is limited to 3 characters. You can see this when you do a dir /x in a
directory. See also:
http://blogs.msdn.com/b/oldnewthing/archive/2005/07/20/440918.aspx
There are ...Ex() versions of the file search functions which on
Win2008R2
and Win7 can ignore the short file names but that doesn't help with
VIM on
older versions of Windows.
Mike
D:\temp>dir /X *.vim
...
Verzeichnis von D:\temp
17.03.2011 20:44 2.645 ABC~1.VIM abc.vimdef
17.03.2011 20:44 2.645 GARYJ~1.VIM garyj.vim,v
2 Datei(en) 5.290 Bytes
...
D:\temp>
That explains it, thanks for the link!
That suggests that Vim would try to source a file named abc.vimdef
in a user's plugin directory, so I tried that at home. Not only did
vim not try to source abc.vimdef, it didn't try to source
garyj.vim,v either. So at home, where I'm still running Windows Vim
7.3.3, I don't see the problem. I discovered the problem at work,
where I think I was running Windows Vim 7.3.46 at the time and
upgraded to Windows Vim 7.3.138 before reporting the problem.
A quick spelunk through the source shows that VIM filters the results
from the Windows find file with the original pattern, I imagine to try
and solve this issue.
However, a quick play in VIM (7.3.138, Win7 x64) seems to show different
behaviour with :args *.vim based on the directory location. Doing :args
*.vim in a runtimepath plugin directory filters out any files whose
extension is more than just .vim, while doing it in a directory not in
the runtimepath picks up the all files whose extension starts with .vim.
This also happens with vim -u NONE -U NONE.
This will need some time in a debugger to find out why there is a
difference, unless someone more experienced with the Windows file
handling code in VIM already knows what is happening.
Ug. This is all done in dos_expandpath() in misc1.c and is a bit of a
rat's nest of pp code. Basically the function does a first pass over
the results of find file with a pattern of *.* matching the results
against an RE of the file pattern. If the first pass does not turn up
any matches then it does a second pass giving the file pattern to find
file and not filtering the results.
The upshot of this is if you have a directory with a single file in it
called erik.viking and do :echo glob('*.vik') VIM will pick it up. If
you add a second file called ernie.vik and do the echo again then VIM
picks up the new file only, and not the original erik.viking file.
This does seem inconsistent and unintuitive, and fails the principle of
least surprise. VIM first matches on long names and only if none match
does it match on short names. I feel it should either match long and
short all the time (which Windows users will know and love/hate but
expect) or only match long with an option to include short as well (for
the unix peeps who like to pretend NTFS behaves like their preferred FS
du jour).
Bram's call.
HTH
Mike
--
Computers must run on smoke; they stop when it leaks out.
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
