From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5614 invoked by alias); 6 Nov 2016 06:42:23 -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: 39846 Received: (qmail 26913 invoked from network); 6 Nov 2016 06:42:23 -0000 X-Qmail-Scanner-Diagnostics: from mail-vk0-f49.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.213.49):SA:0(0.0/5.0):. Processed in 0.910611 secs); 06 Nov 2016 06:42:23 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=SPF_PASS,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.213.49 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=o+ElpFqyxNM1/o7gUdPx8uLzlAQevjjpeMVarFjX2IE=; b=bHnk1G1sCQ/h2NRBe3r55vYau2xtF97bhsyEeqXECowD1V8opmsLo7AMcf99ps8/CI kJGjhsZXzY1Rt3493rsa+u7svM7g3eGegjr6MeYYF4McBvu/weiYz3u0rNqnJCKguvrl rUJ/iT91I4Sw+g61XxL8o/y2qH67EwqQfW97hPwPHEP6SY6+jwHOuYZ2wULCkspgqgLw Y7jiLnGFw6aZsa0b/PUE9Tx8MIWqtXbMUSHLp/zFPtkLH0Nq5mBDgGeT+3ahUsd43GY0 hBnuoat5ps3S+l8QXhezJ3+hZgb0O3E+Juc3EIHao1wtSfd6XY8cFb9H9OETBBiu1jaR T9Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=o+ElpFqyxNM1/o7gUdPx8uLzlAQevjjpeMVarFjX2IE=; b=Lr1Z7mwoov9ktcfeQqcc7q9d0LkN/ct72LOExsDa3Mw5eLx3WBZw7lXNrgkOI0stVU I1iiM6cq6QDy97PZMuW3vUdfWV9mWTTfFcoGURyYj8Tl+r9GXlcnseMEBPsqWAN3rKkj keMjPtGqBNsS2rRS6Y4/BRuiZyYMMps2IhmRoYA2JsRu99nnOJugMwUVzUbVavX/rRr5 R0BqJGjBRiREmQoicmw2ugWcOdZQIRYD9eOt0FppD24pS1J0wCQocm0ba2CqvgbLeWlA Z2VDQrDK7ghMzEGjTwx+h03BnEUQMthv7CuxcRsDqE4RWnr5gZF5YW/jtPEuyhzhq5j1 b/9g== X-Gm-Message-State: ABUngvchmOjuvrd9KHlKoEPS9QVkqTVe6D5kCmSvk7dCKq6NO8Yf52FA2DXJAAXABedIPw== X-Received: by 10.31.172.74 with SMTP id v71mr602306vke.150.1478414530663; Sat, 05 Nov 2016 23:42:10 -0700 (PDT) From: Bart Schaefer Message-Id: <161105234242.ZM24960@torch.brasslantern.com> Date: Sat, 5 Nov 2016 23:42:42 -0700 In-Reply-To: <161104220258.ZM18609@torch.brasslantern.com> Comments: In reply to Bart Schaefer "Re: "fake" style requires at least one real match?" (Nov 4, 10:02pm) References: <161103173955.ZM13768@torch.brasslantern.com> <24199.1478268003@hydra.kiddle.eu> <161104204801.ZM17816@torch.brasslantern.com> <161104220258.ZM18609@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: "fake" style requires at least one real match? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Nov 4, 10:02pm, Bart Schaefer wrote: } } -- then it ignores tag-order entirely: OK, not entirely because it does construct the named-directories-mine tag and use its description -- but it doesn't apply the ordering, it populates all the tags. Really long diagnosis follows, working sort of backwards up the call stack. Skip to the last three paragraphs if you don't want to know all the details. This happens because _tilde calls _users and _directory_stack as well as passing compadd down to _requested for the named-directories tag. So users and directory stack entries look up ignored-patterns entirely separately from the named-directories context. There's no other context for _tilde when it is called from _cd (as opposed to when there is actually a tilde on the line, and you get -tilde- as the context), so you can't apply ignored-patterns to all of it in one go unless you apply it to :cd:*:*. There are probably other cases like this that selectively break the "supplemented context" usage of tag-order, it's just difficult to see unless you're also trying to use ignored-patterns in such a context. The next question is why "_requested users" etc. succeded even though the tag-order style does not include "users". Looking at _complete_debug output, we enter _tilde and it calls _tags users named-directories directory-stack It then does while _tags and tries _requested for all three tags in the first pass of the loop. None of these work because only named-directories-mine is being sought as the current tag in _all_labels. So the loop goes around again, comptags -N moves on to the next tag group, _requested calls "comptags -R" which succeeds, but now $# -eq 1 so neither _all_labels nor _description is called, and _requested returns 0. Therefore both _users and _directory_stack get called, no ignored-patterns are applied, and too much stuff ends up getting passed to compadd. This all bubbles up to _alternative, which is calling while _next_label and inside _next_label is where the supplemented context is built. _tilde gets called, _all_labels reconstructs named-directories-mine, we do one pass that does the right thing with fake and fake-always, but then compadd ($4) on line 35 of _all_labels fails so _all_labels itself fails even though matches were added by _description on line 32; and _alternative goes around the _next_labels loop another time resulting in all the aforementioned breakage in _tilde. The upshot of all this is that _description is never expected to *call* compadd, it's only supposed to generate arguments for compadd that its caller can pass to compadd; but fake and fake-always are in fact compadd-ed directly in _description. _all_labels (in this case) doesn't know they are there, and tells *its* caller to keep looking. I have no immediate idea what to do about this. We can't rewrite every caller of _description to delta $compstate[nmatches] just in case a fake style was used. And in fact it only matters when ONLY the fake matches are added, as the Subject: says ... except: As an additional complication, there's a comment in _describe about bad things happening if _describe is called more than once for the same completion, but that's what may happen if fake or fake-always use the value:description format and there are also descriptions for the other matches in the context.