From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18995 invoked by alias); 12 Feb 2011 22:22:44 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28751 Received: (qmail 5481 invoked from network); 12 Feb 2011 22:22:40 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <110212142222.ZM2525@torch.brasslantern.com> Date: Sat, 12 Feb 2011 14:22:22 -0800 In-reply-to: <20110211203935.4fa6af6a@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: Another _path_files bug?" (Feb 11, 8:39pm) References: <110210084252.ZM30454@torch.brasslantern.com> <110210092820.ZM30702@torch.brasslantern.com> <20110211203935.4fa6af6a@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Another _path_files bug? MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Feb 11, 8:39pm, Peter Stephenson wrote: } Subject: Re: Another _path_files bug? } } On Thu, 10 Feb 2011 09:28:20 -0800 } Bart Schaefer wrote: } > } } > } torch% setopt completeinword } > } torch% ls Test/ } ^completing here... } > } torch% ls Test//Test/Makefile } > } > compadd -Qf -J -default- -J -default- -p Test/ \ } > -s /Makefile -W Test// -M 'r:|/=* r:|=*' - Test } } This is more an experiment than a suggested fix, but I wonder if the } problem is it's assuming there are three path sections: an initial path, } the middle bit, that the cursor's in the middle of, and then contents of } the directory at the end. In the case here, we've only got two: the } "Test/" is being treated as both the initial part and the middle part. Yes, that does seem to describe the situation. } So if we add a separate case for handling this it improves things. This works for the test cases I could think of applying, such as putting a full path at the front and (separately) where the tail is ambiguous. } Obvious we'll need to find out if the original problem was more general, } in which case splitting off this case may work but isn't the right fix, } or if this has repercussions in other simple cases. I haven't found any that break, but I don't have, e.g., any files with multibyte characters in their names handy to try. } Also, what does the 'if [[ -z "$tmp4" ]]' just above that signify? I } think (from the comment above 729) it might just mean we've finished } collecting things and are about to add them to the completion --- That's must be essentially correct -- when tmp4 is non-empty we go back to the top of "for prepath in ..." at line 350, otherwise we enter this block and (eventually) do one of "for i in "$tmp1[@]" ..." to add each string from tmp1 individually, or "compadd ... -a tmp1" to add them all at once. In other cases, though, we compadd the contents of tmp1 in the body of the "while true;" loop from line 595. See comment at 597. At the point where tmp4 becomes empty, tmp1=( Makefile ) [the sole completion in the Test subdir] so empty tmp4 appears to signify that we have in fact NOT found a real file matching the current component (the current component in this instance is the empty path tail after "Test/").