Re: completion functions reorganisation and cleanup

[Oliver Kiddle <okiddle@yahoo.co.uk>]

dana wrote:
> For whatever it's worth, it sounds OK to me. I think all of the potential
> criteria you listed (different/unclear licence, low quality, obscure,
> unmaintained) make sense. If anybody really wants any of those functions, they
> can sort through it for what they need, so the only concern i would have is
> maintenance; it wouldn't be great if it just became a 'junk drawer' of random
> unvetted nonsense. (Though, as you hinted, in some cases it's already like
> that...)

Thanks for the comments. I don't really see this as having much impact
on the issue of maintenance other than us being more explicit about
which functions aren't maintained. On a positive side, we give users the
choice between quality only and greatest breadth of coverage and maybe
it'll provide encouragement for other people to improve them.

> On 7 Oct 2019, at 04:13, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> > We might also consider pulling in the whole zsh-completions project,
> > perhaps updating periodically via git-subtree rather than with a view to
> > replacing it.
>
> One potential issue i can think of with this is that there are some duplicates
> (or rather divergent implementations) between zsh-completions and the main
> repo, which could lead to some confusing configurations on systems that have
> both installed.

I don't think that's the case anymore. They have a policy of removing
any function that duplicates either one in zsh or one upstream. Even
where theirs is better. zsh-completions having it's own directory at the
end of $fpath may also improve things if duplicates do occur.

subtree merges should allow us to be picky but that also involves some
effort. A git submodule is also tempting which avoids that effort
but imports their directory structure - a `src' directory instead of
`Commands' and `Type'.

It might also create a simpler situation for packagers who might
otherwise be tempted to put the Contrib directory into a separate
package that user's would need to choose to install - there's no need
if it is just the same as zsh-completions.

> On 7 Oct 2019, at 04:13, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> > Should we just remove these? Or perhaps announce for 5.8 that they will
> > go in 5.9? Any individual objections, or additions.
>
> The only one of those that i've ever even heard of is elm. I think either of
> those plans is probably fine; it's not like we couldn't re-add in a point
> release if someone complained.

Ok, if nobody complains I'll go ahead and remove the following
completions for dead projects:
  _prcs
  _vux
  _uzbl
  _flasher
  _elm
  _tpconfig
  _sablotron
  _raggle

And the following for which upstream have their own completion:
  _notmuch
  _hg
  _zathura

Otherwise, it'll take a bit of time before I've sorted through
completions to see which might qualify for moving.

Oliver