From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id e0817c66 for ; Fri, 25 Oct 2019 14:33:28 +0000 (UTC) Received: (qmail 24913 invoked by alias); 25 Oct 2019 14:33:20 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 44870 Received: (qmail 22991 invoked by uid 1010); 25 Oct 2019 14:33:20 -0000 X-Qmail-Scanner-Diagnostics: from mail-s33.mailgun.us by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.0/25608. spamassassin: 3.4.2. Clear:RC:0(184.173.153.33):SA:0(-2.0/5.0):. Processed in 1.67144 secs); 25 Oct 2019 14:33:20 -0000 X-Envelope-From: bounce+ec8c1e.97dbd8-zsh-workers=zsh.org@klanderman.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at spf1.mailgun.org designates 184.173.153.33 as permitted sender) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=klanderman.net; q=dns/txt; s=mg; t=1572013998; h=Content-Type: MIME-Version: References: Message-ID: In-Reply-To: Date: Reply-To: Subject: To: From: Sender; bh=KrLR0zHUFHJmMq9fPZoER1pfoD2rddNOsuIAWCqGRFk=; b=ZOFxvdNyBIdI+yC7jR2t52RO64ULJPHpxCnT6Sd59kbhkt6c2Rz8+NDJfHF1uvbt2tmLE+1Q iu0wEJQkgqfr6OSDYZO2koOSVJt3XLoEXesaH2li7hqP5NIvBhkszMTwKU1OfeDz3wOf8bq3 Dt/R/0fcKrvxvWkFw6aKnWoxUN0= X-Mailgun-Sending-Ip: 184.173.153.33 X-Mailgun-Sid: WyIwZjNkNyIsICJ6c2gtd29ya2Vyc0B6c2gub3JnIiwgIjk3ZGJkOCJd Sender: gak@klanderman.net From: Greg Klanderman To: zsh-workers@zsh.org Subject: Re: completion functions reorganisation and cleanup Reply-To: Greg Klanderman Date: Fri, 25 Oct 2019 10:32:10 -0400 In-Reply-To: <12231-1570957542.707781@D0H0.XUEh.rSze> (Oliver Kiddle's message of "Sun, 13 Oct 2019 11:05:42 +0200") Message-ID: <874kzw99qt.fsf@lwm.klanderman.net> User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.24 (linux) References: <60418-1570439627.075514@NIya.iyMV.mGw3> <893E5C01-39AA-41CF-9C5D-C780A0A1B149@dana.is> <12231-1570957542.707781@D0H0.XUEh.rSze> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Maybe 'Unsupported' or 'Unmaintained' iso 'Contrib'? Greg >>>>> On October 13, 2019 Oliver Kiddle 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 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 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