Re: PATCH: tricky.c (was messages from Andrej and Bart)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

Sven Wischnowsky writes:
 > 
 > Bart Schaefer wrote:
 > 
 > > Using 3.1.5-pws-11 with the patches Sven posted overnight (well, overnight
 > > US Pacific Time) 3/8-3/9, I get this strange behavior:
 > > 
 > > zsh% fpath=($PWD:h<TAB>
 > > zsh% fpath=(src/  
 > > 
 > > I expected to get "fpath=(/home/schaefer/src/" ...
 > 
 > That one is a poser... `expand-or-complete' never expanded this
 > without braces.

Ah ... you're right.  That would actually be fine, too (keep the old
behavior of it simply feeping on the above input); but it's completely
wrong to have it replace the input with a fragment of the parameter's
value.

 > If it expanded it, it wouldn't add a trailing slash
 > (but instead add a space, try `${PWD:h}<TAB>').

Yes, I know.

 > So this is handled by the completion code. There, it expands the
 > `$PWD:h', gets a path from it, and then tries to complete the last
 > pathname component.

Yes, but there isn't anything to which that last component should have
completed (there was no subdirectory "src" of the current directory).

 > The problem is that after expansion, the code can't find out
 > what came from the expansion in cases like `${foo}x<TAB>'.

Hrm ... so what was happening in the old completion code in this case?

 > So the patch just uses the expanded prefix if it has the problem that
 > the expanded prefix contains slashes and the original string doesn't.
 > Maybe a better solution would be to do nothing in such cases.

Does this apply only to file completion?  What if the expansion happens
in some other context where slashes aren't special?