From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 685 invoked from network); 13 Oct 2008 16:28:46 -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 16:28:46 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 11673 invoked from network); 13 Oct 2008 16:28:19 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 13 Oct 2008 16:28:19 -0000 Received: (qmail 2092 invoked by alias); 13 Oct 2008 16:28:01 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25879 Received: (qmail 2067 invoked from network); 13 Oct 2008 16:27:58 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 13 Oct 2008 16:27:58 -0000 Received: from cluster-d.mailcontrol.com (cluster-d.mailcontrol.com [217.69.20.190]) by bifrost.dotsrc.org (Postfix) with ESMTPS id D832080524C0 for ; Mon, 13 Oct 2008 18:27:52 +0200 (CEST) Received: from cameurexb01.EUROPE.ROOT.PRI ([193.128.72.68]) by rly39d.srv.mailcontrol.com (MailControl) with ESMTP id m9DGRpfb020765 for ; Mon, 13 Oct 2008 17:27:51 +0100 Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Oct 2008 17:27:51 +0100 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.14.2/8.13.4) with ESMTP id m9DGRoJJ017503 for ; Mon, 13 Oct 2008 17:27:51 +0100 Received: from csr.com (pws@localhost) by news01.csr.com (8.14.2/8.14.2/Submit) with ESMTP id m9DGRoED017498 for ; Mon, 13 Oct 2008 17:27:50 +0100 Message-Id: <200810131627.m9DGRoED017498@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: "Zsh Hackers' List" Subject: Re: Regression in braces completion In-reply-to: <081013084328.ZM28630@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> <20081013100417.36870ba5@news01> <081013084328.ZM28630@torch.brasslantern.com> Comments: In-reply-to Bart Schaefer message dated "Mon, 13 Oct 2008 08:43:28 -0700." Date: Mon, 13 Oct 2008 17:27:50 +0100 From: Peter Stephenson X-OriginalArrivalTime: 13 Oct 2008 16:27:51.0051 (UTC) FILETIME=[A2E7E5B0:01C92D50] X-Scanned-By: MailControl A-08-50-15 (www.mailcontrol.com) on 10.68.0.149 X-Virus-Scanned: ClamAV 0.92.1/8417/Mon Oct 13 09:34:29 2008 on bifrost X-Virus-Status: Clean Bart Schaefer wrote: > However, I'm not sure the C code is actually wrong here. Postulate a > completer that given "abcd" as the thing to match, returns "zyxw" and > uses compadd -U to say "accept this as a completion even though it does > not look like what you started with." Now call that completer for a > line with "abc{d". Is the right answer really "zyx{w" ? Yes, if the C code has (as it does) stripped all the stuff to do with the parts of the brace expansion it doesn't think you want to see away before you ever got to look at the word to be completed. Otherwise you get a meaningless hybrid---you're adding back braces you've never had any information about in the first place. (I can see how you could argue it differently: you can infer the braces by looking at the raw command line and tell the completion system that you've decided you don't like what's done and decide to do it yourself. However, that's overloading -U with multiple meanings: not just "use my completion as it is in your results table" but "forget everything you've done so far and insert this the way I want". I'm not convinced it even works---the system is now thoroughly confused about what it's actually completing, so working out what it's replacing with your string isn't easy. What -U does and doesn't do is already rather obscure, so this is all probably moot.) I think to do it consistently with the other interpretation, you would need completion internally to ignore the presence of braces right from the start and allow the function system to decide whether to handle them. That's not going to happen any time soon---though it's actually possible it's a more elegant solution. > I wasn't suggesting treating this as a special case, I was suggesting > that _path_files treat a spelling correction in the path prefix as a > special case. That's the stated reason why _path_files is using -U. As you previously noted, there are already far too many ways of running compadd within _path_files as it is. I'm not at all happy about doubling the number to get sets with and without -U --- which would leave spelling correction broken in the case where braces are present (perhaps depending which way the pinball decides to roll down _path_files in that case, but I presume it would still miss the flippers in the same way). -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070