From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28347 invoked from network); 18 Aug 2009 09:11:19 -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; 18 Aug 2009 09:11:19 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 66632 invoked from network); 18 Aug 2009 09:11:10 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 18 Aug 2009 09:11:10 -0000 Received: (qmail 22057 invoked by alias); 18 Aug 2009 09:11:01 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 27221 Received: (qmail 22018 invoked from network); 18 Aug 2009 09:11:00 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 18 Aug 2009 09:11:00 -0000 Received: from cluster-d.mailcontrol.com (cluster-d.mailcontrol.com [85.115.60.190]) by bifrost.dotsrc.org (Postfix) with ESMTPS id 04F358058B57 for ; Tue, 18 Aug 2009 11:10:54 +0200 (CEST) Received: from cameurexb01.EUROPE.ROOT.PRI ([193.128.72.68]) by rly40d.srv.mailcontrol.com (MailControl) with ESMTP id n7I9ApGf001022 for ; Tue, 18 Aug 2009 10:10:52 +0100 Received: from news01.csr.com ([10.99.50.25]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 10:10: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 n7I9AkAo018408 for ; Tue, 18 Aug 2009 10:10:46 +0100 Received: from csr.com (pws@localhost) by news01.csr.com (8.14.2/8.14.2/Submit) with ESMTP id n7I9Akh9018405 for ; Tue, 18 Aug 2009 10:10:46 +0100 Message-Id: <200908180910.n7I9Akh9018405@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: zsh-workers Subject: Re: Quoting problems with _zip (unzip) completer In-reply-to: References: <237967ef0908031315u72fa3661i17ff7f0107b85b9c@mail.gmail.com> <200908040850.n748oxlc011862@news01.csr.com> <20090817215819.796e9416@pws-pc> <20090817224954.0b55b854@pws-pc> Comments: In-reply-to Nikolai Weibull message dated "Mon, 17 Aug 2009 23:59:44 +0200." Date: Tue, 18 Aug 2009 10:10:46 +0100 From: Peter Stephenson X-OriginalArrivalTime: 18 Aug 2009 09:10:51.0412 (UTC) FILETIME=[C86D3D40:01CA1FE3] Content-Type: text/plain MIME-Version: 1.0 X-Scanned-By: MailControl A-09-22-00 (www.mailcontrol.com) on 10.68.0.150 X-Virus-Scanned: ClamAV 0.94.2/9707/Tue Aug 18 02:15:41 2009 on bifrost X-Virus-Status: Clean Nikolai Weibull wrote: > I don't want to sound pessimistic, but aren't we approaching a point > where the quoting and pattern matching code simply has to be > re(written|factored)? To some extent, yes, and I looked at the completion quoting code: it's absolutely ghastly and I got pretty much nowhere. (This was the case of nested quoting, however, so it's harder than the sort of thing we've been talking about.) Sven hasn't been available for some years and anyway the object would be to tease something more manageable out, which is a rather different prospect from fixing up the existing code. The pattern matching code in use here is the main shell's; this is actually relatively under control and doesn't merit a rewrite. The big problem we have in cases like yesterday's is the standard one with regular expressions that it's not trivial to quote them from expansion. We could fix that with a flag. There is the case of the completion matching code, which is separate but calls the normal pattern matching code. I have started to improve this to support multibyte characters but got bogged down; the core now works but there's much more work to be done in the logic that uses it, which is heavily tied to one byte per character. It's not entirely clear you're ever going to end up with something completely clean anyway, and a lot of the problem isn't the internals---broadly these do the right thing in most cases or can be persuaded to do so with local changes like yesterday's. There's no guarantee that a rewrite is going to pick remaining issues up. There is the further problem of the conventions of passing between different parts of the system, which need to know what's quoted, what's a pattern, what can be expanded, etc. This is probably what I ran into yesterday---some part of the code has a convention where a file name is quoted where you would expect it not to. Fixing all that would really mean a complete rewrite of the entire system, adding much more internal state. I don't think there's any prospect of that. Then of course there's the problem that at the current rate any changes other than simple, local ones are going to take longer than the age of the universe. -- Peter Stephenson Software Engineer Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK 'member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom'