[Pkg-zsh-devel] Bug#717002: zsh: Update for git-buildpackage completion

[Frank Terbeck]

Hey,

with my pkg-zsh hat on, here are some thoughts:

Guido Günther wrote:
> On Mon, Oct 28, 2013 at 03:50:33PM -0300, Felipe Sateler wrote:
>> On Mon, Oct 28, 2013 at 2:22 PM, Vincent Bernat <bernat at debian.org> wrote:
>> >  ❦ 15 juillet 2013 23:27 CEST, Felipe Sateler <fsateler at debian.org> :
[...]
>> >> Unfortunately my completion foo is quite limited, so they are not as
>> >> good as they could be (multiple pq commands are allowed;
>> >> cannot detect when to require a dsc or a package name in import-dsc and
>> >> others).
>> >>
>> >> I still think the result is somewhat useful.
>> >
>> > It is working fine for me. Maybe this could be shipped with gbp instead?

The three options are: a) Shipping the completion separately (which is
the worst possible solution; b) have it shipped with gbp; and c) have it
shipped with zsh.

Upstream zsh welcomes additions to the pool of available completion
functions. Debian already has its own sub-directory within that pool, so
adding ‘_gbp’ to that pool would be a natural thing to do. The advantage
of that would be, that knowledgeable eyes at least scan the code you
submit. On the flip-side, you'd have to regularly sync your version of
the completion with zsh's repository, because nobody gains anything from
massively outdated completion functions.


>> GBP maintainers, would you mind adding this file to the gbp package?
>> It's a start for a zsh completion, but it is already useful.

If you choose to ship ‘_gbp’ with gbp itself, the advantage would be
that you'd ship a completion that always exactly matches the command
line interface of the software - if you keep the completion up to date.

Debian's zsh package provides an $fpath entry for other packages to drop
completion function files into. That entry was introduced to
specifically support completions that are shipped with the target
software rather than with upstream zsh. That directory would be:

  /usr/share/zsh/function/vendor-completions

For completeness, if you want to ship non-completion functions, the
directory to use would be:

  /usr/share/zsh/function/vendor-functions


> If somebody submits a patch I'd be happy to. I do wonder why you
> hardcode the options though instead of parsing it from the command's
> --help output?

The idea is usually to provide context-specific completion depending on
the option-set. That's why you often need to name the options anyway
since the following code-paths depend on them. By context-sensitive, I
mean for example, with git's completion, "git add <tab>" only shows
files that are not .gitignored and either not tracked yet or contain
changes. To identify that context, the completion needs to know about
‘add’.

Those are my 2¢.

Regards, Frank