On Mon, Aug 2, 2010 at 5:10 PM, Bram Moolenaar <[email protected]> wrote: > > Nazri Ramliy wrote: > >> >> On Mon, Aug 2, 2010 at 8:49 AM, Nazri Ramliy <[email protected]> wrote: >> > On Thu, Jul 29, 2010 at 4:39 AM, Bram Moolenaar <[email protected]> wrote: >> >> I have included the recent patches, but not the one that resets >> >> "recursive" in gen_expand_wildcards(). That is probably causing that >> >> crash. >> > >> > I noticed that mch_expandpath() is defined on both unix and windows as >> > unix_expandpath() and dos_expandpath(), respectively. I'll see if it >> > can be used in place of globpath() (which calls gen_expand_wildcards()) >> > in the function expand_in_path(). >> > >> > If that is successful I'll send a new patch for that and also revert >> > thechanges >> > I did in globpath() (skipping url path). >> >> It turned out that using unix_expandpath() for find completion is much, >> much slower than using globpath. I ended up using mch_expandpath only when >> WIN3264 is defined, and use globpath() otherwise. >> >> The benchmark result (doing a find completion for "jingle.gy" in the google >> chrome source code, the fullname is "jingle.gyp"): >> >> bench.vim: >> ---->8---- >> :set path=~/src/chrome/** >> :find jingle.gy >> :q >> >> ----8<---- >> Note: there's a single tab character after jingle.gy >> >> Result of running >> >> $ time ./vim-globpath -s bench.vim; time ./vim-mch_expandpath -s bench.vim >> >> for five consecutive runs (whitespaces added to align the timing output >> below): >> >> ./vim-globpath -s bench.vim 0.48s user 1.90s system 92% cpu 2.570 >> total >> ./vim-mch_expandpath -s bench.vim 4.26s user 3.97s system 90% cpu 9.135 >> total >> >> ./vim-globpath -s bench.vim 0.53s user 1.64s system 93% cpu 2.310 >> total >> ./vim-mch_expandpath -s bench.vim 2.62s user 2.03s system 91% cpu 5.077 >> total >> >> ./vim-globpath -s bench.vim 0.46s user 1.80s system 91% cpu 2.475 >> total >> ./vim-mch_expandpath -s bench.vim 3.39s user 3.10s system 86% cpu 7.471 >> total >> >> ./vim-globpath -s bench.vim 0.44s user 1.47s system 88% cpu 2.153 >> total >> ./vim-mch_expandpath -s bench.vim 2.00s user 1.92s system 90% cpu 4.350 >> total >> >> ./vim-globpath -s bench.vim 0.47s user 1.46s system 84% cpu 2.271 >> total >> ./vim-mch_expandpath -s bench.vim 2.59s user 2.41s system 96% cpu 5.185 >> total >> >> Based on the benchmark result above it appears that using globpath() is about >> 4 times faster than using mch_expandpath() for doing find completion. >> >> Attached patch makes find completion works on windows using mch_expandpath(). >> On unix we still use globpath(). This is done checking #if defined(WIN3264), >> I'm not sure if that is the preferred way to detect if we're compiling on >> windows. >> >> > In the mean time here is the patch to prevent ":find <tab>" from crashing >> > on >> > windows when 'path" is set to something like "c:\src\**". >> >> With the attached patch the above is no longer necessary. >> >> For people who would like to test this out, please note the remark in :help >> 'path': >> >> - Careful with '\' characters, type two to get one in the option: >> :set path=.,c:\\include >> Or just use '/' instead: > >> :set path=.,c:/include >> >> For example use ":set path=.,c:\\include\\**" or ":set path=.,c:/include/**" >> to make vim recursively find completion candidates in c:\include directory. > > I haven't checked the details, but I have included the patch and made > some style changes. I merged the two functions, I don't like > duplicating code. >
Revision: 7d1044b27e On WinXP, attempting find completion leads to a crash. gvim -N -u NONE a.tex :find <Tab> Vim crashes The same happens with :find a<Tab> Ajit -- 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
