Re: [PATCH] Completion: Add _log_priorities, _logger

[dana <dana@dana.is>]

On 2 Nov 2019, at 00:54, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> That is: use up _one_ top-level option letter and stuff all the not-compadd
> --options and their arguments into the argument(s) of that top-level option
> letter.

That would definitely work, and be easy to parse, though it is a bit
unattractive, especially given how these functions are often called. e.g.,
you could end up with _arguments specs like:

  '--foo=[specify foo]: :_my_type -Y "-a \"my optarg\" -bcd"'

Granted, very few type functions have options that take arguments, so it
probably wouldn't come up that often, but...

On 2 Nov 2019, at 00:54, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> We can also do:
> .
>    _log_priorities "${compadd_options[@]}" -- "${compadd_positional_arguments[@]}" -- "${log_priorities_argv[@]}"
> .
> which is similar to what zargs does.  Normally there would be a question here
> of how to escape a literal "--" in $compadd_positional_arguments, but for
> compadd specifically, I think the following is a satisfactory workaround:

Aside from the literal -- operand thing, there are a few complicating factors
i can think of with that:

1. Lower-level functions like _arguments want to automatically stick compadd
   options at the beginning of those functions' argument lists, so either they
   would have to be changed to pass the two --s (potentially causing issues
   for existing type functions that don't expect them) or you would have to
   include the --s in every argument spec you wrote.

2. Related to what you mentioned: Because compadd options go at the beginning,
   whatever is parsing the function's arguments needs to know all about what
   options compadd takes; otherwise it could get confused by an optarg of --.

3. Your type function has to figure out how to parse all of this, which could
   lead to a lot of noisy and possibly error-prone boiler-plate.

I think #2 and #3 could be solved by a helper function that does like a
two-pass zparseopts, but i'm not sure about #1, or about the path forward for
existing functions in general. (Though, one benefit of your first suggestion,
if we made sure to pick a letter that no type functions currently want for
themselves, is that it would be pretty straight-forward to just update them as
we go, and then maybe some years in the future we could deprecate/remove the
old way of doing it...?)

On 2 Nov 2019, at 00:54, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> I'll leave it to you to decide whether it's worthwhile to change
> _log_priorities from the version you posted.

I'm definitely open to it, just want to make sure it's something everybody
agrees with that'll work going forward.

On 2 Nov 2019, at 00:54, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Which reminds me: Shouldn't we mention _log_priorities in the manual, it
> being a new Type/ function?

I'm not actually sure. zshcompsys mentions a few type functions, but they're
only the really general ones like _files. Aside from some passing mentions,
there's nothing in the manual for stuff like _hosts and _pids and _signals. I
always assumed that was a deliberate omission, so i've never bothered with any
of the new type functions i've added.

dana