From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29489 invoked by alias); 10 Sep 2016 02:40:37 -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: 39263 Received: (qmail 16150 invoked from network); 10 Sep 2016 02:40:37 -0000 X-Qmail-Scanner-Diagnostics: from mail-pa0-f51.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.220.51):SA:0(0.0/5.0):. Processed in 0.596147 secs); 10 Sep 2016 02:40:37 -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=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: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) 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=cN70XShH3IWEhYgFN4uByFd7es/7Kf/BkAx3sPDZP8E=; b=d+oIQrI91lLQsmyAckqPhHsuJc6vINquS415o3UPTjIhwTeHNr7zRRNnTE3Kdg0em/ eSrG8hPTI7YsWYdG2jSotdAf3eBc2clwmLs3GcEv2MLP6xebovqCuj7kwlVYXrAbwWMR Xzi4t2mUi6gUzYRC/Hy6kgdv+t94nE/G87/zds5JuZafuCxd+kJj+FkiIAk+e6W1OQyR 3IabnQWKD+mX5Hc6MLfekSv74f4c4z9FGsRWfLBl0Ls6+XBnVKJlERGcOWV7dVCbC1i5 6elDqMt5BjfOmarcOReJYZcBPuxnFhS6cwoyjXAYqY+awEFmcILICVisMM5d+WCjmKzR 7Y9A== 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=cN70XShH3IWEhYgFN4uByFd7es/7Kf/BkAx3sPDZP8E=; b=Okrx3Lzc+7DPSVpNNBLS1wXlXpI9WlS+2lQ/rJ7zA5KPQJwQIzezHhTwQJQ65GYadq Qd20BVFpMPwP58FwFTqPl94HoXLMk6H+5iMESSHwQ0AbE6/3cQtGrJ603++jjLavcihm 6+54QQ2q/yWPdum5TxxI5vpDfuSu371nwUmMfXdHquCOIBMiCi1+f27OlyvXRjzIrRLz drr4gBiV9SFndtWQOdya2MC69mFkLmjfNthEww0M60OSqvR+CiZxWrnpaq0FY+rbB3Ic nXbdpYr5fAYxlSierA/fYfHmy+3BokyvDLQrfSc6+HMeMqi/ajIToc39BjeqD1z9k2sb KHag== X-Gm-Message-State: AE9vXwOzw21Ev2R83qZFGQ/yw03R1aclrlMFwO7bd4s50AzXAaB6YkIAT2xBeSlSbewHKQ== X-Received: by 10.66.228.2 with SMTP id se2mr11998067pac.93.1473475229933; Fri, 09 Sep 2016 19:40:29 -0700 (PDT) From: Bart Schaefer Message-Id: <160909194033.ZM19936@torch.brasslantern.com> Date: Fri, 9 Sep 2016 19:40:33 -0700 In-Reply-To: <75f69404-5bc4-20e5-caf7-3d0a6dd87b59@redhat.com> Comments: In reply to Marko Myllynen "Pattern matching with _files vs command line" (Sep 9, 8:39am) References: <75f69404-5bc4-20e5-caf7-3d0a6dd87b59@redhat.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh workers Subject: Re: Pattern matching with _files vs command line MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 9, 8:39am, Marko Myllynen wrote: } } _wanted files expl file _files -g '*(-FM)' && ret=0 } } I see the following difference, is this expected or perhaps a bug? It's perhaps a documentation shortcoming. _files actually creates three groups of completion results: globbed-files directories all-files There's a little comment buried in _files: # People prefer to have directories shown on first try as default. # Even if the calling function didn't use -/. So what you're seeing is both the globbed-files group and the directories group. The all-files group is empty because the globbed-files group is not. The way around this is to use either the file-patterns style, or the tag-order style. Either of these is supposed to work: zstyle :completion::complete:foo:: file-patterns '%p:globbed-files' zstyle :completion::complete:foo:: tag-order globbed-files - HOWEVER, you've actually broken things with your glob pattern. Adding the (M) flag means that the generated completions end with a "/" -- that is, the "/" is not just shown in the completion listing, it's actually required to match against any partial word already on the command line, which causes a variety of strange effects (including the duplicates in your original listing). What you really mean is just: --- 8< --- snip --- 8< --- #compdef foo _wanted files expl file _files -g '*(-F)' --- 8< --- snip --- 8< --- There's no need for the "ret" local if you're only making one call to _wanted, you can just use the return value from that directly. ADDITIONAL ASIDE to -workers: The weird side-effects that result here from having the trailing "/" in the completion results seem to be tangentially related to the thread from 39093 where the whole current word gets erased. When all the completions end in "/", it is the first unambigous character, so % foo % foo / with the curson on top of the "/". But now subsequent attempts to complete end up looking for files in the root directory, because the detail that there was an ambiguous prefix has been lost.