Nazri Ramliy wrote: > 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?
That's a bit better than just checking for ".". I'll simplify it a bit to avoid string compares and the #ifdef. One remaining problem: - go to the Vim "src" directory - vi main.c - :set path=./proto - :find e<C-D> The first item is ./proto/eval.pro, somehow it's not shortened. It's probably because there also is ex_eval.pro. -- hundred-and-one symptoms of being an internet addict: 76. Your ISP regards you as a business partner rather than as a customer. /// Bram Moolenaar -- [email protected] -- 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
