From: Greg Klanderman <gak@klanderman.net>
To: zsh-workers@zsh.org
Subject: Re: completion functions reorganisation and cleanup
Date: Fri, 25 Oct 2019 10:32:10 -0400 [thread overview]
Message-ID: <874kzw99qt.fsf@lwm.klanderman.net> (raw)
In-Reply-To: <12231-1570957542.707781@D0H0.XUEh.rSze> (Oliver Kiddle's message of "Sun, 13 Oct 2019 11:05:42 +0200")
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
prev parent reply other threads:[~2019-10-25 14:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-07 9:13 Oliver Kiddle
2019-10-12 7:46 ` dana
2019-10-13 9:05 ` Oliver Kiddle
2019-10-25 14:32 ` Greg Klanderman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874kzw99qt.fsf@lwm.klanderman.net \
--to=gak@klanderman.net \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).