Re: How about separating "_arguments --" into a new function?

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Jun T wrote on Thu, Oct 14, 2021 at 19:58:17 +0900:
> 2021/10/13 1:04, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> > perhaps the tool could be designed with an eye towards updating existing
> > completion functions?  For instance, perhaps the tool could inspect the
> > existing _cmd file and omit from the output any lines where the
> > --foo[lorem ipsum] part already appears in the file?
> 
> Such a tool is useful, of cause, but analyzing the existing _cmd is
> would be quite complicated, I guess.
> 

Well, the tool doesn't need to update the file by itself.  Even if it
simply spat options grouped into three categories — "definitely in the
file", "definitely not in the file", and everything else — that'd still
save most of the work in updating the file.

> >> Or just using $_args_cache_cmd is enough?
> > 
> > If it is enough, then it should be made more discoverable.
> 
> I guess it is enough since no one is requesting to separate _arguments.
> How about the following?
> 

Are we happy with documenting it as a first-class feature, i.e., one
that we would be expected to continue supporting?  Or would we rather
document this as a "we may change this in the future" thing?

Flow-wise, the mention of _gnu_generic seems to me to be oddly placed:
it's right between mentioning the variable's existence and use.
I suppose I'm suggesting to reorder the information being added.  Not
a blocker, of course; just nice to have.

Typos: "commnd", "chache".

Would prefer «print -r --» in case of backslashes, or perhaps just
«typeset -p».

Cheers,

Daniel


> diff --git a/Doc/Zsh/compsys.yo b/Doc/Zsh/compsys.yo
> index 89b918d60..c00270f3d 100644
> --- a/Doc/Zsh/compsys.yo
> +++ b/Doc/Zsh/compsys.yo
> @@ -4237,6 +4237,17 @@ as `tt(-)tt(-enable-foo)', but the script also accepts the negated form
>  
>  example(_arguments -- -s "LPAR()(#s)--enable- --disable-RPAR()")
>  
> +The list of var(spec)s derived from the help text is saved in an array
> +parameter `tt(_arg_cache_)var(cmd)' where `var(cmd)' is the name of the
> +command.  If `tt(_arguments -)tt(-)' (or tt(_gnu_generic)) does not work
> +satisfactorily for a commnd `tt(foo)', you can save the specs in a file
> +`tt(_foo)' by
> +
> +example(echo ${(qqq)_arg_chache_foo} > _foo)
> +
> +and use it as a draft of your own completion function for the command
> +`tt(foo)'.
> +
>  em(Miscellaneous notes)
>  
>  Finally, note that tt(_arguments) generally expects to be the primary
> 
> 
> 
>