From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Zsh workers <zsh-workers@zsh.org>
Subject: Re: [PATCH 1/2] __arguments: New completion function for _arguments.
Date: Thu, 1 Apr 2021 17:33:05 +0000 [thread overview]
Message-ID: <20210401173305.GB11180@tarpaulin.shahaf.local2> (raw)
In-Reply-To: <96182-1617281582.024669@4LIl.h-KW.lXZv>
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
next prev parent reply other threads:[~2021-04-01 17:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 0:00 Daniel Shahaf
2021-04-01 0:00 ` [PATCH 2/2] ___arguments: New completion function for __arguments Daniel Shahaf
2021-04-01 12:53 ` [PATCH 1/2] __arguments: New completion function for _arguments Oliver Kiddle
2021-04-01 17:33 ` Daniel Shahaf [this message]
2021-04-01 22:34 ` _arguments -n / $NORMARG (was: Re: [PATCH 1/2] __arguments: New completion function for _arguments.) Daniel Shahaf
2021-04-09 19:24 ` Oliver Kiddle
2021-04-09 22:52 ` Daniel Shahaf
2021-04-02 23:58 ` [PATCH 1/2] __arguments: New completion function for _arguments Oliver Kiddle
2021-04-10 20:41 ` Lawrence Velázquez
2021-04-13 11:28 ` Daniel Shahaf
2021-04-17 12:25 ` Daniel Shahaf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210401173305.GB11180@tarpaulin.shahaf.local2 \
--to=d.s@daniel.shahaf.name \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).