Re: [PATCH 1/2] __arguments: New completion function for _arguments.

[Oliver Kiddle <opk@zsh.org>]

You wrote:
> +++ b/Completion/Zsh/Function/__arguments

It occurs to me that if completion for completion functions is a useful
thing, _compadd could define a pattern to complete compadd options for
all commands named _*.

And with your __ convention, _nothing could specify a pattern for
completion of completions for completions.

I'm not fond of _git's use of an initial __ on it's private functions
rather than just _git_... (or _git-... for subcommands). We should
perhaps decide and then document the convention.

I don't know whether you were planning to push this or if it only served
as setup for your follow-up but I'll just make a few, um, arguments:

> +  _arguments -A '-*' : \

This is a rare case where the parameter to -A needs to be more
complicated than just '-*'.

I'd actually be inclined to use _regex_arguments for this function.
Would allow specs to be broken up.

> +    '-n[set $NORMARG]' \

-n should not be used, it is fundamentally broken and will never be
fixed because the right answer to $NORMARG as it is defined can be a
list of possibilities. It grabs an internal variable from the first
element of a linked-list and dumps it out. The problem it was added to
solve would have had better solutions.

Could hide it with ! or add a comment.

> +    "-C[modify \$curcontext for \`->action' (requires \`local curcontext')]" \

This is instead of the $context array.
Should only be used where multiple valid states is not a possibility.

I fear that the note in parentheses implies just `local curcontext' and
not local curcontext="$curcontext" is needed.

> +    "-R[when \`->action' matches, return 300]" \

I don't think that really gets used much [[ -n $state ]] is more
readable.

> +    "-M[specify matchspec for completing option names and values]:matchspec for completing option names and values (default\\: 'r\\:|[_-]=* r\\:|=*')" \

The convention widely used elsewhere is to represent defaults in square
brackets without any `default: ' tag.

_description does have mostly unused features for more custom
formatting. We perhaps ought to consider whether this could be better
used for units, defaults, examples, maximums and minimums so that this
is under the control of the user.

> +    '*:spec (e.g., "*(-t --to)"{-t+,--to=}"[specify recipient]\:recipient'\''s address\:_email_addresses)'

In your example, the * needs to come after the exclusion list. ! for
ignored options comes before.

Oliver