Programmatically loading completion for another command?

Programmatically loading completion for another command?

[Vorpal]

Hi,

I'm writing completion for a command that has an option like:

   --makepkg-args=comma,separated,list

where the comma separated list are arguments to the makepkg command.

I thus though I could use "_sequence _makepkg". Unfortunately this 
doesn't work if the user hasn't tried to tab complete "makepkg" yet.

Even more annoying _makepkg is defined in a file with a different name 
(_pacman) and the following #compdef at the top:

#compdef pacman pacman.static=pacman pacman-conf pacman-key makepkg

I.e. _makepkg is not the main "service" of the completion definition 
file. That file has a main completion function that dispatches on $service

* How do I trigger loading that file from my completion so I can offer 
completions to the flag --makepkg-args? Is it even possible?
* Or should I make a wrapper that calls _pacman and overrides $service 
locally?

Both of these approaches seem rather hackish. It would be nice if I 
could ask zsh: give me whatever is used to complete the command "makepkg".

Best regards,
Arvid Norlander

Re: Programmatically loading completion for another command?

[Bart Schaefer]

On Fri, May 27, 2022 at 9:30 AM Vorpal <zsh@vorpal.se> wrote:
>
> * How do I trigger loading that file from my completion so I can offer
> completions to the flag --makepkg-args? Is it even possible?

Something like this should work, no other wrapper needed:

  service=makepkg _sequence $_comps[makepkg]

In my install the service dispatcher function is _pkgtool not _pacman,
so using $_comps[makepkg] in the call to _sequence should get the
right one, whichever.

(Nod over to Daniel on the _services thread.)

Re: Programmatically loading completion for another command?

[Daniel Shahaf]

Bart Schaefer wrote on Fri, 27 May 2022 17:03 +00:00:
> On Fri, May 27, 2022 at 9:30 AM Vorpal <zsh@vorpal.se> wrote:
>>
>> * How do I trigger loading that file from my completion so I can offer
>> completions to the flag --makepkg-args? Is it even possible?
>
> Something like this should work, no other wrapper needed:
>
>   service=makepkg _sequence $_comps[makepkg]
>
> In my install the service dispatcher function is _pkgtool not _pacman,

There's two different makepkg(1) tools, it seems: the one completed by
zsh's _pkgtool file, and Arch Linux' tool, completed by
<https://gitlab.archlinux.org/pacman/pacman/-/blob/master/scripts/completion/zsh_completion.in>.

> so using $_comps[makepkg] in the call to _sequence should get the
> right one, whichever.
>
> (Nod over to Daniel on the _services thread.)

Re: Programmatically loading completion for another command?

[Vorpal]

On 2022-05-27 19:46, Daniel Shahaf wrote:
> Bart Schaefer wrote on Fri, 27 May 2022 17:03 +00:00:
>> On Fri, May 27, 2022 at 9:30 AM Vorpal <zsh@vorpal.se> wrote:
>>>
>>> * How do I trigger loading that file from my completion so I can offer
>>> completions to the flag --makepkg-args? Is it even possible?
>>
>> Something like this should work, no other wrapper needed:
>>
>>    service=makepkg _sequence $_comps[makepkg]

Thanks a lot! That works mostly as expected. There is one issue in that 
exclusivity in the argument completion of makepkg is ignored. Is there 
another option than _sequence that would handle that or do I have to 
invent my own thing that "simulates" the proper $words array (and 
possibly other things?) to the inner completion function?

>>
>> In my install the service dispatcher function is _pkgtool not _pacman,
> 
> There's two different makepkg(1) tools, it seems: the one completed by
> zsh's _pkgtool file, and Arch Linux' tool, completed by
> <https://gitlab.archlinux.org/pacman/pacman/-/blob/master/scripts/completion/zsh_completion.in>.

I am indeed doing this on Arch Linux, which is the relevant tool for me. 
As this is related to the system package manager and the tool I'm 
writing completions for is specific to Arch Linux, being able to support 
both is not really a concern (and doesn't even make sense).

I was more concerned for possibly future changes to how the 
pacman/makepkg completion was implemented breaking my completion script. 
However if $_comps is the official way to do it that significantly 
reduces the risk of that.

However it seems to me that a generic helper on the following form would 
a useful addition to the standard zsh distribution in that case:

_complete_for()
{
     service=$1 $_comps[$1]
}

(I don't care about the name, bikeshed it all you want).

I already included that (under a non-conflicting name) in my completion 
file for now as I need to not just complete makepkg in this manner but 
also makechrootpkg (which is defined in _devtools instead of _pacman).

> 
>> so using $_comps[makepkg] in the call to _sequence should get the
>> right one, whichever.
>>
>> (Nod over to Daniel on the _services thread.)
> 
Best regards,
Arvid Norlander

Re: Programmatically loading completion for another command?

[Bart Schaefer]

On Fri, May 27, 2022 at 12:58 PM Vorpal <zsh@vorpal.se> wrote:
>
> > Bart Schaefer wrote on Fri, 27 May 2022 17:03 +00:00:
> >>
> >>    service=makepkg _sequence $_comps[makepkg]
>
> Thanks a lot! That works mostly as expected. There is one issue in that
> exclusivity in the argument completion of makepkg is ignored.

It looks like _sequence assumes that whatever function it calls will
understand the -F -S and -r options of compadd (and won't fail if
passed them anyway).  Most of the uses of _sequence in the Completion/
tree are "_sequence compadd ..." and several others call functions
that eventually just do "compadd $@ ...".  For a completion function
that uses _arguments to have any hope of working with this, it would
at least have to include something like
  local -a compadd_args=( "$@" )
  ...
  _arguments ... -O compadd_args ...
and even that might not work in many cases, because _arguments doesn't
pass those options to every possible compadd.

A helper function for _sequence could be created to assist with this.

> However it seems to me that a generic helper on the following form would
> a useful addition to the standard zsh distribution in that case:
>
> _complete_for()
> {
>      service=$1 $_comps[$1]
> }

If you have a wrapper, you might as well go all the way:

_complete_for () {
  local service=$1
  shift
  local compadd_args=(${(q)@})
  {
    eval "function compadd { builtin compadd $compadd_args \"\$@\" }"
    $_comps[$service]
  } always {
    unfunction compadd
  }
}

That needs some work to avoid conflicting with other helpers that
redefine compadd, but seems to get the basic job done.