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

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Oliver Kiddle wrote on Thu, Apr 01, 2021 at 14:53:02 +0200:
> You wrote:
> > +++ b/Completion/Zsh/Function/__arguments
> 
> It occurs to me that if completion for completion functions is a useful
> thing,

Well, I do look up compadd and _arguments' options in the manual
somewhat frequently.  That's what gave me the idea of the 1/2 patch in
the first place.

> _compadd could define a pattern to complete compadd options for
> all commands named _*.

That might be useful for writing completion functions at the prompt.  Of
course, it's not needed for the "jog one's memory" use-case, since in
that case one can just do «compadd -<TAB>».

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

To make this work, presumably compadd would want to register itself not
for «_*» but for «_[^_]*» (glob, not regexp), so the patterns don't
overlap.  Whether it's a good idea to default __* functions to be
completed by _nothing I don't have an intuition for, yet.

> 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.

_git didn't exactly invent this.  Using single or double leading
underscores for private symbols is standard this way is standard or
idiomatic in other languages too.

> I don't know whether you were planning to push this

I was/am.

> 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 '-*'.

Hmm.  How about «-A '-*|:|(!|)\(*'»?

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

Could we leave this for future work?  Not to let the perfect be the
enemy of the good, etc..

> > +    '-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.
> 

I'll add !, and we should document that in the manual too if it isn't
already.

> > +    "-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.

There isn't room to say all this inside the brackets.

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

Good point.  How about deleting the parenthetical?  Or replacing it by
"(see manual)"?

> > +    "-R[when \`->action' matches, return 300]" \
> 
> I don't think that really gets used much [[ -n $state ]] is more
> readable.

How does this affect the patch?  Are you suggesting to hide (with «!»)
this too?

> > +    "-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.
> 

I'll make it so.

> _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.

Sounds like a question for a new thread.

> > +    '*: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.

Good catch; will fix.

Thanks for the review,

Daniel