Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: Completion/Cvs/
- X-seq: zsh-workers 7601
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: PATCH: Completion/Cvs/
- Date: Wed, 1 Sep 1999 13:03:03 +0200 (MET DST)
- In-reply-to: Tanaka Akira's message of 01 Sep 1999 19:35:17 +0900
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
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 <TAB>' completes the option-argument and `foo -ebar <TAB>'
> > 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@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author