From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96 invoked from network); 23 Feb 2009 02:33: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.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 Received: from ns2.primenet.com.au (HELO primenet.com.au) (203.24.36.3) by ns1.primenet.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Feb 2009 02:33:19 -0000 Received: (qmail 11159 invoked from network); 23 Feb 2009 02:33:17 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by proxy.melb.primenet.com.au with SMTP; 23 Feb 2009 02:33:17 -0000 Received-SPF: none (proxy.melb.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 44428 invoked from network); 23 Feb 2009 02:25:40 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 23 Feb 2009 02:25:40 -0000 Received: (qmail 12319 invoked by alias); 23 Feb 2009 02:25:34 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26595 Received: (qmail 12302 invoked from network); 23 Feb 2009 02:25:33 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 23 Feb 2009 02:25:33 -0000 Received: from vms173007pub.verizon.net (vms173007pub.verizon.net [206.46.173.7]) by bifrost.dotsrc.org (Postfix) with ESMTP id 1B27B80293E7 for ; Mon, 23 Feb 2009 03:25:28 +0100 (CET) Received: from torch.brasslantern.com ([173.67.122.60]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KFH00F2KYQ8CCG9@vms173007.mailsrvcs.net> for zsh-workers@sunsite.dk; Sun, 22 Feb 2009 20:25:25 -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 n1N2PJ6G005454 for ; Sun, 22 Feb 2009 18:25:20 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n1N2PJPM005453 for zsh-workers@sunsite.dk; Sun, 22 Feb 2009 18:25:19 -0800 From: Bart Schaefer Message-id: <090222182519.ZM5452@torch.brasslantern.com> Date: Sun, 22 Feb 2009 18:25:19 -0800 In-reply-to: Comments: In reply to ( Text in unknown character set UTF-8 not shown ) Sommer "Re: globcomplete desctroys file completion" (Feb 22, 8:36pm) References: <090221111624.ZM12907@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@sunsite.dk Subject: Re: globcomplete desctroys file completion MIME-version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.92.1/9025/Sun Feb 22 22:35:18 2009 on bifrost X-Virus-Status: Clean On Feb 22, 8:36pm, ( Text in unknown character set UTF-8 not shown ) wrote: } Subject: Re: globcomplete desctroys file completion } } Bart Schaefer wrote: } > For example, T*/t*/t* should among other files match Tmp/texlive/tlpkg } > and Tmp/texlive2008/tlpkg, but when you complete without globcomplete } > you're offered Tmp/texlive/te as a unique prefix. How can that be } > correct? } } Because the cursor is placed after texlive and I can select between } texlive and texlive2008 before continuing. That makes the cursor placement correct but the trailing "e" still not. However, I think that's unrelated, so let's ignore it. } I've put these two logs at } http://alioth.debian.org/~jo-guest/zsh-with-globcomplete } http://alioth.debian.org/~jo-guest/zsh-without-globcomplete The line numbers of the functions differ a bit from what I've got out of the latest CVS, but the problem appears to be the same as what I outlined in my last two messages. If I simply comment out the extra -s option in the tmp4 assignment, then I get the correct completion but the wrong cursor placement: torch% print T/t/t torch% print Tmp/texlive/t Cursor is at the end, rather than on the last slash, so if I proceed into menu completion with another TAB I'm not offered texlive2008 as a possibility. Of course that happens withOUT globcomplete as well, but at least in that case the cursor is at the potential point of ambiguity. So there's something wrong with that "tmpdisp" branch of _path_files, but I'm not yet seeing what.