Re: [PATCH] Completion: Add _log_priorities, _logger

["Daniel Shahaf" <d.s@xxxxxxxxxxxxxxxxxx>]

dana wrote on Sat, 02 Nov 2019 06:58 +00:00:
> On 2 Nov 2019, at 01:45, dana <dana@xxxxxxx> wrote:
> > That would definitely work, and be easy to parse, though it is a bit
> > unattractive, especially given how these functions are often called.
> 
> Oh, i realised with your *very* first suggestion, the quoting wouldn't be
> quite as bad:
> 
>   '--foo=[specify foo]: :_my_type -Y-a -Y"my optarg" -Y-bcd'
> 
> Though it's certainly strange in a different way.

Strange how?  I think it's pretty intuitive: to call «_foo "$bar[@]"»,
write «_foo -Y"${^bar[@]}"» (?).  This is:

- Completely generic: it doesn't depend on the value of «"${bar[@]}"»,
  whether it uses single-letter options or GNU-style long options or
  anything else.

- Composable: it's trivial to pass -bcd through _two_ layers of these
  wrappers, should that ever be necessary.  (Example: pdebuild(1) calls
  dpkg-buildpackage(1) which in turn calls dpkg-genbuildinfo(1), and
  it's possible to pass dpkg-genbuildinfo(1) arguments to pdebuild(1).)

- Requires no new code to implement.  It's simply a repeatable option
  whose optargs are collected in an array.  Both zparseopts and _arguments
  already support this.

> It would be cool if there was a convenient way to just have a general prefix
> for options, so that this kind of thing would work:
> 
>   '--foo=[specify foo]: :_my_type -Ya "my optarg" -Ybcd'
> 
> (The point being that (a) you don't have to repeat the hyphens and (b) it
> knows that "my optarg" is an argument to the type function's -a.)
> 
> Maybe zparseopts could be extended to do that somehow, if it's not too silly
> of an idea.

*nod*

Cheers,

Daniel