On Sat, Jul 24, 2010 at 5:00 AM, Bram Moolenaar <b...@moolenaar.net> wrote:
> Perhaps the algorithm can remove the path when there is only one choice,
> but keep a longer path otherwise.  This also depends on the first entry
> in 'path'.  Usually it's ".", thus if "./{shortened-match}" exists and
> is different from the long name then it can't be shortened.

Here's the ideal behavior that I'm aiming for:

instead of

        ./term.h        include/term.h  term.h

It should be

        ./term.h        /usr/include/term.h

Or possibly

        ./term.h        /usr/include/term.h        foo/term.h

when you have another term.h in some subdirectories of your path setting, say
".,/usr/include,/home/user/project/**,,".

In summary for duplicate filenames don't "basename" them, instead make them
uniquely "find-able" while keeping the names as short as possible and when that
is not possible use the fullpath instead.

My initial attempt at fixing the duplicates was roughly in that
direction but was
stalled because the other (non-)solution that I posted seemed simpler
to implement.

I'll look into this again sometime next week.

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

Raspunde prin e-mail lui