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

[Daniel Shahaf <d.s@daniel.shahaf.name>]

Jun. T wrote on Sat, Oct 09, 2021 at 01:12:42 +0900:
> _gnu_generic works rather well for basenc, and '_arguments --'
> caches the option specs generated from the --help text in a variable
> _args_cache_basenc. So I created _basenc by
> 
> % compdef _gnu_generic basenc
> % basenc <TAB>
> % echo ${(F)${(qqq)_args_cache_basenc}} > _basenc
> and edited _basenc (to add option groups etc.).
> 

Nice :)

> If we separate the part of _arguments that generates the option specs
> (around lines 36 - 323) into an auto-loadable function, say help2specs,
> then we will be able to do something like
> 
> % help2specs cmd > _cmd
> (and edit _cmd to improve it)
> 
> If this seems useful I'll work on it.

A tool that takes some command's --help output and produces a skeleton
completion function would certainly be nice for people writing
completion functions.  However, creating a new completion function isn't
a common task; I suspect it's more common to update an existing
completion function with more custom logic or with new options.  So,
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?

Perhaps make the tool a filter, in order to support, say, «ssh foo
'lorem --help' | help2specs»?

The docs of _arguments say one should declare «local context state
state_descr line; typeset -A opt_args» whenever one uses -> actions.
Some tool (not necessarily the same tool as the proposed help2specs
tool) that prefills those lines would be nice to have: that would
prevent people from forgetting or overlooking those declarations, and
having them prefilled would be easier than copying them from the manual.

> Or just using $_args_cache_cmd is enough?

If it is enough, then it should be made more discoverable.

> If _arguments is separated into two, tracing the history by 'git blame'
> etc. would be a little bit tedious.

Well, yes, but on the other hand, _arguments would then be "doing one
thing and doing it well", and its documentation would be clearer.  And
_arguments' own source code might be clearer too.  (I don't have
a strong opinion; I'm just playing Devil's advocate.)

Of course, if _arguments does get splitted, it may then be needed to
update __arguments.

Cheers,

Daniel