Re: completion functions reorganisation and cleanup

[Greg Klanderman <gak@xxxxxxxxxxxxxx>]

Maybe 'Unsupported' or 'Unmaintained' iso 'Contrib'?

Greg

>>>>> On October 13, 2019 Oliver Kiddle <okiddle@xxxxxxxxxxx> wrote:

> 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@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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