From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23097 invoked from network); 6 Jul 2008 19:51:38 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 6 Jul 2008 19:51:38 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 87951 invoked from network); 6 Jul 2008 19:51:31 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 6 Jul 2008 19:51:31 -0000 Received: (qmail 19820 invoked by alias); 6 Jul 2008 19:51:27 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25267 Received: (qmail 19804 invoked from network); 6 Jul 2008 19:51:26 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 6 Jul 2008 19:51:26 -0000 Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by bifrost.dotsrc.org (Postfix) with ESMTP id D5A7280561C1 for ; Sun, 6 Jul 2008 21:51:13 +0200 (CEST) Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20080706195555.MHFH28496.mtaout01-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Sun, 6 Jul 2008 20:55:55 +0100 Received: from pws-pc ([81.107.40.67]) by aamtaout03-winn.ispmail.ntl.com with ESMTP id <20080706200132.FDQB8797.aamtaout03-winn.ispmail.ntl.com@pws-pc>; Sun, 6 Jul 2008 21:01:32 +0100 Date: Sun, 6 Jul 2008 20:51:09 +0100 From: Peter Stephenson To: zsh-workers@sunsite.dk Cc: 486785@bugs.debian.org Subject: Re: Bug#486785: tab completion broken Message-ID: <20080706205109.7e91a057@pws-pc> In-Reply-To: <20080630213522.5fe843de@pws-pc> References: <20080619211539.GA5218@scru.org> <20080622232342.756e9d4b@pws-pc> <20080630213522.5fe843de@pws-pc> X-Mailer: Claws Mail 3.4.0 (GTK+ 2.12.10; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92.1/7646/Sun Jul 6 18:08:08 2008 on bifrost X-Virus-Status: Clean On Mon, 30 Jun 2008 21:35:22 +0100 Peter Stephenson 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 Web page now at http://homepage.ntlworld.com/p.w.stephenson/