From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14644 invoked by alias); 23 May 2012 06:08:55 -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: 17113 Received: (qmail 17011 invoked from network); 23 May 2012 06:08:42 -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: <120522230819.ZM2600@torch.brasslantern.com> Date: Tue, 22 May 2012 23:08:19 -0700 In-reply-to: Comments: In reply to Greg Klanderman "Re: completion oddity" (May 22, 6:55pm) 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> In-reply-to: Comments: In reply to Greg Klanderman "Re: completion oddity" (May 22, 7:09pm) 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, 6:55pm, Greg Klanderman wrote: } } OK, thanks for looking into this Bart. So _main_complete is still } looping over zstyle matcher-list values in completing parameters but } it's not used? I do see that _arguments uses _description which uses } _matcher if non-empty (as you noted earlier). Hmm, hadn't thought about that ... _parameters calls _wanted so it does go through _description, which means the matcher-list is also applied to parameter names. At this point I have no idea whether that is intentional. } I have to confess I cannot follow all this completion code though. I'm not sure anyone can. On May 22, 7:09pm, Greg Klanderman wrote: } } > You're right; in the first case the completion system has recorded a } > list of "ambiguous positions" that distinguish what it filled Sorry, thinko there -- it actually records UNambiguous positions, and insert_positions which are the places that something needs to be added or changed in order that the word on the line match one of the possible completions. } Oh the horrors never end.. could you be so kind as to point me to some } of the relevant bits of code that are doing this logic and how that } state is stored? Please tell me it's not in the even more } impenetrable C code.. The state is available in the compstate hash, which is actually pretty thoroughly documented (though exactly what the internals do with the values isn't, so much). However, yes, the logic that figures out what are insert_positions and what are unambiguous_positions is all deep in the C code. There is exactly one example of shell code making use of one of those values: Functions/Zle/cycle-completion-positions -- but it's not very helpful.