[Pkg-zsh-devel] Bug#962135: Bug#962135: Bug#962135: patch for bugs 962133 and 962135

[Daniel Shahaf]

Vincent Lefevre wrote on Wed, 03 Jun 2020 21:14 +0200:
> On 2020-06-03 20:28:11 +0200, Axel Beckert wrote:
> > Daniel: Would you review it for upstream inclusion?

Sure.

> Note that this is not documented, so I thought that this was just
> internal, and 3rd party code should have its own functions.

As far as completion functions go, I'd err on the side of considering
the comment at the top of _deb_packages to be API documentation,
notwithstanding that it's only a top-of-file comment and not in the
manual.

Furthermore, I'd rather not remove code just because it's currently
unused in zsh.git.  The completion system — especially the Type/*
functions — is an API, not a blackbox.  Does the function proposed for
removal answer a useful question?  Might third party tools (or even
people's zshrc files) be using or in the future use that function?  The
function has already been written (and debugged, etc); how likely is it
that if we remove it, someone will have to reinvent the wheel?

So, I agree with Axel about the _deb_packages part of the patch.

As to the _dpkg part of the patch, first of all, it's incomplete:
it removes the "listfiles" case but not the code that sets that value.
Once the latter is removed too, the function will then display a single
asterisk to the user instead of an actual description.  And with _that_
fixed, there'll still be the issue that, where possible, it's better to
generate completions than to just tell the user what type of thing they're
supposed to type in.  Incorrect or incomplete code should, if possible,
be corrected rather than axed.

So I consider the _dpkg part of the patch a helpful debugging aid, but
I'm afraid I don't think it's ready to be merged as-is.

I'm not overly familiar with the aptitude/apt/dpkg/dselect hierarchy of
semantics, but in general, completion should (1) offer everything that
the command would accept, (2) not offer things the command won't accept.
That's in descending order of priority: it's usually better to offer too
much than too little.

HTH.  Let me know if you have further questions ☺

Cheers,

Daniel
(no pun intended)