From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 366 invoked by alias); 12 Sep 2016 04:31:07 -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: 39291 Received: (qmail 25829 invoked from network); 12 Sep 2016 04:31:06 -0000 X-Qmail-Scanner-Diagnostics: from mail-wm0-f42.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(74.125.82.42):SA:0(-0.0/5.0):. Processed in 0.314446 secs); 12 Sep 2016 04:31:06 -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 autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: myllynen@redhat.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 74.125.82.42 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=EgV6dKRXKaHRio0Hj0IGaUO2puiKy/2IIAMRxxWumkQ=; b=FbuFlMMsYDa///Q0c6gObYvjhtQEFrIijHmJ1N1YIdsgMq8Eu+ixKIanMq3ifN4iTG 1Zu27yVpCOBJbqOdJ1GfpZFEKd+r0fBsk5OJq9v0hBFW58cZS/Gj5DzT3ZQzfzNebSdq pLkMfCv/kBV9Ln/yjobZOHgZTafyH+lRv0d030HU0NqSoEjs9YJaLg1nXIIFaZefJSIi 2QzN6icmHrD7eP3lKN2cosPK11QS7E56yvLmKwVXLufxsty4qi01yHoBWmefafVUtKgP YaVh6mVHI+wEoZBho7yHnjOrWg0qM0yi28xwp8x0VkuFJ/lbjdNNqppq00r6gVf0S70g iNnw== X-Gm-Message-State: AE9vXwNdNjftRBOF/pz1053SPe1BxUnf4swzVECW2hw6gXwXiUA5ntDtqecaGYaogj+Q1mcj X-Received: by 10.28.19.134 with SMTP id 128mr8057383wmt.40.1473654655317; Sun, 11 Sep 2016 21:30:55 -0700 (PDT) Reply-To: Marko Myllynen Subject: Re: Pattern matching with _files vs command line References: <75f69404-5bc4-20e5-caf7-3d0a6dd87b59@redhat.com> <160909194033.ZM19936@torch.brasslantern.com> To: zsh-workers@zsh.org From: Marko Myllynen Organization: Red Hat Message-ID: Date: Mon, 12 Sep 2016 07:30:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <160909194033.ZM19936@torch.brasslantern.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, On 2016-09-10 05:40, Bart Schaefer wrote: > 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' Thanks, this did the trick! > zstyle :completion::complete:foo:: tag-order globbed-files - This, however, doesn't seem to work: with or without the former this stops completion for foo altogether. > 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. Yeah, it was a copypaste from a larger function which wanted ret. Thanks, -- Marko Myllynen