From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20263 invoked by alias); 8 Aug 2013 06:56:17 -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: 31638 Received: (qmail 11949 invoked from network); 8 Aug 2013 06:56:10 -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: <130807235610.ZM24023@torch.brasslantern.com> Date: Wed, 07 Aug 2013 23:56:10 -0700 In-reply-to: <09EC9380-2BAE-4669-B03C-E365FFE1CB00@kba.biglobe.ne.jp> Comments: In reply to "Jun T." "why '_file -/' completes files if there is no directory?" (Jul 25, 11:09pm) References: <09EC9380-2BAE-4669-B03C-E365FFE1CB00@kba.biglobe.ne.jp> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: "zsh-workers@zsh.org" Subject: Re: why '_file -/' completes files if there is no directory? MIME-version: 1.0 Content-type: text/plain; charset=us-ascii This came in while I was on vacation, but I noticed it still has no replies. On Jul 25, 11:09pm, Jun T. wrote: } Subject: why '_file -/' completes files if there is no directory? The literal answer to this question is that _files always completes anything in the filesystem. The -g and -/ options don't mean that matches will be restricted, just that they'll be grouped differently. } With the following style: } zstyle ':completion:*:warnings' format 'No match for: %d } } If there is no subdirectory in the current directory, } zsh$ cd } gives } No match for: `local directory' } but } zsh$ rmdir } completes the normal files in the current directory. I suspect it was left that way because people who were used to the older, less context-aware completion preferred the visual feedback of having *something* completed. } Not a serious problem, but I prefer getting a warning than being } offered a useless list of normal files. } } Are there any way to stop this behavior by using zstyle? Yes, though it's not obvious. More below. } I tried } zstyle ':completion:*:directories' file-patterns '*(-/)' } but it didn't' work (it seems setting file-patterns for a specific } tag has no meaning). Right, the file-patterns style may be used to *define* the tags, so it is evaluated before the tag part of the context is generated. } Setting file-patterns (or tag-order?) to each } context ':completion:*:gcc:option-I-1:*' etc. may work, but I don't } want to do that even if it works. Yes, tag-order is the "approved" mechanism. However, zstyle provides a convenient back-door for the cases where the approved method is not general enough: the -e option calls "eval" on the style value at the point where the style is looked up, which means you can examine the current state of local variables, etc. Here's your answer: zstyle -e ':completion::*' file-patterns \ '[[ $funcstack[1] = _files && $type = */* ]] && reply=("*(/)")' This isn't ideal because it's fragile if _files is ever rewritten, but those core completers are pretty stable at this point.