From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28983 invoked from network); 13 Oct 2008 15:44:32 -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.2 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 15:44:32 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 98731 invoked from network); 13 Oct 2008 15:44:22 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 13 Oct 2008 15:44:22 -0000 Received: (qmail 19291 invoked by alias); 13 Oct 2008 15:44:11 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25877 Received: (qmail 19265 invoked from network); 13 Oct 2008 15:44:07 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 13 Oct 2008 15:44:07 -0000 Received: from vms172069pub.verizon.net (vms172069pub.verizon.net [206.46.172.69]) by bifrost.dotsrc.org (Postfix) with ESMTP id 40D8180524C2 for ; Mon, 13 Oct 2008 17:43:47 +0200 (CEST) Received: from torch.brasslantern.com ([96.238.220.215]) by vms172069.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0K8O00FVFP0IQDV2@vms172069.mailsrvcs.net> for zsh-workers@sunsite.dk; Mon, 13 Oct 2008 10:43:31 -0500 (CDT) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id m9DFhT5R028632 for ; Mon, 13 Oct 2008 08:43:30 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id m9DFhSNK028631 for zsh-workers@sunsite.dk; Mon, 13 Oct 2008 08:43:28 -0700 Date: Mon, 13 Oct 2008 08:43:28 -0700 From: Bart Schaefer Subject: Re: Regression in braces completion In-reply-to: <20081013100417.36870ba5@news01> To: "Zsh Hackers' List" Message-id: <081013084328.ZM28630@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii 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> Comments: In reply to Peter Stephenson "Re: Regression in braces completion" (Oct 13, 10:04am) X-Virus-Scanned: ClamAV 0.92.1/8417/Mon Oct 13 09:34:29 2008 on bifrost X-Virus-Status: Clean On Oct 13, 10:04am, Peter Stephenson wrote: } Subject: Re: Regression in braces completion } } 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 The direct effect of -U (if the doc is remotely descriptive of the code) is to cause matching of the returned words against the command line to be skipped, so perhaps the code that handles braces is embedded in the compresult code that performs matching. The usual indirect effect of -U is that the the word on the command line is thrown away and replaced entirely with the result from compadd, which does look like what's happening here. Maybe all that's been lost is the position at which to re-insert the brace, but I'm betting that this comment above cline_str() is significant: /* This builds the unambiguous string. If ins is one, it is immediately * inserted into the line. Otherwise csp is used to return the relative * cursor position in the string returned and posl contains all * positions with missing or ambiguous characters. If ins is two, csp * and posl contain real command line positions (including braces). */ Comparing walkthroughs of cline_str() when ins==1 for the correct case (-U removed from compadd) and the incorrect case, the difference is at line 240, where in the correct case li==3 and in the incorrect li==0. The value for li comes from l->prefix->llen, which must be the result of the call to cut_cline() on line 175. I've run out of time to spend on this, but I suspect that the effect of the -U option is to cause cut_cline() to decide that nothing that was already on the line is worth keeping, when really in this case we want to keep the first three characters up to the brace. 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" ? } so there's no way you can treat this as a special case anywhere else 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. In fact _path_files probably ought to bail out in the case where it has corrected the path prefix and make the user confirm that the correction is, well, correct, before it goes on to guessing about stuff further along in the path. The trouble most likely is that we're trying to do too many things in one go. Of course if we change that, someone will complain that what used to need only one tab now needs two, but this may be a case of lesser of evils. Or there may be an entirely other way of solving this, such as adding the entire paths including the correction as separate matches so that the point of ambiguity is much farther to the left. In any case if you agree that the C code behavior for -U is correct, then the right fix is something that eliminates the -U from _path_files by using another approach for the original auto-correction problem.