From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4187 invoked from network); 8 May 2000 17:58:37 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 8 May 2000 17:58:37 -0000 Received: (qmail 14144 invoked by alias); 8 May 2000 17:58:25 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11267 Received: (qmail 14110 invoked from network); 8 May 2000 17:58:22 -0000 From: "Bart Schaefer" Message-Id: <1000508175816.ZM17624@candle.brasslantern.com> Date: Mon, 8 May 2000 17:58:14 +0000 References: <200005080900.LAA13146@beta.informatik.hu-berlin.de> <200005080944.LAA15834@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Assorted _arguments arguments MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On May 8, 11:00am, Sven Wischnowsky wrote: } Subject: Re: PATCH: Re: sudo completion problem } } Zefram wrote: } } > If we can determine that a particular command is processing options in } > this way, it would be nice to complet options accordingly. However, } > by default options should only be completed before the first non-option } > argument. In either case, options should never be completed after a "--". } } I don't buy this. There *may* be commands or shell functions which } take `--' to, e.g., separate different sets of options and arguments. As an example, consider writing a completer for the old compctl command, following a -x option. } _arguments is intended to be general enough to generate sensible } completions even for user-written shell functions, after all. I'm with Sven here. I don't think making _arguments more specialized is the right thing. There should perhaps be a fairly trivial way to tell it to stop completing options after a non-option argument, including `--' as a non-option, but otherwise I think it may already even go too far in treating words that begin with a `-' specially. } But before I start writing it: should the default for _arguments be } changed? And would someone be willing to check all uses of _arguments } and add the option to the calls that need them? I don't think it makes a lot of difference which way the default goes; do whatever would require the fewest changes to _arguments and to all the other functions that call it. On May 8, 11:44am, Sven Wischnowsky wrote: } Subject: Re: optional argument? } [Tanaka-san wrote:] } > This is caused by optional argument for --context. In this position, } > _diff_options should completes only new files: second file set. In } > general, optional argument of _arguments always causes similar } > problem, I think. So, I think it is bit confused and not so useful. } } Hrmpf. Make `='-options complete the argument *only* after the equal } sign? Add a new specification type, say `-opt==' for options that } don't accept the argument in a separte word (should the long-option } auto-detection code use it then?)? On May 8, 11:49pm, Tanaka Akira wrote: } Subject: Re: optional argument? } } Actual commands which has optional arguments judge whether they are } specified or not in a some criteria. So, supporting some common } criteria is useful. } [...] } } Exactly, the existence of `=' is the criteria used by getopt_long. So } it's good. But I vote `-opt=?' instead of `-opt=='. I think we should try to make the syntax consistent with `getopts' and `zparseopts' if possible. Maybe that _isn't_ possible do to conflicting use of colons ... and maybe we should have thought of that before we used colons everywhere, but ... } Note that another common criteria is that a optional argument must be } some set of strings: `yes' or `no' for example. At least, xset } handles optional arguments in this way. If we can specify a pattern } addition to the current optional argument syntax, it can be handled. If there's a known set of strings that can be the optional argument, then I think this can be handled with state changes and/or alternation and we don't need any more patterns jammed into the opt-spec. } Apart from that, I hope a extension for _arguments. There are } many duplicated descriptions such as: } } '(-i)--ignore-case[case insensitive]' \ } '(--ignore-case)-i[case insensitive]' \ } '(-w)--ignore-all-space[ignore all white space]' \ } '(--ignore-all-space)-w[ignore all white space]' \ } } So, I really want to describe them as: } } '--ignore-case,-i[case insensitive]' \ } '--ignore-all-space,-w[ignore all white space]' \ } } In other words, I think it is useful that opt-spec is comma separated } list of options. And exclusive options are automatically set up each } other if they are not prefixed as `*'. On a similar topic, can anyone think of a way to write an exclusive-or glob pattern? E.g. I want to match ChangeLog if that exists, or Changes if that exists, but neither if both exist? Returning to the original topic, perhaps a better way to think of this is that -i and --ignore-case are synonyms and should get the same treatment and description. E.g. your suggestion does not help with a case like _bzip2: '(--decompress --compress -z --test -t)-d[decompress]' \ _bzip2: '(-d --compress -z --test -t)--decompress[decompress]' \ _bzip2: '(--compress --decompress -d --test -t)-z[compress]' \ _bzip2: '(-z --decompress -d --test -t)--compress[compress]' \ where you have both options that have alternate names for each other and are mutually exclusive with other options. Much better would be, say, '-d(--decompress)' '-z(--compress)' '-t(--test)' \ '(-z -t)-d[decompress]' \ '(-d -t)-z[compress]' \ '(-z -d)-t[test compressed file integrity]' \ It might even be able to compute this automatically from the comma-lists in --help output, or some such. (No, I don't really like the `-x(--xxx)' syntax, but I haven't time to think harder about it just now.) -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com