From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28194 invoked from network); 7 Jul 2009 15:16:28 -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.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from new-brage.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.254.104) by ns1.primenet.com.au with SMTP; 7 Jul 2009 15:16:28 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 94572 invoked from network); 7 Jul 2009 15:16:23 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 7 Jul 2009 15:16:23 -0000 Received: (qmail 15010 invoked by alias); 7 Jul 2009 15:16:16 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 27094 Received: (qmail 14997 invoked from network); 7 Jul 2009 15:16:16 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 7 Jul 2009 15:16:16 -0000 Received: from cluster-d.mailcontrol.com (cluster-d.mailcontrol.com [85.115.60.190]) by bifrost.dotsrc.org (Postfix) with ESMTPS id C36B480307FA for ; Tue, 7 Jul 2009 17:16:13 +0200 (CEST) Received: from cameurexb01.EUROPE.ROOT.PRI ([193.128.72.68]) by rly14d.srv.mailcontrol.com (MailControl) with ESMTP id n67FFsEK018382 for ; Tue, 7 Jul 2009 16:16:12 +0100 Received: from news01.csr.com ([10.99.50.25]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 16:11:49 +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 n67FBmps021666 for ; Tue, 7 Jul 2009 16:11:49 +0100 Received: from csr.com (pws@localhost) by news01.csr.com (8.14.2/8.14.2/Submit) with ESMTP id n67FBl9J021661 for ; Tue, 7 Jul 2009 16:11:48 +0100 Message-Id: <200907071511.n67FBl9J021661@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: zsh-workers@sunsite.dk Subject: Re: need help debugging cvs completion problem In-reply-to: References: <19013.18790.978774.551126@gargle.gargle.HOWL> <20090627212418.36848701@pws-pc> <20090628113802.GA3707@primenet.com.au> <20090628205428.77cd5198@pws-pc> Comments: In-reply-to Greg Klanderman message dated "Tue, 07 Jul 2009 10:15:07 -0400." Date: Tue, 07 Jul 2009 16:11:47 +0100 From: Peter Stephenson X-OriginalArrivalTime: 07 Jul 2009 15:11:49.0401 (UTC) FILETIME=[403E9890:01C9FF15] X-Scanned-By: MailControl A-09-20-00 (www.mailcontrol.com) on 10.68.0.124 X-Virus-Scanned: ClamAV 0.94.2/9540/Tue Jul 7 12:52:52 2009 on bifrost X-Virus-Status: Clean Greg Klanderman wrote: > Unfortunately, it seems that when the new completion system was > designed, it did not abstract stuff like handling parameter > references, quoting, etc like the compctl stuff did. So if you're > doing file completion, _path_files has all that logic (at the expense > of being completely incomprehensible) and it mostly works, but other > sorts of completion either have to reimplement that logic (sometimes > partially and/or buggily), or just not handle these complications. Right, it's the same problem with generating the files for git completion---if you're not using _path_files, you're starting from scratch, and you don't have the useful stuff for handling directories, hence you're doing too much work. It would be really nice to have this all generic---pass in a directory to a context-defined function, pass back a list of files, however generated---even if it was in the first instance separate from _path_files. The combination of _path_files, compfiles, and the basic completion system is as obfuscated as anything I know. compctl was no better---but as the whole thing was hidden from you from start to end it didn't matter. -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070