RE: Path completion causing ambiguous path tail to disappear

["Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru>]

 causing ambiguous path tail to disappear
>
>
> This is not exactly a complaint, because I can (almost) get the behavior I
> want by using a style ... rather it's a question of whether the default
> behavior should be different.
>
> I have my zsh sources under /usr/src/local/zsh/.  With dev-19:
>
> zagzig[36] cd /usr/s/l/<TAB>
>
> The valid completions at this point should be
>
> /usr/src/local	/usr/src/linux /usr/share/libtool /usr/share/locale
>
> However, what happens is that the word on the command line is *shortened*,
> leaving me with
>
> zagzig[36] cd /usr/s/
>

I noted this as well. It was introduced at some time fairly recently, I
believe.

But I think, it shortens path if some possibility is invalid. E.g. I have
/u1/lager directory; if I try

ls /u/l/l<TAB> I get

bor@itsrm2% l /u/l
u1@   usr/

because /u1/lager/l* do not exist (or so my explanation).

In your case ... do you have /usr/s<anyhing> that cause the above to fail
(just as me?) May it be, that trailing '/' makes zsh look, if subdirectorues
exist?

Yes, I believe, zsh is oversmart here. And it was different at some point.

/andrej