Re: What is the _services array?

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

Peter Stephenson wrote on Fri, 27 May 2022 13:01 +00:00:
>> On 27 May 2022 at 13:45 Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
>> Peter Stephenson wrote on Fri, 27 May 2022 09:52 +00:00:
>> >> On 27 May 2022 at 10:09 Zach Riggle <zachriggle@xxxxxxxxx> wrote:
>> >> I recently found the _services array by playing around with "typeset -H"
>> >> and there's some neat stuff in here, I'm just not sure what it's for or how
>> >> to make use of it.
>> >> 
>> >> Any ideas?
>> >
>> > This is the backend DB for the feature described in the zshcompsys manual
>> > in the paragraph that starts
>> >
>> > "Each  name may also be of the form `cmd=service'.  "
>> >
>> > You should be able to be configure it by the means noted there.
>> 
>> It's not documented, though, which means it's liable to change
>> incompatibly without notice.  If that's not the case, then we should
>> document that function :)
>
> My inclination would be that if Zach finds things he can do with _services
> that aren't part of the existing interface,

I can't comment about $_services, but here's two things I've used
$_comps for:

1. Providing a fallback completion function:

       _has_completion() { (( $# == 1 )) || return 2; (( ${+_comps[$1]} )) }
       _has_completion ag || compdef _gnu_generic ag
       
   This lets ag(1) be completed by «_gnu_generic» if nothing better has been
   registered.

   The helper's completion function is also relevant:

       compdef 'compadd -k _comps' _has_completion

2. Listing commands that don't have completions:

       () { print -rl -- ${(k)commands:|argv} } ${(k)_comps}

   I haven't used this before.

3. Invoking a specific command's completion.

   I use a git() wrapper function to implement a «git cd» command.  To
   complete that, I defined a «_git-cd» function.  That function does
   «__git_worktrees "$@" || ${_comps[cd]} "$@"».

I don't know how to implement the first two via the API.  The third can be done
without ${_comps} using «(( --CURRENT )); shift words; _normal» (on the RHS of the «||»).

> we should probably extend the interface rather than expose the
> implementation detail.  But, of course, it's horse for courses.

On the one hand, +1 to abstraction.  On the one hand, since special parameters
are a thing, exposing an assoc parameter doesn't _necessarily_ mean we
have to use an assoc under the hood forever.

Cheers,

Daniel