Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: GH:zsh-users/zsh-completions.
- X-seq: zsh-workers 41895
- From: Eric Cook <llua@xxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: GH:zsh-users/zsh-completions.
- Date: Sat, 14 Oct 2017 12:49:48 -0400
- In-reply-to: <CA+mcLN6ZuZ_AoKvfbceupZVg9+1btDg7NG=bGRUMDxwzLs5bcg@mail.gmail.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <7240.1507973844@thecus.kiddle.eu> <CA+mcLN6ZuZ_AoKvfbceupZVg9+1btDg7NG=bGRUMDxwzLs5bcg@mail.gmail.com>
On 10/14/2017 10:44 AM, Julien Nicoulaud wrote:
> - I believe the release rythm of zsh (~once a year) is a bit too slow
> for completions. We do ~monthly releases, and I think most users importing
> it via a "plugin manager" actually directly use the master branch, which is
> fine IMHO for completions. By the time a compdef lands in a zsh release, it
> can be already obsolete or need bugfixes. I think this is the biggest point
> for having compdefs in a separate repo than the shell itself.
The release frequency cuts both ways, if the command in question changes frequently,
with the completer keeping in sync and an user continues to use an older version
of the command. they would be presented options that doesn't exist yet. That
would be my biggest point for trying to push those completers into their project's
source tree. While it would awesome if the developers attempt to keep it up to date
there isn't an reason why the original contributor of the completer couldn't help with
that effort too. But once an release of project foo happens and appears on your
os, you have an snapshot of the options supported by that release. bug fixes to the
completer would work like any other bug fix to packages on an os.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author