completion functions reorganisation and cleanup

completion functions reorganisation and cleanup

[Oliver Kiddle]

We carry a few completion functions that have their own licence terms
listed in their headers. In some cases packagers need to jump through
hoops to accomodate this. There are probably also cases where they ought
to but it has gone unnoticied. I'm not especially keen to be a stickler
for licences but we might be doing some packagers a favour by making a
clearer distinction.

How about the following patch to add in an extra directory for
completions that will NOT be installed by default? A configure option is
there so tweaking of config.modules is not required. I have named the
directory `Contrib' which isn't a particularly accurate description of
its contents. If anything they are not contributed but the name might be
a good match to expectations for the contents. Any better ideas would
be good, though we should perhaps first decide on what the criteria
should be for being moved to the non-Default-installed directory. Other
criteria that come to mind are:
    - low quality,
    - poorly maintained,
    - obscure command
    - dead upstream

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.

Differently licenced functions are: _hg, _qdbus, _osc, _darcs and _zypper. 
_hg is carried by upstream so I would suggest we just remove it. The same
applies to _notmuch (and possibly _git-buildpackage - that needs verifying on
Debian). _osc and _zypper would be good candidates for trying to persuade
upstream to take them.

Where the upstream projects are dead, there may be users around long
afterwards so I'm not sure I would be too quick to remove completions.
They also have the advantage of being stable and not breaking our
completions. But functions for dead projects, that I would suggest
removing include:

prcs - this was fairly well known 20 years ago and the completion is
       good quality (by Sven) but appears to be very dead
vux
uzbl
flasher
elm
tpconfig
sablotron - not sure, sources still there on sourceforge but not packaged
raggle - website only down since Feb 2016, not in Debian

aap, cplay, totd also seem to be dead but still are packaged on either
Debian or FreeBSD so should perhaps be kept.

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 thing that really comes to mind for the "obscure command"
criteria is mysqldiff. Sadly for "poorly maintained" there are quite a
few.

Oliver

diff --git a/INSTALL b/INSTALL
index cf70893a7..9edcc63f6 100644
--- a/INSTALL
+++ b/INSTALL
@@ -479,6 +479,12 @@ want; in particular, the zsh/complete and zsh/zftp modules are of much less
 use without the associated functions.  The functions listed with zsh/zle
 are not used by the editor unless you explicitly load them, however.
 
+Some of the completion functions have been separated out into a `Contrib'
+directory where they are licenced under different terms to the rest of the
+zsh distribution - see the headers of individual files for details.  These
+are not installed by default but you can use the configure option
+--enable-contrib-completions to include them in config.modules.
+
 You can also use the configure option --enable-function-subdirs to allow
 shell functions to be installed into subdirectories of the function
 directory, i.e. `Base/*' files will be installed into `FNDIR/Base, and so
diff --git a/Src/Zle/complete.mdd b/Src/Zle/complete.mdd
index 77e33504d..93e9084dc 100644
--- a/Src/Zle/complete.mdd
+++ b/Src/Zle/complete.mdd
@@ -1,8 +1,7 @@
 name=zsh/complete
 link=either
 load=yes
-functions='Completion/*comp* Completion/AIX/*/* Completion/BSD/*/* Completion/Base/*/* Completion/Cygwin/*/* Completion/Darwin/*/* Completion/Debian/*/* Completion/Linux/*/* Completion/Mandriva/*/* Completion/Redhat/*/* Completion/Solaris/*/* Completion/openSUSE/*/* Completion/Unix/*/* Completion/X/*/* Completion/Zsh/*/*'
-
+functions='Completion/*comp* Completion/AIX/*/* Completion/BSD/*/* Completion/Base/*/* Completion/Cygwin/*/* Completion/Darwin/*/* Completion/Debian/*/* Completion/Linux/*/* Completion/Mandriva/*/* Completion/Redhat/*/* Completion/Solaris/*/* Completion/openSUSE/*/* Completion/Unix/*/* Completion/X/*/*'`if test x$enable_contrib_completions = xyes; then echo " Completion/Contrib/*/*"; fi`
 moddeps="zsh/zle"
 
 autofeatures="b:compadd b:compset c:prefix c:suffix c:between c:after"
diff --git a/configure.ac b/configure.ac
index 8a2664ed2..8c8790767 100644
--- a/configure.ac
+++ b/configure.ac
@@ -344,6 +344,9 @@ else
   FUNCTIONS_SUBDIRS=no
 fi
 
+AC_ARG_ENABLE(contrib-completions,
+AS_HELP_STRING([--enable-contrib-completions],[install additional completion functions]))
+
 ifdef([additionalfpath],[undefine([additionalfpath])])dnl
 AC_ARG_ENABLE(additional-fpath,
 AS_HELP_STRING([--enable-additional-fpath=DIR],[add directories to default function path]),

Re: completion functions reorganisation and cleanup

[dana]

On 7 Oct 2019, at 04:13, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> How about the following patch to add in an extra directory for
> completions that will NOT be installed by default?

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...)

'Contrib' is a slightly ambiguous name to give that entire category of
things, but i can't think of anything better off the top of my head.

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.

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.

dana

Re: completion functions reorganisation and cleanup

[Oliver Kiddle]

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

Re: completion functions reorganisation and cleanup

[Greg Klanderman]

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

Greg

>>>>> On October 13, 2019 Oliver Kiddle <okiddle@yahoo.co.uk> 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@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