Re: Question about :find completion support in Vim 7.3b
James Vega wrote: On Thu, Aug 05, 2010 at 09:56:29PM +0200, Bram Moolenaar wrote: Nazri Ramliy wrote: test73.in should now run successfully on both unix and windows. Thank you very much for fixing the problems and enhancing the test. I'll include this and check that it works for me. The Xfind directory wasn't removed, you had the last :cd commented-out. Hmm, the test passes, but it rings the bell a lot. I can fix one (the empty line). The others appear to be for when completion of :find fails. I'm not sure how to avoid that. I'll add :set visualbell. Attached patch also adjusts 'viminfo' appropriately so that the user's viminfo isn't overwritten. Thanks! -- How To Keep A Healthy Level Of Insanity: 8. Don't use any punctuation marks. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.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
Re: Question about :find completion support in Vim 7.3b
On Thu, Aug 05, 2010 at 09:56:29PM +0200, Bram Moolenaar wrote: Nazri Ramliy wrote: test73.in should now run successfully on both unix and windows. Thank you very much for fixing the problems and enhancing the test. I'll include this and check that it works for me. The Xfind directory wasn't removed, you had the last :cd commented-out. Hmm, the test passes, but it rings the bell a lot. I can fix one (the empty line). The others appear to be for when completion of :find fails. I'm not sure how to avoid that. I'll add :set visualbell. Attached patch also adjusts 'viminfo' appropriately so that the user's viminfo isn't overwritten. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com diff --git a/src/testdir/test73.in b/src/testdir/test73.in --- a/src/testdir/test73.in +++ b/src/testdir/test73.in @@ -5,7 +5,7 @@ : delete the Xfind directory during cleanup : : This will cause a few errors, do it silently. -:set visualbell +:set nocp viminfo+=nviminfo visualbell : :function! DeleteDirectory(dir) : if has(win16) || has(win32) || has(win64) @@ -17,7 +17,6 @@ : On windows a stale Xfind directory may exist, remove it so that : we start from a clean state. :call DeleteDirectory(Xfind) -:set nocp :new :let cwd=getcwd() :!mkdir Xfind signature.asc Description: Digital signature
Re: Question about :find completion support in Vim 7.3b
On Thu, Aug 5, 2010 at 12:25 AM, Ajit Thakkar a...@unb.ca wrote:
Nazri, for the future, you may want to try and add path completion for :cd
Ajit
Here's a toy patch if you would like to try it out. Thanks for the suggestion.
I've never used 'cdpath' before.
The implementation reuses the same mechanism as the find completion.
From my cursory tests it seems to work fine on unix for 'cdpath' values set
to default (,,), empty (set cdpath=), and recursive (set cdpath=~/foo/**).
I'll do a quick test on windows XP ...
It doesn't work as smooth as on unix because completion list have
trailing path separators for all the directories that it found:
:cd somedirincdpath\
fails, while
:cd somedirincdpath
or
:cd somedirincdpath/
works fine.
To fix this the trailing path must be stripped for each completion item
when they are added to the completion list. Search for the comment
/* Copy each path in files into gap */ to see where this happen.
I'm running out of time here so I'm attaching the patch as it is now,
warts and all.
nazri.
--
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
From 6ca0e09bd86271f59efe1a26d815589f284cd857 Mon Sep 17 00:00:00 2001
From: Nazri Ramliy ayieh...@gmail.com
Date: Fri, 6 Aug 2010 17:20:00 +0800
Subject: [PATCH] cd, lcd, chdir, and lchdir completion based on 'cdpath'
---
src/ex_docmd.c |3 +--
src/ex_getln.c |6 +-
src/misc1.c| 29 +++--
src/vim.h |2 ++
4 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/src/ex_docmd.c b/src/ex_docmd.c
index 0d91a0b..900577d 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -3472,8 +3472,7 @@ set_one_cmd_context(xp, buff)
case CMD_chdir:
case CMD_lcd:
case CMD_lchdir:
- if (xp-xp_context == EXPAND_FILES)
- xp-xp_context = EXPAND_DIRECTORIES;
+ xp-xp_context = EXPAND_DIR_IN_CDPATH;
break;
case CMD_help:
xp-xp_context = EXPAND_HELP;
diff --git a/src/ex_getln.c b/src/ex_getln.c
index 8a18a4c..b726e71 100644
--- a/src/ex_getln.c
+++ b/src/ex_getln.c
@@ -4102,6 +4102,7 @@ addstar(fname, len, context)
if (context != EXPAND_FILES
context != EXPAND_FILES_IN_PATH
+ context != EXPAND_DIR_IN_CDPATH
context != EXPAND_SHELLCMD
context != EXPAND_DIRECTORIES)
{
@@ -4429,7 +4430,8 @@ ExpandFromContext(xp, pat, num_file, file, options)
if (xp-xp_context == EXPAND_FILES
|| xp-xp_context == EXPAND_DIRECTORIES
- || xp-xp_context == EXPAND_FILES_IN_PATH)
+ || xp-xp_context == EXPAND_FILES_IN_PATH
+ || xp-xp_context == EXPAND_DIR_IN_CDPATH)
{
/*
* Expand file or directory names.
@@ -4461,6 +4463,8 @@ ExpandFromContext(xp, pat, num_file, file, options)
flags |= EW_FILE;
else if (xp-xp_context == EXPAND_FILES_IN_PATH)
flags |= (EW_FILE | EW_PATH);
+ else if (xp-xp_context == EXPAND_DIR_IN_CDPATH)
+ flags |= (EW_DIR | EW_CDPATH);
else
flags = (flags | EW_DIR) ~EW_FILE;
/* Expand wildcards, supporting %:h and the like. */
diff --git a/src/misc1.c b/src/misc1.c
index ef7c10c..a0bbc8c 100644
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9238,9 +9238,9 @@ unix_expandpath(gap, path, wildoff, flags, didstar)
#if defined(FEAT_SEARCHPATH)
static int find_previous_pathsep __ARGS((char_u *path, char_u **psep));
static int is_unique __ARGS((char_u *maybe_unique, garray_T *gap, int i));
-static void expand_path_option __ARGS((char_u *curdir, garray_T *gap));
+static void expand_option __ARGS((char_u *curdir, garray_T *gap, char_u *option));
static char_u *get_path_cutoff __ARGS((char_u *fname, garray_T *gap));
-static void uniquefy_paths __ARGS((garray_T *gap, char_u *pattern));
+static void uniquefy_paths __ARGS((garray_T *gap, char_u *pattern, char_u *option));
static int expand_in_path __ARGS((garray_T *gap, char_u *pattern, int flags));
/*
@@ -9310,12 +9310,11 @@ is_unique(maybe_unique, gap, i)
* expanding each into their equivalent path(s).
*/
static void
-expand_path_option(curdir, gap)
+expand_option(curdir, gap, path_option)
char_u *curdir;
garray_T *gap;
+char_u *path_option;
{
-char_u *path_option = *curbuf-b_p_path == NUL
- ? p_path : curbuf-b_p_path;
char_u *buf;
char_u *p;
@@ -9424,9 +9423,10 @@ get_path_cutoff(fname, gap)
* matches the pattern. Beware, this is at least O(n^2) wrt gap-ga_len.
*/
static void
-uniquefy_paths(gap, pattern)
+uniquefy_paths(gap, pattern, path_option)
garray_T *gap;
char_u *pattern;
+char_u *path_option;
{
int i;
int len;
@@ -9468,7 +9468,7 @@ uniquefy_paths(gap, pattern)
return;
mch_dirname(curdir, MAXPATHL);
-expand_path_option(curdir, path_ga);
+expand_option(curdir, path_ga, path_option);
for (i = 0; i gap-ga_len; i++)
{
@@ -9582,12 +9582,17 @@ expand_in_path(gap,
Re: Question about :find completion support in Vim 7.3b
On Thu, Aug 5, 2010 at 4:11 AM, Bram Moolenaar b...@moolenaar.net wrote:
I noticed another problem: with 'path' set to ./** and in an empty
buffer :find completion crashes. =A0I fixed it.
Thanks. I'll add this check to the test script.
I've updated the test to check for this and a few more conditions.
The test script works OK on Unix, but on MS-Windows it only finds two of
the three files. Also interactively, so this appears to be a problem in
the implementation.
Attached patch 0002 fixes this issue.
I already changed it to use three separate mkdir commands, as mkdir
-p doesn't work on MS-Windows (and some old Unixen too).
The mkdir Xfind/in gives error on windows, it should be mkdir
Xfind\in. I've modified it to work on both unix and windows in patch
0003.
I used an edit command instead of :!echo to make it portable.
What I can't figure out is a portable way to delete the created
directories. rmdir /s /q Xfind should work, but it gives an error for
the /s option...
Patch 0003 checks the platform using has(win??) and runs the
appropriate command.
Patch 0001 moves the check for path_with_url() for skipping urls during
find completion from globpath() into expand_path_option(). That is the
correct place to make the call for excluding any non-supported path for
find completion.
test73.in should now run successfully on both unix and windows.
nazri.
--
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
From fc8868bfedaf9551f6274d3946790d06b2ec0364 Mon Sep 17 00:00:00 2001
From: Nazri Ramliy ayieh...@gmail.com
Date: Thu, 5 Aug 2010 09:59:04 +0800
Subject: [PATCH 1/3] find completion: Path url should be skipped earlier.
Doing it in globpath() is too late and not appropriate.
---
src/ex_getln.c |6 --
src/misc1.c|2 ++
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/ex_getln.c b/src/ex_getln.c
index 790d531..948e59a 100644
--- a/src/ex_getln.c
+++ b/src/ex_getln.c
@@ -5045,12 +5045,6 @@ globpath(path, file, expand_options)
{
/* Copy one item of the path to buf[] and concatenate the file name. */
copy_option_part(path, buf, MAXPATHL, ,);
- if (path_with_url(buf))
- continue;
- /*
- * FIXME: should we proactively skip 'path' with limiter (/usr/ **N)
- * and upward search (;) notations, just like we did with url above?
- */
if (STRLEN(buf) + STRLEN(file) + 2 MAXPATHL)
{
add_pathsep(buf);
diff --git a/src/misc1.c b/src/misc1.c
index c8fb8eb..ef7c10c 100644
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9337,6 +9337,8 @@ expand_path_option(curdir, gap)
}
else if (buf[0] == NUL) /* relative to current directory */
STRCPY(buf, curdir);
+ else if (path_with_url(buf))
+ continue;
else if (!mch_isFullName(buf))
{
/* Expand relative path to their full path equivalent */
--
1.7.2.1.6.g61bf12
From 116422ea986dc2bb568c0b943c6fa5460999e61e Mon Sep 17 00:00:00 2001
From: Nazri Ramliy ayieh...@gmail.com
Date: Thu, 5 Aug 2010 12:32:02 +0800
Subject: [PATCH 2/3] find completion on windows: use / as path separator when joining path
---
src/ex_getln.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/src/ex_getln.c b/src/ex_getln.c
index 948e59a..0c48fe8 100644
--- a/src/ex_getln.c
+++ b/src/ex_getln.c
@@ -5047,7 +5047,16 @@ globpath(path, file, expand_options)
copy_option_part(path, buf, MAXPATHL, ,);
if (STRLEN(buf) + STRLEN(file) + 2 MAXPATHL)
{
+#ifdef WIN3264
+ /*
+ * Using the platform's path separator (\) makes vim incorrectly
+ * treat it as an escape character, use '/' instead.
+ * TODO: Add it only if there is none yet, like add_pathsep does.
+ */
+ STRCAT(buf, /);
+#else
add_pathsep(buf);
+#endif
STRCAT(buf, file);
if (ExpandFromContext(xpc, buf, num_p, p,
WILD_SILENT|expand_options) != FAIL num_p 0)
--
1.7.2.1.6.g61bf12
From e3cba918c80dda9f7ee2c05c08980d4462de368f Mon Sep 17 00:00:00 2001
From: Nazri Ramliy ayieh...@gmail.com
Date: Thu, 5 Aug 2010 13:50:41 +0800
Subject: [PATCH 3/3] Add more tests to find completion (test73.in)
---
src/testdir/test73.in | 81 ++--
src/testdir/test73.ok |8 +
2 files changed, 85 insertions(+), 4 deletions(-)
diff --git a/src/testdir/test73.in b/src/testdir/test73.in
index 8928aeb..c9684a3 100644
--- a/src/testdir/test73.in
+++ b/src/testdir/test73.in
@@ -1,23 +1,96 @@
Tests for find completion.
STARTTEST
+: Do all test in a separate window to avoid E211 when we recursively
+: delete the Xfind directory during cleanup
+
+:function! DeleteDirectory(dir)
+: if has(win32) || has(win95) || has(win64) || has(win16)
+: exec silent !rmdir /Q /S . a:dir
+: else
+: exec silent !rm -rf . a:dir
+: endif
+:endfun
+: On windows a stale Xfind directory may exist, remove it so that
+: we start from a
Re: Question about :find completion support in Vim 7.3b
Nazri Ramliy wrote: On Thu, Aug 5, 2010 at 4:11 AM, Bram Moolenaar b...@moolenaar.net wrote: I noticed another problem: with 'path' set to ./** and in an empty buffer :find completion crashes. =A0I fixed it. Thanks. I'll add this check to the test script. I've updated the test to check for this and a few more conditions. The test script works OK on Unix, but on MS-Windows it only finds two of the three files. Also interactively, so this appears to be a problem in the implementation. Attached patch 0002 fixes this issue. I already changed it to use three separate mkdir commands, as mkdir -p doesn't work on MS-Windows (and some old Unixen too). The mkdir Xfind/in gives error on windows, it should be mkdir Xfind\in. I've modified it to work on both unix and windows in patch 0003. I used an edit command instead of :!echo to make it portable. What I can't figure out is a portable way to delete the created directories. rmdir /s /q Xfind should work, but it gives an error for the /s option... Patch 0003 checks the platform using has(win??) and runs the appropriate command. Patch 0001 moves the check for path_with_url() for skipping urls during find completion from globpath() into expand_path_option(). That is the correct place to make the call for excluding any non-supported path for find completion. test73.in should now run successfully on both unix and windows. Thank you very much for fixing the problems and enhancing the test. I'll include this and check that it works for me. The Xfind directory wasn't removed, you had the last :cd commented-out. Hmm, the test passes, but it rings the bell a lot. I can fix one (the empty line). The others appear to be for when completion of :find fails. I'm not sure how to avoid that. I'll add :set visualbell. -- hundred-and-one symptoms of being an internet addict: 14. You start introducing yourself as Jim at I-I-Net dot net dot au /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.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
Re: Question about :find completion support in Vim 7.3b
On Wed, Aug 4, 2010 at 1:16 PM, Nazri Ramliy ayieh...@gmail.com wrote: which call expand_in_path(), which in turns call globpath(), fails with the exact same argument c:/src/vim/**, misc* and 0 for path, file and expand_options, respectively. Help! I think I found the solution. recursive should be reset to FALSE before calling expand_in_path in gen_expand_wildcards(). I'll submit a patch soon. I'm also working on a test script to test the find completion stuff. I'll send a patch for that one too, soon. nazri. -- 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
Re: Question about :find completion support in Vim 7.3b
On Wed, Aug 4, 2010 at 4:47 PM, Nazri Ramliy ayieh...@gmail.com wrote:
On Wed, Aug 4, 2010 at 1:16 PM, Nazri Ramliy ayieh...@gmail.com wrote:
which call expand_in_path(), which in turns call globpath(), fails with
the exact same argument c:/src/vim/**, misc* and 0 for path, file and
expand_options, respectively.
Help!
I think I found the solution. recursive should be reset to FALSE before
calling expand_in_path in gen_expand_wildcards().
I'll submit a patch soon.
Patch attached (0001).
I'm also working on a test script to test the find completion stuff.
I'll send a patch for that one too, soon.
Preliminary patch attached (0002). It only test for relative path
with '**' notation.
Obviously there should be more path values that it should test but I gotta
run now and I think that having a preliminary test is much better than having
no test at all. This one runs fine on unix.
I'm also attaching a third patch (0003) that (BLINDLY) adds test73.out to the
other platforms. It is added here so that others can try it out.
nazri.
--
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
From 99bfc4658184e10a01db239bba8e91da42b580b2 Mon Sep 17 00:00:00 2001
From: Nazri Ramliy ayieh...@gmail.com
Date: Wed, 4 Aug 2010 17:16:17 +0800
Subject: [PATCH 1/3] find completion: use globpath for both windows and unix
---
src/misc1.c | 22 +++---
1 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/src/misc1.c b/src/misc1.c
index b0f7e91..99b021d 100644
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9578,14 +9578,10 @@ expand_in_path(gap, pattern, flags)
char_u *curdir;
garray_T path_ga;
int i;
-# ifdef WIN3264
-char_u *file_pattern;
-# else
char_u *files = NULL;
char_u *s; /* start */
char_u *e; /* end */
char_u *paths = NULL;
-# endif
if ((curdir = alloc((unsigned)MAXPATHL)) == NULL)
return 0;
@@ -9594,20 +9590,6 @@ expand_in_path(gap, pattern, flags)
expand_path_option(curdir, path_ga);
vim_free(curdir);
path_list = (char_u **)(path_ga.ga_data);
-# ifdef WIN3264
-if ((file_pattern = alloc((unsigned)MAXPATHL)) == NULL)
- return 0;
-for (i = 0; i path_ga.ga_len; i++)
-{
- if (STRLEN(path_list[i]) + STRLEN(pattern) + 2 MAXPATHL)
- continue;
- STRCPY(file_pattern, path_list[i]);
- STRCAT(file_pattern, /);
- STRCAT(file_pattern, pattern);
- mch_expandpath(gap, file_pattern, EW_DIR|EW_ADDSLASH|EW_FILE);
-}
-vim_free(file_pattern);
-# else
for (i = 0; i path_ga.ga_len; i++)
{
if (paths == NULL)
@@ -9654,7 +9636,6 @@ expand_in_path(gap, pattern, flags)
}
vim_free(files);
-# endif
return gap-ga_len;
}
@@ -9795,7 +9776,10 @@ gen_expand_wildcards(num_pat, pat, num_file, file, flags)
{
#if defined(FEAT_SEARCHPATH)
if (*p != '.' !vim_ispathsep(*p) (flags EW_PATH))
+ {
+ recursive = FALSE;
add_pat = expand_in_path(ga, p, flags);
+ }
else
#endif
add_pat = mch_expandpath(ga, p, flags);
--
1.7.2.1.6.g61bf12
From 4be95b821c6542c5c69932e8fa90ad4416af498a Mon Sep 17 00:00:00 2001
From: Nazri Ramliy ayieh...@gmail.com
Date: Wed, 4 Aug 2010 10:38:25 +0800
Subject: [PATCH 2/3] Test script for testing find completion
---
src/testdir/Makefile |2 +-
src/testdir/test73.in | 18 ++
src/testdir/test73.ok |3 +++
3 files changed, 22 insertions(+), 1 deletions(-)
create mode 100644 src/testdir/test73.in
create mode 100644 src/testdir/test73.ok
diff --git a/src/testdir/Makefile b/src/testdir/Makefile
index f970b26..4951dc2 100644
--- a/src/testdir/Makefile
+++ b/src/testdir/Makefile
@@ -23,7 +23,7 @@ SCRIPTS = test1.out test2.out test3.out test4.out test5.out test6.out \
test54.out test55.out test56.out test57.out test58.out \
test59.out test60.out test61.out test62.out test63.out \
test64.out test65.out test66.out test67.out test68.out \
- test69.out test70.out test71.out test72.out
+ test69.out test70.out test71.out test72.out test73.out
SCRIPTS_GUI = test16.out
diff --git a/src/testdir/test73.in b/src/testdir/test73.in
new file mode 100644
index 000..ca8750c
--- /dev/null
+++ b/src/testdir/test73.in
@@ -0,0 +1,18 @@
+Tests for find completion.
+
+STARTTEST
+:!mkdir -p Xfind/in/path
+:!echo Holy Grail Xfind/file.txt
+:!echo Jimmy Hoffa Xfind/in/file.txt
+:!echo E.T. Xfind/in/path/file.txt
+:set path=Xfind/**
+:set nocp
+:find file
+:w! test.out
+:find file
+:w test.out
+:find file
+:w test.out
+:qa!
+ENDTEST
+
diff --git a/src/testdir/test73.ok b/src/testdir/test73.ok
new file mode 100644
index 000..bf1d433
--- /dev/null
+++ b/src/testdir/test73.ok
@@ -0,0 +1,3 @@
+Holy Grail
+Jimmy Hoffa
+E.T.
--
1.7.2.1.6.g61bf12
From 054274787c07e6bb0dc03bc9ca628ea8f7bd49b8 Mon Sep 17 00:00:00 2001
From: Nazri Ramliy ayieh...@gmail.com
Date: Wed, 4 Aug 2010
Re: Question about :find completion support in Vim 7.3b
Nazri Ramliy wrote: On Wed, Aug 4, 2010 at 4:39 AM, Bram Moolenaar b...@moolenaar.net wrote: Attached is the fix on top of Revision: 7d1044b27e. Thanks and sorry, I suppose I caused this problem. That is minuscule compared to all the problems that I have caused with all this find-completion stuff :) Prove (this will show that I'm still naive at grokking vim source code): We shouldn't have to write window-specific code for the find completion because apparently f_globpath() works fine on both unix and windows and it happily uses globpath() to do its job. To cut a long story short, I found this out while writing a test script for testing the find completion stuff. With that realization I'm going to investigate why is it that on windows, globpath() as used in the expand_in_path() function fails to do its jobs when it works just fine when used in f_globpath(), with the exact same set of arguments. I'm attaching a patch to produce my debug version of eval.c and misc1.c which will show this problem for those who would like to help in investigating this. On windows, doing :echo globpath(c:/src/vim/**, misc*) calls f_globpath(), which in turn calls globpath() with the arguments c:/src/vim/**, misc* and 0 for path, file and expand_options, respectively and it successfully gives c:\src\vim\src\misc1.c c:\src\vim\src\misc2.c c:\src\vim\src\proto\misc1.c c:\src\vim\src\proto\misc2.c c:\src\vim\src\ObjC\misc1.obj c:\src\vim\src\ObjC\misc2.obj c:\src\vim\src\ObjG\misc1.obj c:\src\vim\src\ObjG\misc2.obj while doing :set path=c:/src/vim/** :find misctab which call expand_in_path(), which in turns call globpath(), fails with the exact same argument c:/src/vim/**, misc* and 0 for path, file and expand_options, respectively. If the arguments are the same the returned values should be the same. You will need to use a debugger to find out what really happens. I noticed another problem: with 'path' set to ./** and in an empty buffer :find completion crashes. I fixed it. Maybe I'll have time to look at the completion code, looks like you are getting lost. -- The process for understanding customers primarily involves sitting around with other marketing people and talking about what you would to if you were dumb enough to be a customer. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.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
Re: Question about :find completion support in Vim 7.3b
On Wed, Aug 4, 2010 at 7:20 PM, Bram Moolenaar b...@moolenaar.net wrote: If the arguments are the same the returned values should be the same. You will need to use a debugger to find out what really happens. I did. The problem is due to the static nature of recursive in gen_expand_wildcards(). Please see my patches to fix this in an earlier follow-up message [1]. I noticed another problem: with 'path' set to ./** and in an empty buffer :find completion crashes. I fixed it. Thanks. I'll add this check to the test script. Maybe I'll have time to look at the completion code, looks like you are getting lost. The light bulb turned on for me when I insert a debug message to print the value of recursive at the top of gen_expand_wildcards(). It revealed that when doing :echo globpath(c:/src/**, misc*) globpath() is called with recursive set to FALSE, while doing :find misctab globpath() is called with recursive set to TRUE, which is why it doesn't work the same way. The patch attached in [1] seems to fix that. With that patch the find completion uses the same code for both windows and unix. nazri. [1] http://article.gmane.org/gmane.editors.vim.devel/27663 -- 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
Re: Question about :find completion support in Vim 7.3b
Nazri Ramliy wrote: On Wed, Aug 4, 2010 at 7:20 PM, Bram Moolenaar b...@moolenaar.net wrote: If the arguments are the same the returned values should be the same. You will need to use a debugger to find out what really happens. I did. The problem is due to the static nature of recursive in gen_expand_wildcards(). Please see my patches to fix this in an earlier follow-up message [1]. Yeah, I included this now. I fixed a memory leak and moved the concatenation of strings to a separate function. I noticed another problem: with 'path' set to ./** and in an empty buffer :find completion crashes. =A0I fixed it. Thanks. I'll add this check to the test script. Maybe I'll have time to look at the completion code, looks like you are getting lost. The light bulb turned on for me when I insert a debug message to print the value of recursive at the top of gen_expand_wildcards(). It revealed that when doing :echo globpath(c:/src/**, misc*) globpath() is called with recursive set to FALSE, while doing :find misctab globpath() is called with recursive set to TRUE, which is why it doesn't work the same way. The patch attached in [1] seems to fix that. With that patch the find completion uses the same code for both windows and unix. OK. I also set recursive back to TRUE to stay on the safe side. -- hundred-and-one symptoms of being an internet addict: 1. You actually wore a blue ribbon to protest the Communications Decency Act. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.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
Re: Question about :find completion support in Vim 7.3b
On Wed, Aug 4, 2010 at 12:46 PM, Bram Moolenaar b...@moolenaar.net wrote: Nazri Ramliy wrote: On Wed, Aug 4, 2010 at 7:20 PM, Bram Moolenaar b...@moolenaar.net wrote: If the arguments are the same the returned values should be the same. You will need to use a debugger to find out what really happens. I did. The problem is due to the static nature of recursive in gen_expand_wildcards(). Please see my patches to fix this in an earlier follow-up message [1]. Yeah, I included this now. I fixed a memory leak and moved the concatenation of strings to a separate function. I noticed another problem: with 'path' set to ./** and in an empty buffer :find completion crashes. =A0I fixed it. Thanks. I'll add this check to the test script. Maybe I'll have time to look at the completion code, looks like you are getting lost. The light bulb turned on for me when I insert a debug message to print the value of recursive at the top of gen_expand_wildcards(). It revealed that when doing :echo globpath(c:/src/**, misc*) globpath() is called with recursive set to FALSE, while doing :find misctab globpath() is called with recursive set to TRUE, which is why it doesn't work the same way. The patch attached in [1] seems to fix that. With that patch the find completion uses the same code for both windows and unix. OK. I also set recursive back to TRUE to stay on the safe side. Seems to work well; the speedup is noticeable on WinXP. Nazri, for the future, you may want to try and add path completion for :cd 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
Re: Question about :find completion support in Vim 7.3b
Nazri Ramliy wrote: On Wed, Aug 4, 2010 at 7:20 PM, Bram Moolenaar b...@moolenaar.net wrote: If the arguments are the same the returned values should be the same. You will need to use a debugger to find out what really happens. I did. The problem is due to the static nature of recursive in gen_expand_wildcards(). Please see my patches to fix this in an earlier follow-up message [1]. I noticed another problem: with 'path' set to ./** and in an empty buffer :find completion crashes. =A0I fixed it. Thanks. I'll add this check to the test script. The test script works OK on Unix, but on MS-Windows it only finds two of the three files. Also interactively, so this appears to be a problem in the implementation. I already changed it to use three separate mkdir commands, as mkdir -p doesn't work on MS-Windows (and some old Unixen too). I used an edit command instead of :!echo to make it portable. What I can't figure out is a portable way to delete the created directories. rmdir /s /q Xfind should work, but it gives an error for the /s option... -- The goal of science is to build better mousetraps. The goal of nature is to build better mice. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.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
Re: Question about :find completion support in Vim 7.3b
Am 03.08.2010 02:33, schrieb Nazri Ramliy: On Tue, Aug 3, 2010 at 8:07 AM, Nazri Ramliyayieh...@gmail.com wrote: On Tue, Aug 3, 2010 at 7:51 AM, Ajit Thakkara...@unb.ca wrote: Revision: 7d1044b27e On WinXP, attempting find completion leads to a crash. gvim -N -u NONE a.tex :findTab Vim crashes The same happens with :find aTab Ajit Thanks for testing it. I'll investigate the crash. Attached is the fix on top of Revision: 7d1044b27e. nazri. Hi, I get this warning and :find tab crashes: f:\tmp\vim73\vim\src\misc1.c(9597) : warning C4700: Die nicht initialisierte lokale Variable file_pattern wurde verwendet. translation: usage of non-initialised variable misc1.c is at this version: F:\tmp\vim73\vim\srchg log misc1.c -l1 changeset: 2470:6570c136be32 branch: vim73 user:Bram Moolenaar b...@vim.org date:Mon Aug 02 21:33:37 2010 +0200 summary: Improvements for :find completion. (Nazri Ramliy) Thomas -- 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
Re: Question about :find completion support in Vim 7.3b
Nazri Ramliy wrote: On Tue, Aug 3, 2010 at 8:07 AM, Nazri Ramliy ayieh...@gmail.com wrote: On Tue, Aug 3, 2010 at 7:51 AM, Ajit Thakkar a...@unb.ca wrote: 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 aTab Ajit Thanks for testing it. I'll investigate the crash. Attached is the fix on top of Revision: 7d1044b27e. Thanks and sorry, I suppose I caused this problem. -- Q: What's a light-year? A: One-third less calories than a regular year. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.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
Re: Question about :find completion support in Vim 7.3b
On Wed, Aug 4, 2010 at 4:39 AM, Bram Moolenaar b...@moolenaar.net wrote:
Attached is the fix on top of Revision: 7d1044b27e.
Thanks and sorry, I suppose I caused this problem.
That is minuscule compared to all the problems that I have caused with
all this find-completion stuff :)
Prove (this will show that I'm still naive at grokking vim source code):
We shouldn't have to write window-specific code for the find completion
because apparently f_globpath() works fine on both unix and windows and
it happily uses globpath() to do its job.
To cut a long story short, I found this out while writing a test script
for testing the find completion stuff.
With that realization I'm going to investigate why is it that on
windows, globpath() as used in the expand_in_path() function fails to do
its jobs when it works just fine when used in f_globpath(), with the
exact same set of arguments.
I'm attaching a patch to produce my debug version of eval.c and
misc1.c which will show this problem for those who would like to help in
investigating this.
On windows, doing
:echo globpath(c:/src/vim/**, misc*)
calls f_globpath(), which in turn calls globpath() with the arguments
c:/src/vim/**, misc* and 0 for path, file and expand_options,
respectively and it successfully gives
c:\src\vim\src\misc1.c
c:\src\vim\src\misc2.c
c:\src\vim\src\proto\misc1.c
c:\src\vim\src\proto\misc2.c
c:\src\vim\src\ObjC\misc1.obj
c:\src\vim\src\ObjC\misc2.obj
c:\src\vim\src\ObjG\misc1.obj
c:\src\vim\src\ObjG\misc2.obj
while doing
:set path=c:/src/vim/**
:find misctab
which call expand_in_path(), which in turns call globpath(), fails with
the exact same argument c:/src/vim/**, misc* and 0 for path, file and
expand_options, respectively.
Help!
nazri.
--
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
diff --git a/src/eval.c b/src/eval.c
index 8a26b66..db6fdb5 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -11692,8 +11692,15 @@ f_globpath(argvars, rettv)
if (file == NULL || error)
rettv-vval.v_string = NULL;
else
- rettv-vval.v_string = globpath(get_tv_string(argvars[0]), file,
- flags);
+{
+ char_u *p = get_tv_string(argvars[0]);
+ smsg(X calling globpath:);
+ smsg(X path: '%s', p);
+ smsg(X file: '%s', file);
+ smsg(X flags: '%d', flags);
+ rettv-vval.v_string = globpath(p, file, flags);
+ smsg(X result: '%s', rettv-vval.v_string);
+}
}
/*
diff --git a/src/misc1.c b/src/misc1.c
index b0f7e91..eeed9f8 100644
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9578,14 +9578,10 @@ expand_in_path(gap, pattern, flags)
char_u *curdir;
garray_T path_ga;
int i;
-# ifdef WIN3264
-char_u *file_pattern;
-# else
char_u *files = NULL;
char_u *s; /* start */
char_u *e; /* end */
char_u *paths = NULL;
-# endif
if ((curdir = alloc((unsigned)MAXPATHL)) == NULL)
return 0;
@@ -9594,20 +9590,6 @@ expand_in_path(gap, pattern, flags)
expand_path_option(curdir, path_ga);
vim_free(curdir);
path_list = (char_u **)(path_ga.ga_data);
-# ifdef WIN3264
-if ((file_pattern = alloc((unsigned)MAXPATHL)) == NULL)
- return 0;
-for (i = 0; i path_ga.ga_len; i++)
-{
- if (STRLEN(path_list[i]) + STRLEN(pattern) + 2 MAXPATHL)
- continue;
- STRCPY(file_pattern, path_list[i]);
- STRCAT(file_pattern, /);
- STRCAT(file_pattern, pattern);
- mch_expandpath(gap, file_pattern, EW_DIR|EW_ADDSLASH|EW_FILE);
-}
-vim_free(file_pattern);
-# else
for (i = 0; i path_ga.ga_len; i++)
{
if (paths == NULL)
@@ -9626,12 +9608,22 @@ expand_in_path(gap, pattern, flags)
}
}
+verbose_enter_scroll();
+smsg(Y calling globpath:);
+smsg(Y path: '%s', paths);
+smsg(Y file: '%s', pattern);
+smsg(Y flags: '%d', 0);
files = globpath(paths, pattern, 0);
vim_free(paths);
if (files == NULL)
+{
+ msg(Y files is NULL);
return 0;
+}
+smsg(Y result: '%s', files);
+verbose_leave();
/* Copy each path in files into gap */
s = e = files;
while (*s != NUL)
@@ -9654,7 +9646,6 @@ expand_in_path(gap, pattern, flags)
}
vim_free(files);
-# endif
return gap-ga_len;
}
Re: Question about :find completion support in Vim 7.3b
On Mon, Aug 2, 2010 at 8:49 AM, Nazri Ramliy ayieh...@gmail.com wrote:
On Thu, Jul 29, 2010 at 4:39 AM, Bram Moolenaar b...@moolenaar.net 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.
nazri.
--
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
From 9540345bbf11461d7d8723306f1a9b2272e3661d Mon Sep 17 00:00:00 2001
From: nazri ayieh...@gmail.com
Date: Mon, 2 Aug 2010 16:10:56 +0800
Subject: [PATCH] Make find completion work on windows platform
---
src/misc1.c | 78 +++---
1 files changed, 68 insertions(+), 10 deletions(-)
diff --git a/src/misc1.c b/src/misc1.c
index 11c2b1b..8b96b68 100644
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9350,7 +9350,9 @@ expand_path_option(curdir, gap)
STRMOVE(buf + curdir_len, buf + curdir_len + 1);
}
- addfile(gap, buf, EW_NOTFOUND|EW_DIR|EW_FILE);
+ if (ga_grow(gap, 1) == FAIL)
+ return;
+ ((char_u **)gap-ga_data)[gap-ga_len++] = vim_strsave(buf);
}
vim_free(buf);
@@ -9378,8 +9380,11 @@ get_path_cutoff(fname, gap)
{
int j = 0;
- while (fname[j] == path_part[i][j] fname[j] != NUL
- path_part[i][j] != NUL)
+ while ((fname[j] == path_part[i][j]
+#if defined(WIN3264)
+ || vim_ispathsep(fname[j]) vim_ispathsep(path_part[i][j])
+#endif
+ ) fname[j] != NUL path_part[i][j] != NUL)
j++;
if (j maxlen)
{
@@ -9389,8 +9394,15 @@ get_path_cutoff(fname, gap)
}
/* Skip to the file or directory name */
-while (cutoff != NULL vim_ispathsep(*cutoff) *cutoff != NUL)
- mb_ptr_adv(cutoff);
+if (cutoff != NULL)
+ while (
+#if defined(WIN3264)
+ *cutoff == '/'
+#else
+ vim_ispathsep(*cutoff)
+#endif
+ )
+ mb_ptr_adv(cutoff);
return cutoff;
}
@@ -9454,7 +9466,13 @@ uniquefy_paths(gap, pattern)
char_u *dir_end = gettail(path);
len = (int)STRLEN(path);
- while (dir_end path !vim_ispathsep(*dir_end))
+ while (dir_end path
+#if
Re: Question about :find completion support in Vim 7.3b
Nazri Ramliy wrote: On Thu, Jul 29, 2010 at 4:39 AM, Bram Moolenaar b...@moolenaar.net 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). 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\**. I'm not including this patch. Resetting recursive while it was set elsewhere is wrong. The next call would do the recursive call and cause problems. -- Engineers are always delighted to share wisdom, even in areas in which they have no experience whatsoever. Their logic provides them with inherent insight into any field of expertise. This can be a problem when dealing with the illogical people who believe that knowledge can only be derived through experience. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.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
Re: Question about :find completion support in Vim 7.3b
Nazri Ramliy wrote: On Mon, Aug 2, 2010 at 8:49 AM, Nazri Ramliy ayieh...@gmail.com wrote: On Thu, Jul 29, 2010 at 4:39 AM, Bram Moolenaar b...@moolenaar.net 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. -- For humans, honesty is a matter of degree. Engineers are always honest in matters of technology and human relationships. That's why it's a good idea to keep engineers away from customers, romantic interests, and other people who can't handle the truth. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.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
Re: Question about :find completion support in Vim 7.3b
On Mon, Aug 2, 2010 at 5:10 PM, Bram Moolenaar b...@moolenaar.net wrote: Nazri Ramliy wrote: On Mon, Aug 2, 2010 at 8:49 AM, Nazri Ramliy ayieh...@gmail.com wrote: On Thu, Jul 29, 2010 at 4:39 AM, Bram Moolenaar b...@moolenaar.net 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 aTab 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
Re: Question about :find completion support in Vim 7.3b
On Tue, Aug 3, 2010 at 7:51 AM, Ajit Thakkar a...@unb.ca wrote: 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 aTab Ajit Thanks for testing it. I'll investigate the crash. nazri. -- 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
Re: Question about :find completion support in Vim 7.3b
On Tue, Aug 3, 2010 at 8:07 AM, Nazri Ramliy ayieh...@gmail.com wrote:
On Tue, Aug 3, 2010 at 7:51 AM, Ajit Thakkar a...@unb.ca wrote:
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 aTab
Ajit
Thanks for testing it.
I'll investigate the crash.
Attached is the fix on top of Revision: 7d1044b27e.
nazri.
--
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
From 0e74ad37a897ea651ac3671b8d442ac4601ad754 Mon Sep 17 00:00:00 2001
From: nazri ayieh...@gmail.com
Date: Tue, 3 Aug 2010 08:25:43 +0800
Subject: [PATCH] Fix use of unallocated buffer for find completion on windows
---
src/misc1.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/misc1.c b/src/misc1.c
index e564c5c..6e988fa 100644
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9586,6 +9586,11 @@ expand_in_path(gap, pattern, flags)
return 0;
mch_dirname(curdir, MAXPATHL);
+# ifdef WIN3264
+if ((file_pattern = alloc((int)(MAXPATHL))) == NULL)
+ return 0;
+# endif
+
expand_path_option(curdir, path_ga);
vim_free(curdir);
path_list = (char_u **)(path_ga.ga_data);
@@ -9599,6 +9604,8 @@ expand_in_path(gap, pattern, flags)
STRCAT(file_pattern, pattern);
mch_expandpath(gap, file_pattern, EW_DIR|EW_ADDSLASH|EW_FILE);
}
+
+vim_free(file_pattern);
# else
for (i = 0; i path_ga.ga_len; i++)
{
--
1.7.2.1.6.g61bf12
Re: Question about :find completion support in Vim 7.3b
On Thu, Jul 29, 2010 at 4:39 AM, Bram Moolenaar b...@moolenaar.net 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).
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\**.
nazri.
--
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
diff --git a/src/misc1.c b/src/misc1.c
index 11c2b1b..48dcd36 100644
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9675,7 +9675,10 @@ gen_expand_wildcards(num_pat, pat, num_file, file, flags)
#ifdef SPECIAL_WILDCHAR
return mch_expand_wildcards(num_pat, pat, num_file, file, flags);
#else
+{
+ recursive = FALSE;
return FAIL;
+}
#endif
#ifdef SPECIAL_WILDCHAR
Re: Question about :find completion support in Vim 7.3b
On Wed, Jul 28, 2010 at 8:53 AM, Nazri Ramliy ayieh...@gmail.com wrote: On Wed, Jul 28, 2010 at 2:44 AM, Nazri Ramliy ayieh...@gmail.com wrote: When I set 'path' to something like c:\src\** the completion doesn't work: :find tab has no effect. When the patch is applied on top of my patches sent in [1], vim (on Windows) crashes. I'll investigate this later. I've found that the current implementation of the completion for find/sfind/tabfind will not work on Windows due to the non-availability of the equivalent mch_expand_wildcards for that platform: $ grep -l mch_expand_wildcards os_*.c os_riscos.c os_unix.c os_vms.c A related issue is highlighted by Ingo Karkat in a recent thread [1]. nazri. [1] http://article.gmane.org/gmane.editors.vim.devel/27471 -- 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
Re: Question about :find completion support in Vim 7.3b
Nazri Ramliy wrote: On Wed, Jul 28, 2010 at 8:53 AM, Nazri Ramliy ayieh...@gmail.com wrote: On Wed, Jul 28, 2010 at 2:44 AM, Nazri Ramliy ayieh...@gmail.com wrote: When I set 'path' to something like c:\src\** the completion doesn't work: :find tab has no effect. When the patch is applied on top of my patches sent in [1], vim (on Windows) crashes. I'll investigate this later. I've found that the current implementation of the completion for find/sfind/tabfind will not work on Windows due to the non-availability of the equivalent mch_expand_wildcards for that platform: $ grep -l mch_expand_wildcards os_*.c os_riscos.c os_unix.c os_vms.c A related issue is highlighted by Ingo Karkat in a recent thread [1]. I have included the recent patches, but not the one that resets recursive in gen_expand_wildcards(). That is probably causing that crash. It appears to do what I expect it to do. :find termTab gives a nice list of the possible matches, in the local directory and in /usr/include. I did a few minor style edits. I did fix that one function was returning a struct from the stack, that doesn't work reliably. It wasn't needed anyway. I haven't checked the code for correctness. Please test! Please make further patches on top of the current version. -- I used to wonder about the meaning of life. But I looked it up in the dictionary under L and there it was - the meaning of life. It was less than I expected. - Dogbert /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.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
Re: Question about :find completion support in Vim 7.3b
On Tue, Jul 27, 2010 at 10:55 AM, Ajit Thakkar a...@unb.ca wrote: On Mon, Jul 26, 2010 at 9:16 PM, Nazri Ramliy ayieh...@gmail.com wrote: On Tue, Jul 27, 2010 at 6:01 AM, Yegappan Lakshmanan yegapp...@gmail.com wrote: When I press Tab after typing :find , I expected that the filenames from the current directory will be completed. But none of the filenames are displayed. If I try to complete file names using ./ or .\, then the file names are displayed. Is this the expected behavior? No this is a bug. It should behave as you expected. Does this happen on both console vim and gvim? Confirmed for both console and gui. I managed to get my hands on a Windows (Vista) machine. Attached patch should make the find/sfind/tabfind completion works (almost) as expected. It works when 'path' is .,, When I set 'path' to something like c:\src\** the completion doesn't work: :find tab has no effect. If nobody beat me to it I'll investigate further later. nazri -- 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 find-completion-win.patch Description: Binary data
Re: Question about :find completion support in Vim 7.3b
On Wed, Jul 28, 2010 at 2:44 AM, Nazri Ramliy ayieh...@gmail.com wrote: When I set 'path' to something like c:\src\** the completion doesn't work: :find tab has no effect. When the patch is applied on top of my patches sent in [1], vim (on Windows) crashes. I'll investigate this later. nazri. [1] http://article.gmane.org/gmane.editors.vim.devel/27393 -- 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
Re: Question about :find completion support in Vim 7.3b
On Tue, Jul 27, 2010 at 6:01 AM, Yegappan Lakshmanan yegapp...@gmail.com wrote: Hi, I am trying the new completion support for the :find command in Vim7.3b on MS-Windows (XP). The 'path' option is set to the default value (.,,). Thanks for trying out the :find completion feature on MS-Windows. When I press Tab after typing :find , I expected that the filenames from the current directory will be completed. But none of the filenames are displayed. If I try to complete file names using ./ or .\, then the file names are displayed. Is this the expected behavior? No this is a bug. It should behave as you expected. Does this happen on both console vim and gvim? Sadly I don't have a windows machine handy to reproduce this (maybe it's a blessing? :) Dimitar Dimitrov reported that the :find completion on Windows XP gvim crashes [1]. I'm working on refining the :find completion right now. I will post a new patch soon. nazri. [1] http://article.gmane.org/gmane.editors.vim.devel/27081 -- 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
