From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19504 invoked by alias); 1 Mar 2013 05:56:47 -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: 31088 Received: (qmail 3136 invoked from network); 1 Mar 2013 05:56:45 -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: <130228215632.ZM9327@torch.brasslantern.com> Date: Thu, 28 Feb 2013 21:56:32 -0800 In-reply-to: Comments: In reply to joe M "trying to understand how the zsh completer works" (Feb 28, 6:38pm) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: trying to understand how the zsh completer works MIME-version: 1.0 Content-type: text/plain; charset=us-ascii I'm wondering if this doesn't belong on zsh-users rather than -workers? On Feb 28, 6:38pm, joe M wrote: } } I am trying to tell the completer to use a different completer based } on context. } } In this situation, I am trying to tell it to use the _approximate } completer when completing the argument-rest context of grep. Unfortunately this is one of the things that mostly doesn't work. The set of completers is determined very early in the process when the context is still very non-specific -- because it is the completers themselves that supply the semantic analysis to fill out the rest of the context. Note that the definition of a the zstyle context for completion is :completion:FUNCTION:COMPLETER:COMMAND:ARGUMENT:tag This roughly corresponds to how far down into the completion process the current operation has progressed. More detail is appended to the context at each stage. The current completer is the third component; by the time the context has been built up to the fifth component, it's way too late for the style "completer" to be meaningful. It can only be usefully looked up at the very beginning (:completion:) or during the first FUNCTION (:completion:hist-complete: to use one of your examples). In retrospect it might have been useful to split the context analysis from the generation of matches, rather than having a single function responsible for doing both parts for each command name. On the other hand that would have doubled the number of functions (or at least the number of call signatures) and we'd probably never have gotten done with the implementation. :-} If you do put _approximate in the global list of completers, you can see where it appears in the context -- see how it's "upstream" from *:grep:argument-rest: ? tags in context :completion::approximate::: corrections original (_approximate) tags in context :completion::approximate-1:grep:: argument-rest options (_arguments _grep (eval)) tags in context :completion::approximate-1:grep:argument-rest: globbed-files (_files _arguments _grep (eval)) tags in context :completion::approximate-1:grep:options: options (_describe _arguments _grep (eval)) tags in context :completion::complete:grep:: argument-rest options (_arguments _grep (eval)) tags in context :completion::complete:grep:argument-rest: globbed-files (_files _arguments _grep (eval)) This means that _approximate is (indirectly) calling _grep, not the other way around as you might expect. The only workaround for this is to do your own context analysis and embed that in the style value via "zstyle -e". Something like: zstyle -e ':completion:*' completer \ 'reply=(_complete); \ (( $CURRENT > 2 )) && [[ $words[1] = grep ]] && reply+=(_approximate)' Yes, this could get ugly quickly if you want to customize a lot of completers for individual commands or word positions.