From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19659 invoked from network); 1 Sep 1999 11:03:32 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 1 Sep 1999 11:03:32 -0000 Received: (qmail 9724 invoked by alias); 1 Sep 1999 11:03:15 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7601 Received: (qmail 9717 invoked from network); 1 Sep 1999 11:03:13 -0000 Date: Wed, 1 Sep 1999 13:03:03 +0200 (MET DST) Message-Id: <199909011103.NAA00249@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Tanaka Akira's message of 01 Sep 1999 19:35:17 +0900 Subject: Re: PATCH: Completion/Cvs/ Tanaka Akira wrote: > > In this example I think I would like to have it complete `vi' if the > > cursor is directly after the `-e' (same word), because the `*::...' > > should only take affect on whole words, i.e. in this case the word > > after the `-e...'. > > Why? Since a first non-option argument is the `a', I think the > `*::...' should take affect the `-e...' after the `a'. > > I want to stop completion by _arguments until first non-option > argument --- the `a'. So In the example, I want the behaviour that > there should be no completion after the `a'. Ahem. Sorry, I simply overlooked the `a' in your previous mail. You are right. > > With that, this is just a special case of a more general problem with > > completion after a `-e+:...' option. Currently we use the description > > for the first option-argument to complete the next word after the `-e' > > only if there really is nothing after the `-e' in the same word (so > > that `foo -e ' completes the option-argument and `foo -ebar ' > > completes normal arguments). But what if the empty string is a valid > > option-argument? I think `-e+::...' should give us that (that's what > > the patch below does). > > I think this is another issue. > > Even if the empty string is a valid option-argument, getopt does not > take the option-argument from the same word because getopt never > knows it. In general, it is impossible to parse command line with the > rule that enable the empty string option-argument just after (without > white space) the option-argument word. So I think it is useless. The patch was mostly cosmetic, in fact. The question is: will users think that `-e+::..' does what they want in this case or not? Personally I don't care much if the patch is included or, since I would use `-e-:..' in such cases. Bye Sven diff -u oc/Base/_arguments Completion/Base/_arguments --- oc/Base/_arguments Wed Sep 1 13:02:10 1999 +++ Completion/Base/_arguments Wed Sep 1 13:02:36 1999 @@ -525,6 +525,8 @@ # We either don't have a description for an argument of an option # or we have a description for a optional argument. + opt=yes + if [[ -z "$def" ]]; then # If we have none at all, use the one for this argument position. @@ -535,6 +537,7 @@ optbeg="$nargbeg" argbeg="$nargbeg" fromrest=yes + [[ "$def" = \*::* ]] && opt='' fi fi @@ -542,8 +545,7 @@ # be in a string that starts with an option name and continues with # the first argument, test that (again, two loops). - opt=yes - if (( $#dopts )); then + if [[ -n "$opt" && $#dopts -ne 0 ]]; then # Get the option names. -- Sven Wischnowsky wischnow@informatik.hu-berlin.de