2010/8/14 Bram Moolenaar <[email protected]>:
>
> Dominique Pelle wrote:
>
>> Bram Moolenaar wrote:
>>
>> >> Bug #2:
>> >>
>> >> Using the same file /tmp/foo/xxxxxx as above, file completion does
>> >> not work if I do:
>> >>
>> >> :cd /tmp
>> >> :find /tmp/fo<C-D> " does not work, no completion.
>> >>
>> >> For file completion to work in the current directory, I have to use:
>> >>
>> >> :cd /tmp
>> >> :find ./fo<C-D> " this works.
>> >>
>> >> I have not fixed this second bug yet. I assume that's not the expected
>> >> behavior, is it?
>> >
>> > It works OK for me. What is your 'path' set to? It should be the
>> > default, and it works for me with the default.
>> >
>> > When I complete ":find /tmp/fo" it shortens to ":find foo/". A bit
>> > strange, but it's correct.
>>
>>
>> Sorry, I did not describe well bug #2.
>>
>> Here is how I can reproduce it with Vim-7.3f (2562:5769dc787ec5):
>>
>> $ mkdir /tmp/foo
>> $ vim -u NONE -N -c 'set wildmode=longest,list'
>>
>> :set path?
>> path=.,/usr/include,,
>> :cd " go to home dir
>> :find /tmp/fo<Tab> " Good, completes to :find /tmp/foo/
>> :cd /tmp
>> :find /tmp/fo<Tab> " Bad, does not complete anything
>>
>> I assume that's not the expected behavior.
>
> OK, I see it now. It's interference between "longest" in 'wildmode' and
> the shortening that the :find completion is doing. Using CTRL-L shows
> it without changing the 'wildmode' option.
>
> At the last step, if you use CTRL-D instead of <Tab>, you see it lists
> "foo/". That's the shortened version of "/tmp/foo/". The method
> "longest" uses to find the longest common string doesn't really work
> here, because when there are multiple matches you get a short string
> which then has a different meaning. The shortening for :find completion
> only works if you use the whole result.
>
> Example: Suppose /tmp/foobar and /tmp/foofoo exist. Then completing
> ":find /tmp/fo" would result in ":find foo", since "foo" is the longest
> common part of "foobar" and "foofoo". But removing "/tmp/" now has
> changed the meaning, further completion on ":find foo" will give a
> different set of results.
>
> I'll add a remark in the todo list.
Attached patch fixes this issue.
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 c4a6015..f8e51a2 100644
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9722,6 +9722,9 @@ gen_expand_wildcards(num_pat, pat, num_file, file, flags)
char_u *p;
static int recursive = FALSE;
int add_pat;
+#if defined(FEAT_SEARCHPATH)
+ int did_expand_in_path = FALSE;
+#endif
/*
* expand_env() is called to expand things like "~user". If this fails,
@@ -9814,6 +9817,7 @@ gen_expand_wildcards(num_pat, pat, num_file, file, flags)
recursive = FALSE;
add_pat = expand_in_path(&ga, p, flags);
recursive = TRUE;
+ did_expand_in_path = TRUE;
}
else
#endif
@@ -9838,7 +9842,7 @@ gen_expand_wildcards(num_pat, pat, num_file, file, flags)
}
#if defined(FEAT_SEARCHPATH)
- if (ga.ga_len > 0 && (flags & EW_PATH))
+ if (did_expand_in_path == TRUE && ga.ga_len > 0 && (flags & EW_PATH))
uniquefy_paths(&ga, p);
#endif
if (p != pat[i])
