Re: _values and end of options

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Marko Myllynen wrote:
>
> Otherwise this works nicely (each of the options is completed only once)
> but -1 -2 are missing from offered options (see _values). I can use --
> to have them included as well (_values -w opts -- $opts) but then -- is
> also offered.

_values starts with a call to zparseopts to remove normal compadd
style options such as -1 and -2. In general these shouldn't occur after
(or mixed with) the values. It mostly occurs when _values is used
within an _arguments spec. In that case the unwanted options only appear
at the beginning. The following patch makes it only remove compadd style
options that occur at the beginning.

> Can _values be used reliably in cases where there might be options as
> values? Or is there a better way to achieve this with compadd or such
> for the above case?

Well, normally you'd use _arguments for options but I assume you have
some reason for not doing that. _values should work but may have some
differences - like not checking the prefix-needed style.

Oliver

diff --git a/Completion/Base/Utility/_values b/Completion/Base/Utility/_values
index ab0e46a..c510b4c 100644
--- a/Completion/Base/Utility/_values
+++ b/Completion/Base/Utility/_values
@@ -3,7 +3,7 @@
 local subopts opt usecc garbage
 
 subopts=()
-zparseopts -D -E -a garbage C=usecc O:=subopts M: J: V: 1 2 n F: X:
+zparseopts -D -a garbage C=usecc O:=subopts M: J: V: 1 2 n F: X:
 
 (( $#subopts )) && subopts=( "${(@P)subopts[2]}" )