Re: globcomplete desctroys file completion

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Feb 21, 11:16am, Bart Schaefer wrote:
}
} Interesting.  Comparing the traces I find that at _path_files:238 with
} globcomplete, menu=yes is being set, and at _path_files:623 the value
} of $compstate[pattern_match] is "*" so the code branches to line 667
} instead of 629.  This sends us around the (for i in "$tmp1[@]"; do)
} loop at line 673 a bunch of times, each time adding either "texlive"
} or "texlive2008" as a completion with a different path tail as a hidden
} suffix.

Fooling with this a bit more ... that loop looks like:

            for i in "$tmp1[@]"; do
	      tmpdisp=("${i%%/*}")
	      _list_files tmpdisp "$prepath$realpath$testpath"
	      compadd "$tmp4[@]" -s "/${i#*/}" $listopts - "$tmpdisp"
	    done

If I change line 674 to this:

              tmpdisp=($i)

then I get the same results with globcomplete set as without:

torch% setopt globcomplete 
torch% print Tmp/texlive/t
                        ^
                        cursor on this final slash

However, I suspect using $i there is only working in this specific
example and not in the general case.  The resulting compadd looks
like (line break added for readability):

    compadd -Qf -J -default- -J -default- -p Tmp/ -s '' -W Tmp/ \
     -M 'r:|/=* r:|=*' -s /temp - texlive/temp

(and similarly for all the other files in texlive and texlive2008).
That looks wrong to me in any case because the description of -W
indicates that it's used "together with" -p ... but also note that
we have two -s options, so something is rotten in tmp4 at line 668,
is it not?

(However, in the NO_globcomplete case, the compadd still has identical
arguments to the -p and -W options, so maybe that's a red herring and/or
the -W doc is imprecise.)