From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20776 invoked by alias); 9 Aug 2013 05:59:39 -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: 31646 Received: (qmail 19329 invoked from network); 9 Aug 2013 05:59:33 -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: <130808225913.ZM25757@torch.brasslantern.com> Date: Thu, 08 Aug 2013 22:59:13 -0700 In-reply-to: Comments: In reply to "Jun T." "Re: why '_file -/' completes files if there is no directory?" (Aug 9, 1:34am) References: <09EC9380-2BAE-4669-B03C-E365FFE1CB00@kba.biglobe.ne.jp> <130807235610.ZM24023@torch.brasslantern.com> 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 On Aug 9, 1:34am, Jun T. wrote: } } Interestingly, 'gcc -I' gives nothing, i.e., not completes } normal files nor gives a warning. } 'gcc -I./' does give a warning, though. This comes down to some oddness in _describe. In the first case (no warnings), "compdescribe -g csl2 _args _tmpm _tmpd" succeeds so a compadd call is made, _ret=0 is assigned, and _describe returns 0 without reaching the end of the _tags loop. In the second case, compdescribe fails so _describe falls out of the _tags loop and returns 1. You mention that: } This happens only if the optspec given to _arguments has the form '*-I-'. In this form, the string "-I" is provided to compadd as a possible completion (because it is allowed to appear more than once on the command line). With the form -I- it is not, because it's allowed only once; with *-I the code takes an entirely different path because a separate word is being completed, and _describe is never called. The result of all this is that with an optspec in the "*-I-" format, the -I by itself is treated as successful but ambiguous completion, rather than as a finished option string that needs its argument. I think this is probably a bug in comparguments -- it should be able to tell from the single colon in "*-I-:header file ..." that -I can't appear a second time without first filling in its mandatory argument -- but like most of us I'm lost as to whether the problem is with computil.c:ca_parse_line during "comparguments -i", or whether it's actually a bug in cd_init or cd_get as part of compdescribe, or ...