From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19806 invoked by alias); 6 Nov 2016 23:47:36 -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: 39850 Received: (qmail 26345 invoked from network); 6 Nov 2016 23:47:36 -0000 X-Qmail-Scanner-Diagnostics: from mail-ua0-f177.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.217.177):SA:0(0.0/5.0):. Processed in 0.799353 secs); 06 Nov 2016 23:47:36 -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.217.177 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=jB5TbOof+kf4bujhcN9HMpDTF/IKhSLQT/ERO0XUfQw=; b=g+eRrVAyqFTsagd0CZIcq79jVUD3zXSzVFrtHOFKx3+gKqZEfxtu9CNuQdpbVX2k0K XHvoXaI+Vsp4PK+NCAW3oA3XRc3LYsGSnoicHeyRpBlZCZ+f22fBaDefRZItBiei4Rxc Eat+hza6MpACBAlTQNpQhimmIuFflGQUcyTm7CUpSMFO3VbLlAZScUSXIWlkelTUGI8d HA+MSb5hEgeRc5O90fQTUVB/FGBZbjKGifyoaHiLSlQNx7/LUfJZc1fiPE5pNwLmy2kC zeyhoFNGbT0SEX98Y07Dv8TzcyGrTWKwgxeUl/7vOdKZXu9RCTScPN2OQM58xKtnEyWg T/vg== 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=jB5TbOof+kf4bujhcN9HMpDTF/IKhSLQT/ERO0XUfQw=; b=fwY7UNEo+u8qUPA80lkq5vbW7q/TCrnENs/JWOIKqZqOW7tjkBb3vPf/jhGXcniu3t t0r1Pj2ERAbBJl0ExEx9LwRIye8ntMksy4bYiRNbWSX7oJfUxjxb0uEgTnZZWqDn/YI9 /ANuSEqoG3EmCSw5YK425qqPFM/N8JZily6sdS8wDIwagxWrPCylhLRBcJD4vEfIHWMM 0JPJdzigZC6nDbHYfacyprHe/XMZhiYDLNnb0wL/vsq2SlPx1rH7SHiXJhzCqi7MW8z/ nyZOtqpnXFvNaYJ4HVqBLR59AMRaRE1Bnigf5l2ivNg8dCsIEvIvuJrwTSvEEJxMJLGZ W/OA== X-Gm-Message-State: ABUngvengiCbPTcnsx63RT9DWpz8LJ29/HPPnHcN+ME57kRNkzd5ygRTJUUTrvszPIYH+w== X-Received: by 10.176.5.137 with SMTP id e9mr1799043uae.109.1478475689120; Sun, 06 Nov 2016 15:41:29 -0800 (PST) From: Bart Schaefer Message-Id: <161106154202.ZM21049@torch.brasslantern.com> Date: Sun, 6 Nov 2016 15:42:02 -0800 In-Reply-To: <161105234242.ZM24960@torch.brasslantern.com> Comments: In reply to Bart Schaefer "Re: "fake" style requires at least one real match?" (Nov 5, 11:42pm) References: <161103173955.ZM13768@torch.brasslantern.com> <24199.1478268003@hydra.kiddle.eu> <161104204801.ZM17816@torch.brasslantern.com> <161104220258.ZM18609@torch.brasslantern.com> <161105234242.ZM24960@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 5, 11:42pm, Bart Schaefer wrote: } } 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 ... I looked through all the functions that call _description and for the vast majority of them this only matters indirectly to the caller of the function; that is, the usage is equivalent to _description ... compadd ... return which means that unless the caller is testing the return value to decide whether to proceed with another completion, adding fake matches in _description does not affect anything. Ignoring for the moment functions that might appear directly in the 'completer' style, that leaves the following callers of _description: _requested and _next_label both ignore the result of _description and always return zero after calling it. _alternative does the "right thing" and uses a delta of nmatches to decide what to return. _values uses _all_labels and a _next_label loop. _next_tags redefines _all_labels and _next_label, so I'm going to ignore it for this purpose. And then there's _arguments, which has a _tags loop but is a wrapper that calls back to whatever was passed into it; so there's really no reasonable way to analyze it. I think, therefore, the only reasonable thing is to fix _all_labels, which should by proxy fix _values. However, it's a little more complicated than I first thought. A compounding problem is that we're calling _tilde from _alternative. _alternative does its own call to _description on line 28, inside the _tags loop. Inside _tilde, we start another _tags loop, which eventually calls _all_labels, which calls _description *again*. The fake matches were already added by the first call in _alternative, so compstate[nmatches] is unchanged and can't work as a test for the appropriate return value for _all_labels. For the moment I'm stuck. Sorry for the play-by-play. Ideas welcome. Probably not worth holding up a release, if one is being considered.