Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

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



On Tue, 17 Oct 2017 09:53:45 +0200
Oliver Kiddle <okiddle@xxxxxxxxxxx> wrote:
> 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.

Yes, duplication and incompatibility needs some thinking about.  But if
the source bundle is distributing a completion bundle in an identical
format to (but possibly rather different contents from) the more chaotic
completion set, it should be possible to arrange to pick one
or the other complete, and there's no absolute need to supply the
rapidly varying one at all in a distribution.  In fact, in some ways it
seems a bit pointless to make a package out of it --- it could just come
as a mechanism for keeping it updated.

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

That's what I kind of imagined.  But it would still be possible to do
subrepositories, wouldn't it?  The source could be set up by default to
pull as an anonymous user from git??b, which should work for anyone
setting up git (up to subtleties like needing to use http instead off
ssh to get through a proxy), with instructions about how to update if
you are going to change things.  That would reduce the problems Bart
noted.

pws



Messages sorted by: Reverse Date, Date, Thread, Author