Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
In-reply-to: <57596005.3070100@redhat.com>
From: Oliver Kiddle <okiddle@yahoo.co.uk>
References: <57596005.3070100@redhat.com>
To: zsh workers <zsh-workers@zsh.org>
Subject: Re: _values and end of options
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2448.1465487019.1@thecus.kiddle.eu>
Date: Thu, 09 Jun 2016 17:43:43 +0200
Message-ID: <2450.1465487023@thecus.kiddle.eu>

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]}" )