On Sun, 22 Jun 2008 23:23:42 +0100
Peter Stephenson <[EMAIL PROTECTED]> wrote:
> On Thu, 19 Jun 2008 21:15:39 +0000
> Clint Adams <[EMAIL PROTECTED]> wrote:
> > Using only the following zshrc, ls /tmp/.X2<tab> results in the entire
> > argument being elided (/tmp/.X* exists but /tmp/.X2* does not).
> >
> > --8<--zshrc--8<--
> > autoload -U compinit
> > compinit
> >
> > zstyle ':completion:*' completer _approximate
> >
> > --8<--zshrc--8<--
>
> It's something to do with using the -U argument to compadd when you've
> got ambiguous completions: it works fine when there's only a single
> completion. It was triggered by adding the -U's to do approximation in
> non-final path segments (even before the compmatch change).
Slight cop out, but the "-M <matcher>" option is not documented as doing
anything useful with the -U option and removing that wherever it occurs
together with -U makes it better. (In case you're worried, this is not
the matcher from the matcher list, which is passed down to compfiles
earlier on to generate the list of trial completions rather than to
compadd; the matcher here appears to be some kind of "it works better
that way" kludge, I think to help path completion by allowing anything
that matches completions of partial path prefixes.) Strictly I think
the -M argument should be ignored, and it isn't, which is probably a
bug, but I don't have time to investigate bugs that can be easily worked
around, and I think given the -U the new code is more correct anyway.
I've only removed the -M where there is a -U option.
This improves things to the point where the unambiguous prefix is kept
and the trial completions are available. I think the main difference in
my own set-up was having menucomplete set, but my experiences are a bit
ambiguous.
I'm now a little worried it should be going into menu completion at this
point even without the option being set; the documentation for
_approximate says "the completer will normally start menu completion"
but in the test case above it doesn't. I'm not clear how it starts menu
completion, since _approximate only mentions menu completion in a
comment at the top, implying it is done somewhere within that function
that I can't find. If someone who doesn't usually have menu completion
set can confirm that it's still not doing the right thing, I will see if
I can find any further clues to how this should be happening.
I couldn't find anything this change broke and I don't think it's
supposed to have any negative effect.
The reason this happens with _approximate, by the way, seems to be due
to addition of the default completion:
compadd -V -default- -U -Q - /tmp/.X2
to the array of normal matches (despite the fact there is no -M argument
here---possibly the discrepancy between the two is confusing it). I
traced the bug down to the function (assuming you've got /tmp/.X2 on
the command line---the tmp1 contents aren't important, they're just what
I happen to have):
local -a tmp1
tmp1=( .X0-lock .X11-unix .Xfoo )
compadd -J -default- -U -Qf -J -default- -p /tmp/ -s '' \
-W /tmp/ -M 'r:|/=* r:|=*' -a tmp1
compadd -V -default- -U -Q - /tmp/.X2
However, I don't think that helps us with the remaining problem
because that extra compadd can't explain how we get into menu
completion.
(I have kept this mail short by expunging phrases like "in an obscure
fashion" and "undocumented" and "incomprehensible", as well as sarcastic
asides like "of course" and "as I'm sure you'd guessed", and
long-suffering comments like "spending weeks of my life", from wherever
they naturally occur. You can have fun reinserting them. You can have
even more fun writing a lex programme to fill out a completion system
bug fix posting with the appropriate comments.)
Index: Completion/Unix/Type/_path_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_path_files,v
retrieving revision 1.31
diff -u -r1.31 _path_files
--- Completion/Unix/Type/_path_files 21 Jun 2008 21:36:01 -0000 1.31
+++ Completion/Unix/Type/_path_files 30 Jun 2008 19:55:41 -0000
@@ -598,7 +598,7 @@
compadd -U -Qf "[EMAIL PROTECTED]" -p "$IPREFIX$linepath$tmp2" \
-s "/${tmp3#*/}$ISUFFIX" \
-W "$prepath$realpath$testpath" \
- "[EMAIL PROTECTED]" -M "r:|/=* r:|=*" \
+ "[EMAIL PROTECTED]" \
$listopts \
-a tmp1
else
@@ -608,7 +608,7 @@
compadd -U -Qf "[EMAIL PROTECTED]" -p "$IPREFIX$linepath$tmp2" \
-s "$ISUFFIX" \
-W "$prepath$realpath$testpath" \
- "[EMAIL PROTECTED]" -M "r:|/=* r:|=*" \
+ "[EMAIL PROTECTED]" \
$listopts \
-a tmp1
fi
@@ -617,7 +617,7 @@
compadd -U -Qf "[EMAIL PROTECTED]" -p "$IPREFIX$linepath$tmp2" \
-s "$ISUFFIX" \
-W "$prepath$realpath$testpath" \
- "[EMAIL PROTECTED]" -M "r:|/=* r:|=*" \
+ "[EMAIL PROTECTED]" \
$listopts \
-a tmp1
fi
@@ -627,7 +627,7 @@
tmp4=( -U -Qf "[EMAIL PROTECTED]" -p "$IPREFIX$linepath$tmp2"
-s "$ISUFFIX"
-W "$prepath$realpath$testpath"
- "[EMAIL PROTECTED]" -M "r:|/=* r:|=*" )
+ "[EMAIL PROTECTED]" )
if [[ -z "$listsfx" ]]; then
for i in "[EMAIL PROTECTED]"; do
tmpdisp=("${i%%/*}")
@@ -647,7 +647,7 @@
compadd -U -Qf "[EMAIL PROTECTED]" -p "$IPREFIX$linepath$tmp2" \
-s "$ISUFFIX" \
-W "$prepath$realpath$testpath" \
- "[EMAIL PROTECTED]" -M "r:|/=* r:|=*" \
+ "[EMAIL PROTECTED]" \
$listopts \
-a tmp1
fi
@@ -716,7 +716,7 @@
compadd -U -Qf "[EMAIL PROTECTED]" -p "$IPREFIX$linepath$tmp3/" \
-s "/$tmp4$i$ISUFFIX" \
-W "$prepath$realpath${mid%/*/}/" \
- "[EMAIL PROTECTED]" -M "r:|/=* r:|=*" $listopts - "$tmp2"
+ "[EMAIL PROTECTED]" $listopts - "$tmp2"
done
else
if [[ "$osuf" = */* ]]; then
@@ -747,7 +747,7 @@
compadd -U -Qf -p "$IPREFIX$linepath$tmp4" \
-s "$ISUFFIX" \
-W "$prepath$realpath$testpath" \
- "[EMAIL PROTECTED]" "[EMAIL PROTECTED]" -M "r:|/=* r:|=*"
$listopts -a tmp1
+ "[EMAIL PROTECTED]" "[EMAIL PROTECTED]" $listopts -a tmp1
fi
fi
fi
--
Peter Stephenson <[EMAIL PROTECTED]>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
