Re: Bug#486785: tab completion broken

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Mon, 30 Jun 2008 21:35:22 +0100
Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx> 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 -0000	1.94
+++ Src/Zle/compcore.c	6 Jul 2008 19:38:17 -0000
@@ -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 <p.w.stephenson@xxxxxxxxxxxx>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/