From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9367 invoked from network); 19 Feb 2008 22:30:15 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.4 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 19 Feb 2008 22:30:15 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 27714 invoked from network); 19 Feb 2008 22:22:41 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 19 Feb 2008 22:22:41 -0000 Received: (qmail 17240 invoked by alias); 19 Feb 2008 22:22:37 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 24573 Received: (qmail 17226 invoked from network); 19 Feb 2008 22:22:37 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 19 Feb 2008 22:22:37 -0000 Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by bifrost.dotsrc.org (Postfix) with ESMTP id 851318026E0B for ; Tue, 19 Feb 2008 23:22:33 +0100 (CET) Received: from torch.brasslantern.com ([71.121.18.67]) by vms173003.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JWI00M4ZBCSVPW1@vms173003.mailsrvcs.net> for zsh-workers@sunsite.dk; Tue, 19 Feb 2008 16:19:42 -0600 (CST) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id m1JMMTdo020754 for ; Tue, 19 Feb 2008 14:22:29 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id m1JMMS4A020753 for zsh-workers@sunsite.dk; Tue, 19 Feb 2008 14:22:28 -0800 Date: Tue, 19 Feb 2008 14:22:28 -0800 From: Bart Schaefer Subject: Re: _approximate doesn't work In-reply-to: <20080219101904.010f8df8@news01> To: zsh-workers@sunsite.dk Message-id: <080219142228.ZM20752@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <200802171925.m1HJPbE8009696@pws-pc.ntlworld.com> <080218013338.ZM15026@torch.brasslantern.com> <080219002936.ZM16243@torch.brasslantern.com> <20080219101904.010f8df8@news01> Comments: In reply to Peter Stephenson "Re: _approximate doesn't work" (Feb 19, 10:19am) X-Virus-Scanned: ClamAV 0.91.2/5887/Tue Feb 19 20:42:20 2008 on bifrost X-Virus-Status: Clean On Feb 19, 10:19am, Peter Stephenson wrote: } Subject: Re: _approximate doesn't work } } On Tue, 19 Feb 2008 00:29:35 -0800 } Bart Schaefer wrote: } > Looking through the output, PREFIX gets set by the replacement } > compadd created via _approximate -- but that doesn't happen until } > *inside* the call to _wanted, long after the test in _path_commands. } } [...] this is an extremely general problem. Very many completion } functions assume quite reasonably that testing PREFIX tests what the } completer is trying to match. I just looked through "grep PREFIX Completion/**/*(.)" and I don't think there are very many functions that use PREFIX as a pattern in the way that _path_commands does. Most of them test another pattern against $PREFIX, to determine context based on what $PREFIX contains. The real, more general problem IMO is that we've allowed the lines of responsibility to become way too blurry. The original idea (ISTR) was that the completion functions (as opposed to "completers", or what the manual calls "control functions") would generate a large set of possible completions and then compadd would filter them down to the actual matches, because only compadd knows enough about the internal state of the shell to do so. This gets compromised for performance reasons (e.g., if we know an entire directory path, limit file names to those in that directory) but the early functions were careful to do this only with the parts of the command line that were already unambiguous. That is not, in general, true of $PREFIX. The job of a completer is to figure out the context and supply the corresponding tags. The job of a completion function is to enumerate all the possible strings for some subset of tags. The job of compadd is to reduce that set of strings to the actual completions. As soon as either of the functions starts crossing those boundaries, there's a potential problem, and it better be happening for a good reason. } Perhaps we need to make approximation/correction more visible by } introducing parameters that are local to the completion system and } only contain text in the appropriate case (e.g. APPROX="(#a1)")? It may be that approximation is worthy of addition to compset/compadd. The fact that _approximate has to create a dummy compadd function in order to be implemented, argues in that direction. However, I still think _path_commands was wrong to pre-filter on $PREFIX.