From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17481 invoked from network); 13 Oct 2008 09:05:07 -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=-1.1 required=5.0 tests=AWL 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; 13 Oct 2008 09:05:07 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 85062 invoked from network); 13 Oct 2008 09:04:52 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 13 Oct 2008 09:04:52 -0000 Received: (qmail 25166 invoked by alias); 13 Oct 2008 09:04:38 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25873 Received: (qmail 25135 invoked from network); 13 Oct 2008 09:04:34 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 13 Oct 2008 09:04:34 -0000 Received: from cluster-g.mailcontrol.com (cluster-g.mailcontrol.com [208.87.233.190]) by bifrost.dotsrc.org (Postfix) with ESMTPS id EA3F780524C0 for ; Mon, 13 Oct 2008 11:04:28 +0200 (CEST) Received: from cameurexb01.EUROPE.ROOT.PRI ([193.128.72.68]) by rly13g.srv.mailcontrol.com (MailControl) with ESMTP id m9D92tnd017204 for ; Mon, 13 Oct 2008 10:04:19 +0100 Received: from news01 ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Oct 2008 10:04:17 +0100 Date: Mon, 13 Oct 2008 10:04:17 +0100 From: Peter Stephenson To: "Zsh Hackers' List" Subject: Re: Regression in braces completion Message-ID: <20081013100417.36870ba5@news01> In-Reply-To: <081012154721.ZM22722@torch.brasslantern.com> References: <20a807210810111932r1b32b746l3cca788a383e84ed@mail.gmail.com> <081011213249.ZM29979@torch.brasslantern.com> <081012001051.ZM30706@torch.brasslantern.com> <20081012204236.6669a668@pws-pc> <081012154721.ZM22722@torch.brasslantern.com> Organization: CSR X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.8; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Oct 2008 09:04:17.0527 (UTC) FILETIME=[AC026870:01C92D12] X-Scanned-By: MailControl A-08-50-15 (www.mailcontrol.com) on 10.71.0.123 X-Virus-Scanned: ClamAV 0.92.1/8417/Mon Oct 13 09:34:29 2008 on bifrost X-Virus-Status: Clean On Sun, 12 Oct 2008 15:47:19 -0700 Bart Schaefer wrote: > In order to find the possible completions of the rightmost expansion > of the brace expression, the C code removes everything between the > brace and the comma, inclusive, and then asks the completer (which > happens to be _path_files) for the matches. It's not expecting the > completer to modify the command line as a side-effect, but that's > what happens when "compadd -U" is called. No, that's not how "compadd -U" works. It simply changes the rules of how completions added by the command are treated. The actual modification of the command line happens later in any case. It's very roughly like this: - completion system kicks off a set of functions - somewhere inside those compadd is called - within the C code some internal variables are updated to add lists of things grouped together in horribly obscure ways, storing the fact that "-U" was present - eventually the completion function exits - the code in compresult.c uses the previous results to decide how to manipulate the command line. As the compresult code is called a lot later than the "compadd" and there's no clear grouping of variables used by it, it's extremely difficult to pin changes in the result onto changes in the command that added the completion, particularly since the whole thing is sensitive (via what's visible as compstate etc.) to context (although different context shouldn't be an issue here). One of the things that's taken account of at various places along the line, including in the compresult code that adds ambiguous or unambiguous completions, is whether -U was present (except that it's called something entirely different internally that I've forgotten). It's certainly possible that the code that takes account of braces in the case of compadd -U isn't present because it's never been tested before, but that would be bug: the C code takes pains to hide the existence of the braces from the rest of the system, so there's no way you can treat this as a special case anywhere else, and if you did it would arbitrarily limit the completions you could do on expressions with braces. pws