From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27777 invoked by alias); 21 Jun 2011 05:04:07 -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: 29499 Received: (qmail 1617 invoked from network); 21 Jun 2011 05:03:51 -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: <110620220334.ZM8712@torch.brasslantern.com> Date: Mon, 20 Jun 2011 22:03:34 -0700 In-reply-to: <20110618220723.6559e606@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: _multi_parts and -q" (Jun 18, 10:07pm) References: <20110617215008.GA3154@lorien.comfychair.org> <20110618205218.093eb2f8@pws-pc.ntlworld.com> <110618130334.ZM19744@torch.brasslantern.com> <20110618220723.6559e606@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: _multi_parts and -q MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jun 18, 10:07pm, Peter Stephenson wrote: } } I think the issue is that "xy/foo", "xy/bar" etc. look like a set of } ambiguous completions with "xy/" as prefix --- and in *that* case the } "/" isn't special, it's just part of the input string. (Possibly you } can see some behaviour that disagrees with this hypothesis.) That's part of it, but by examination _multi_parts never passes -q to compadd on its own, and it only passes *through* a -q from its options ($sopts) in three cases: (1) The separator is not in the string from the command line AND there is exactly one possible match; or (2) The separator is not in the string from the command line AND *none* of the possible matches contains the separator; or (3) The matcher list found no matches AND there's no suffix on the command line, i.e. we're completing at the end of a word. In fact in the most obvious case _complete_debug shows the code passing through the compadd on line 120 which passes -r $sep -S $sep but not -q (this is the first clause of case 2 but not the second). This happens even when there is an exact match that does not contain the separator. This change makes it take the compadd at line 123 (124 after the patch) instead, and then Danek's example works: Index: Completion/Base/Utility/_multi_parts =================================================================== --- Completion/Base/Utility/_multi_parts 21 Dec 2010 16:41:14 -0000 +++ Completion/Base/Utility/_multi_parts 21 Jun 2011 05:00:16 -0000 @@ -116,7 +116,8 @@ compadd "$group[@]" "$expl[@]" "$sopts[@]" \ -M "r:|${sep}=* r:|=* $matcher" - $pref$matches else - if (( $matches[(I)${tmp1[1]}${sep}*] )); then + if (( $matches[(I)${tmp1[1]}${sep}*] )) && + ! (( $matches[(I)${tmp1[1]}] )); then compadd "$group[@]" "$expl[@]" -p "$pref" -r "$sep" -S "$sep" "$opts[@]" \ -M "r:|${sep}=* r:|=* $matcher" - "$tmp1[1]" else By the way, do NOT pass an empty separator to _multi_parts. Infinite loop.