From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22255 invoked by alias); 23 May 2012 06:32:02 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 17116 Received: (qmail 24395 invoked from network); 23 May 2012 06:32:00 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) 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.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <120522233155.ZM2630@torch.brasslantern.com> Date: Tue, 22 May 2012 23:31:55 -0700 In-reply-to: <20120522230646.GD10763@lorien.comfychair.org> Comments: In reply to Danek Duvall "Re: completion oddity" (May 22, 4:06pm) References: <20120521214023.GB10763@lorien.comfychair.org> <120521194232.ZM990@torch.brasslantern.com> <20120522050158.GC26384@lorien.comfychair.org> <20120522051617.GD26384@lorien.comfychair.org> <120521233507.ZM1136@torch.brasslantern.com> <20120522230646.GD10763@lorien.comfychair.org> <20120523010322.GF26384@lorien.comfychair.org> In-reply-to: <20120523010322.GF26384@lorien.comfychair.org> Comments: In reply to Danek Duvall "Re: completion oddity" (May 22, 6:03pm) X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: completion oddity MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On May 22, 4:06pm, Danek Duvall wrote: } } So if I set up my own style processing in order to override this } behavior (both the earliness and the use of the empty value) as you } suggested to Greg, would it be kosher to use the matcher-list style, } or would I want to use my own style name? Doesn't really matter. Using the matcher-list name means that any definition of that for any less-specific context will end up applying to your more specific situation, but if you're planning always to provide the most specific definition then that won't matter. } > } gtar --show--names } > } } > } and it beeps and moves me to between the second double-hyphen, } > } then after another beep, starts cycling between the two. If I } > } just have "--show" there, then it ends up cycling among four } > } alternatives. } } --show-defaults } --show-omitted-dirs } --show-transformed-names } --show-stored-names Oh, well, that all makes sense. When you have all four possibilities there are no common suffixes, and when you do have a common suffix there are the same number of words; in neither case is there the possibility of resolving the ambiguity. On May 22, 6:03pm, Danek Duvall wrote: } Subject: Re: completion oddity } } ... is there some way, either in a user's configuration or within } a single completion function, to turn off the "end with the same } substring" completion, while maintaining the dash-separates-words } aspect of the completion [...?] In fact, there is, and it's at once so obvious and so unintuitive that I'm quite sure it wasn't done on purpose. Define _k this way: _k() { _arguments --really-r1-word --r1-word } The specifications passed to _arguments are tried in order, so if the longer one (which I suspect means the one having the most words rather than the most characters) is tried first, the ambiguity is re-discovered and you get menu completion.