Re: GH:zsh-users/zsh-completions.

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

Peter wrote:
> The next question is more about how it interacts with the source
> distribution.  If it overrides it --- which is easy to set up, too ---
> there's no actual clash.  The question then becomes more one of bundling
> and installation.

Having it override it makes sense, though we would be reliant on people
doing the packaging to get that right. It might mean that the functions get
installed with a flattened directory structure. And some distributions
may take exception to the duplication of functions resulting in users
having to install both zsh and zsh-completions before compinit works.

There's also the question of what we do about Base/* Zsh/* comp* and the
some more borderline things like Unix/Type/_files, Unix/Type/(anything
else called from Zsh/*), bashcompinit etc. We'd also need to think about
the contents of compsys.yo.

> > And is there a simple way to provide this without separating the repository?
>
> That seems to me the wrong way to go.  There's no absolute need for
> completions to be in the same place as the source.  Either keep them
> separate and updated and installed separately (but potentially bundled
> with a source release for convenience) or keep them (or an stabilised
> version, as above) with the source, with the restrictions that implies.

I wasn't expecting this reaction.

I guess that if zsh releases continue to include the functions (or
at least the stable/decent quality subset) then that would allay the
concerns I have with such as separation.

The main disadvantage would be having to think about backward
compatibility with older zsh releases.

> If we expected lots more activity in the completion area, it might be
> worth thinking about another mailing list regardless of where the
> repository is.  Presumably there would be requests to cherry-pick
> people's changes that needed to go somewhere.

Perhaps, though I imagined pull requests being the main avenue for
cherry-pick requests. A mailing list can have value for more general
discussion and if someone prefers to send patches to a list then we can
easily accomodate that too.

> The disadvantage is this has overlap with the users list (is this

I don't think that would be too much of a problem.

> > and (2) at how many different places (github,
> > sourceforge, etc.) must I maintain accounts (and corresponding
> > separate git clones) in order to be able to contribute?

> It's easy to have additional repositories at Sourceforge --- the
> question is whether they can be set up conveniently for the desired
> model, which I don't know.  I think in any case this is easier than

I suspect that using Sourceforge would sort of miss half the point.
Sourceforge does support forks and "merge" requests but the idea is to
make it easier for casual contributors and these days that means github.
Maybe gitlab would be fine too.

Oliver

PS. My comment about oh-my-zsh in my previous mail might have sounded
dismissive but if the model proves a success, we might farm out the
promptinit, zle stuff in a similar manner. There isn't much activity in
terms of accepting pull requests at oh-my-zsh these days which is
something of a concern even if I have no interest in using it myself. No
shortage of pull requests however.