Bug#486785: tab completion broken
On Sun, Jul 6, 2008 at 21:51, Peter Stephenson <[EMAIL PROTECTED]> wrote: > It's not clear to me from the > +* documentation why the second condition would apply, but sure > +* enough if I remove it the test suite falls over. You will most likely not know _which_ test falls over in a few years. I would suggest adding the name or some other reference for future reference. Won't hurt and might the life of you or someone else a tiny bit easier, at some point :) Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486785: tab completion broken
On Mon, 30 Jun 2008 21:35:22 +0100
Peter Stephenson <[EMAIL PROTECTED]> wrote:
> 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.
Comparing with 4.3.4 confirms this problem.
> 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.
It comes from the combination of
compstate[pattern_match]='*'
in _approximate and something I haven't bothered to track down setting
compstate[insert]=menu
somewhere else. The need for the combination, which I don't really
understand, also underlies what's going on in the code.
See the comment in the fix. I think I've said quite enough there.
Please do report any remaining problems, since I've at least half
convinced myself I've fixed it, however unlikely that seems.
Index: Src/Zle/compcore.c
===
RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v
retrieving revision 1.94
diff -u -r1.94 compcore.c
--- Src/Zle/compcore.c 6 May 2008 16:01:19 - 1.94
+++ Src/Zle/compcore.c 6 Jul 2008 19:38:17 -
@@ -2277,6 +2277,45 @@
haspattern = 1;
}
}
+ } else {
+ /*
+* (This is called a "comment". Given you've been
+* spending your time reading the completion time, you
+* may have forgotten what one is. It's used to deconfuse
+* the poor so-and-so who's landed up having to maintain
+* the code.)
+*
+* So what's going on here then? I'm glad you asked. To test
+* whether we should start menu completion, we test whether
+* compstate[insert] has been set to "menu", but only if we found
+* patterns in the code. It's not clear to me from the
+* documentation why the second condition would apply, but sure
+* enough if I remove it the test suite falls over. (Testing
+* comppatmatch at the later point doesn't work because compstate
+* is likely to have been reset by the point we actually insert
+* the completions, after all functions have exited; this is at
+* least part of the problem.) In the present case, we are not
+* doing matching on the code because all the clever stuff has
+* been done over our heads and we've simply between told to
+* insert it. However, we still need to take account of ambiguous
+* completions properly. To do this, we rely on the caller to
+* pass down the same prefix/suffix with the patterns that we
+* would get if we were doing matching, and test those for
+* patterns. This gets us out of the hole apparently without
+* breaking anything. The particular case where this is needed is
+* approximate file completion: this does its own matching but
+* _approximate still sets the prefix to include the pattern.
+*/
+ if (comppatmatch && *comppatmatch) {
+ int pflen = strlen(compprefix);
+ char *tmp = zhalloc(pflen + strlen(compsuffix) + 1);
+ strcpy(tmp, compprefix);
+ strcpy(tmp + pflen, compsuffix);
+ tokenize(tmp);
+ remnulargs(tmp);
+ if (haswilds(tmp))
+ haspattern = 1;
+ }
}
if (*argv) {
if (dat->pre)
--
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]
Bug#486785: tab completion broken
On Tue, Jul 01, 2008 at 06:26:25PM +0200, martin f krafft wrote: > Unfortunately, I cannot find the repository from which zsh-beta is > built, so I can't bisect it... You can bisect git://git.debian.org/git/private/schizo/tailor/zsh-cvs/.git -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486785: tab completion broken
also sprach Peter Stephenson <[EMAIL PROTECTED]> [2008.06.30.2235 +0200]:
> 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.
Even though the patch does not apply to Debian's package, it's
trivial to make it work. Patch for Clint attached.
I can confirm that your patch fixes the issue, as you describe.
Thanks, Peter!
I do wonder though why this bug has only recently surfaced. Assuming
that the cause is in _path_files, any revision since 1.28 could be
at fault, because it only recently trickled into zsh-beta.
And for the record, if I symlink
http://git.debian.org/?p=private/schizo/zsh.git;a=blob;f=Completion/Unix/Type/_path_files;h=HEADhttp://git.debian.org/?p=private/schizo/zsh.git;a=blob;f=Completion/Unix/Type/_path_files;hb=HEAD
to a directory in my $fpath, the problem disappears.
So it was certainly introduced in the set of commits between what corresponds to
Debian's zsh 4.3.6-4 package, and Debian's zsh-beta
4.3.6-dev-0+20080605-1, although I am sure that the problem didn't
appear with that package.
I pulled
http://snapshot.debian.net/archive/2008/04/29/debian/pool/main/z/zsh-beta/zsh-beta_4.3.6-dev-0+20080428-1_{amd64,i386}.deb
and verified that the bug does *not* appear in this version.
Unfortunately, I cannot find the repository from which zsh-beta is
built, so I can't bisect it...
--
.''`. martin f. krafft <[EMAIL PROTECTED]>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#486785: tab completion broken
On Sun, 22 Jun 2008 23:23:42 +0100
Peter Stephenson <[EMAIL PROTECTED]> wrote:
> On Thu, 19 Jun 2008 21:15:39 +
> Clint Adams <[EMAIL PROTECTED]> wrote:
> > Using only the following zshrc, ls /tmp/.X2 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 " 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_files21 Jun 2008 21:36:01 - 1.31
+++ Completion/Unix/Type/_path_files30 Jun 2008 19:55:41 -
@@ -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" \
Bug#486785: tab completion broken
On Sun, Jun 22, 2008 at 11:23:42PM +0100, Peter Stephenson wrote: > 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). The initial > "." is a red herring. However, I don't know where it's going wrong > since when I do approximation after normal completion (but lots of other > options set, too) it works fine. This triggers a different part of > _path_files which has compadd -U but slight differences in the other > arguments. Internally the Cline struct that's used for generating the > command line looks a bit spartan in the failed case. Needless to say I > haven't the faintest clue where this is leading. Further clues: 1) these behave the same way zstyle ':completion:*' completer _complete _ignored _match _approximate zstyle ':completion:*' completer _complete _correct _approximate zstyle ':completion:*' completer _complete _approximate 2) this one behaves the same way on the second tab zstyle ':completion:*' completer _list _expand _complete _ignored _match _correct _approximate _prefix I have not performed an exhaustive search by any means, but I have not yet run across a combination where the inclusion of _approximate doesn't trigger the surprise elision. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486785: tab completion broken
On Thu, 19 Jun 2008 21:15:39 + Clint Adams <[EMAIL PROTECTED]> wrote: > Using only the following zshrc, ls /tmp/.X2 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). The initial "." is a red herring. However, I don't know where it's going wrong since when I do approximation after normal completion (but lots of other options set, too) it works fine. This triggers a different part of _path_files which has compadd -U but slight differences in the other arguments. Internally the Cline struct that's used for generating the command line looks a bit spartan in the failed case. Needless to say I haven't the faintest clue where this is leading. pws -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486785: tab completion broken
also sprach Clint Adams <[EMAIL PROTECTED]> [2008.06.19.2315 +0200]: > Using only the following zshrc, ls /tmp/.X2 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<-- confirmed. -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems micro$oft windows psychic edition: we will tell you where you are going tomorrow. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#486785: tab completion broken
Using only the following zshrc, ls /tmp/.X2 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<-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486785: tab completion broken
On Thu, Jun 19, 2008 at 08:05:05PM +0200, Yves-Alexis Perez wrote: > Try with ZDOTDIR=$PWD/zsh/.zsh ? Ah, now there we go. ls /tmp/.X2 removes the whole argument, and ls .X2 (cd'd to /tmp) just removes the 2. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486785: tab completion broken
On Thu, Jun 19, 2008 at 03:37:16PM +0200, martin f krafft wrote: > So this works fine here too. > > My point is that my config used to work around 24 May and between > then and now, the *same* config exhibits new behaviour, suggesting > that zsh-beta changed something... which is not really nice. I believe you; I just can't reproduce it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486785: tab completion broken
On jeu, 2008-06-19 at 11:50 +, Clint Adams wrote: > On Wed, Jun 18, 2008 at 07:47:04AM +0200, martin f krafft wrote: > > git clone git://git.madduck.net/etc/zsh.git > > ZDOTDIR=`pwd`/zsh zsh > > % ZDOTDIR=$PWD/zsh zsh-beta > da% ls /tmp/.X2 > ls: cannot access /tmp/.X2: No such file or directory Try with ZDOTDIR=$PWD/zsh/.zsh ? Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#486785: tab completion broken
also sprach Clint Adams <[EMAIL PROTECTED]> [2008.06.19.1422 +0200]: > % zsh-beta -f > hostname% autoload -U compinit > hostname% compinit > hostname% ls /tmp/.X2 So this works fine here too. My point is that my config used to work around 24 May and between then and now, the *same* config exhibits new behaviour, suggesting that zsh-beta changed something... which is not really nice. -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems "we all know linux is great... it does infinite loops in 5 seconds." -- linus torvalds digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#486785: tab completion broken
On Thu, Jun 19, 2008 at 02:07:27PM +0200, martin f krafft wrote: > Definitely not here, on two separate systems. > > Do you have a configuration available that I can test, like you > could test mine? Sure. % zsh-beta -f hostname% autoload -U compinit hostname% compinit hostname% ls /tmp/.X2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486785: tab completion broken
also sprach Clint Adams <[EMAIL PROTECTED]> [2008.06.19.1350 +0200]: > % ZDOTDIR=$PWD/zsh zsh-beta > da% ls /tmp/.X2 > ls: cannot access /tmp/.X2: No such file or directory Definitely not here, on two separate systems. Do you have a configuration available that I can test, like you could test mine? -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems quick!! act as if nothing has happened! digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#486785: tab completion broken
On Wed, Jun 18, 2008 at 07:47:04AM +0200, martin f krafft wrote: > git clone git://git.madduck.net/etc/zsh.git > ZDOTDIR=`pwd`/zsh zsh % ZDOTDIR=$PWD/zsh zsh-beta da% ls /tmp/.X2 ls: cannot access /tmp/.X2: No such file or directory -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486785: tab completion broken
Package: zsh-beta Version: 4.3.6-dev-0+20080605-1 Severity: important Either 4.3.6-dev-0+20080520-1, 4.3.6-dev-0+20080605-1, or 4.3.6-dev-0+20080531-1 seem to have broken tab completion, I have not had the chance to figure out which. The symptoms are that tab completion on nonexistent prefixes cause the entire path to be removed. For example, given /tmp/.X11-unix: ls /tmp/.X2_ yields ls _ (where _ denotes the cursor). This certainly did not happen three weeks ago, when I last used zsh intensively. I checked my configuration logs but have not made any changes to the config. You can obtain and test my configuration like so: git clone git://git.madduck.net/etc/zsh.git ZDOTDIR=`pwd`/zsh zsh -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
