2010/8/15 Nazri Ramliy <[email protected]>:
> 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.
Excerpt from help 'path':
This is a list of directories which will be searched when using the
|gf|, [f, ]f, ^Wf, |:find|, |:sfind|, |:tabfind| and other commands,
provided that the file being searched for has a relative path (not
starting with "/", "./" or "../").
is the attached patch (review.patch) a better check for triggering
the find-completion?
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 f8e51a2..a9a61fb 100644
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9811,7 +9811,12 @@ gen_expand_wildcards(num_pat, pat, num_file, file, flags)
if (mch_has_exp_wildcard(p))
{
#if defined(FEAT_SEARCHPATH)
- if (*p != '.' && !vim_ispathsep(*p) && (flags & EW_PATH))
+ if ((flags & EW_PATH) && !mch_isFullName(p)
+ && STRNCMP(p, "./", 2) && STRNCMP(p, "../", 3)
+#if defined(MSWIN) || defined(MSDOS)
+ && STRNCMP(p, ".\\", 2) && STRNCMP(p, "..\\", 3)
+#endif
+ )
{
/* recursiveness is OK here */
recursive = FALSE;
