Mike Williams wrote:
> 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.
We can't really drop the current method, it's there for a reason.
We also can't ignore the problem. I can't think of a better solution
than using an option. It's far from nice, it's unlikely the user finds
out about the option when the wrong files match. And I don't really
know what the default value would be.
--
INSPECTOR END OF FILM: Move along. There's nothing to see! Keep moving!
[Suddenly he notices the cameras.]
INSPECTOR END OF FILM: (to Camera) All right, put that away sonny.
[He walks over to it and puts his hand over the lens.]
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
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
