From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26863 invoked from network); 3 May 2009 18:03:42 -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.6 required=5.0 tests=AWL,BAYES_00 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; 3 May 2009 18:03:42 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 66250 invoked from network); 3 May 2009 18:03:35 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 3 May 2009 18:03:35 -0000 Received: (qmail 5748 invoked by alias); 3 May 2009 18:03:31 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26920 Received: (qmail 5737 invoked from network); 3 May 2009 18:03:31 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 3 May 2009 18:03:31 -0000 Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by bifrost.dotsrc.org (Postfix) with ESMTP id BFFE880590A3 for ; Sun, 3 May 2009 20:01:30 +0200 (CEST) Received: from torch.brasslantern.com ([96.249.201.13]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KJ2009SGY5D98ME@vms173019.mailsrvcs.net> for zsh-workers@sunsite.dk; Sun, 03 May 2009 13:03:14 -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 n43I3Cl2021930 for ; Sun, 03 May 2009 11:03:13 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n43I3CVY021929 for zsh-workers@sunsite.dk; Sun, 03 May 2009 11:03:12 -0700 From: Bart Schaefer Message-id: <090503110312.ZM21928@torch.brasslantern.com> Date: Sun, 03 May 2009 11:03:12 -0700 In-reply-to: Comments: In reply to Greg Klanderman "Re: another file completion problem in 4.3.9-dev-2" (May 3, 12:56pm) References: <18939.51080.161444.80368@gargle.gargle.HOWL> <090502075455.ZM29259@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@sunsite.dk Subject: Re: another file completion problem in 4.3.9-dev-2 MIME-version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.92.1/9320/Sun May 3 08:19:28 2009 on bifrost X-Virus-Status: Clean On May 3, 12:56pm, Greg Klanderman wrote: } } >>>>> Bart Schaefer writes: } } > "baz" is a mismatch in at least two dimensions, both position in the } > word (not a prefix) and case. I suspect the matcher list can adjust } > for only one dimension at a time. } } I don't think that's true, it usually works for me, for example: } } lwm% touch FooBar FooBaz } lwm% ls baz # ===> FooBaz Right, and look at this: torch% ls BarBaz FooBaz torch% ls baz torch% ls FooBaz The only match found is FooBaz. The condition seems to be that "baz" matches nothing, and "Ba" matches a prefix of BarBaz, so there's no futher attempt to find another spot where "Ba" might match -- the mismatch of "z" vs. "r" discards BarBaz as a possible completion unless correction is also allowed. Completion isn't coded like a regular expression engine that will backtrack and retry until it finds all possible substring hits -- in fact, when presented with the choice the decision frequently was to make completion fail quickly even if that meant missing something. Otherwise it's too easy to get into situations where you hit TAB and the shell just goes away for minutes at a time. Some people would say that's already too easily perpetrated. } Any thoughts on the other one I sent a couple weeks back, which seemed } to have something to do with quoting of space? I can't reproduce it using the steps that you outlined. For example, at the point where you say -- > OK, now lists: I can't list with ^D, instead it deletes the backslash character that is under the cursor. If I invoke list-choices explicitly, the cursor moves to the end of the line when the list is displayed, then moves to the backslash again when I hit TAB; no "o" is inserted. Is it possible you have some settings creeping in from /etc/z* even when starting with zsh -f ? Or perhaps the contents of the several directories makes a difference -- can you reproduce with empty dirs?