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=2.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,MALFORMED_FREEMAIL, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE,RCVD_IN_DNSWL_NONE autolearn=no 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 210ff7bb for ; Sun, 13 Oct 2019 09:06:35 +0000 (UTC) Received: (qmail 367 invoked by alias); 13 Oct 2019 09:06:26 -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: 44831 Received: (qmail 28899 invoked by uid 1010); 13 Oct 2019 09:06:26 -0000 X-Qmail-Scanner-Diagnostics: from park01.gkg.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.0/25598. spamassassin: 3.4.2. Clear:RC:0(205.235.26.22):SA:0(1.7/5.0):. Processed in 1.985147 secs); 13 Oct 2019 09:06:26 -0000 X-Envelope-From: SRS0=udwr=YG=yahoo.co.uk=okiddle@bounces.park01.gkg.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at bounces.park01.gkg.net designates 205.235.26.22 as permitted sender) X-Virus-Scanned: by amavisd-new at gkg.net Authentication-Results: amavisd4.gkg.net (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1570957545; bh=6z7uUz4RH2y4EVp7W5bvwwpbKwCxalVg/QSPQUDH3WM=; h=From:References:To:Subject:Date:From:Subject; b=HVPiqY4VSyUBho/E2hy0dcTZHQTylxj4kTkXzm8dCFo/NcIBbpwJomTssRetLNafn+mOp5D/ZRJgRGo5B5omRezP+C7yStZzhA1expANMmm8buaC72WyM5kexNcUqsUtQCzNwimHIKU+4VvKPKnJDld5KVvcTJ2uik5+9DMigC2/1nbICYE1FH2+lY8QmOMRIwzNmis5DV4gjN/+5dstm+bMh0KULALawDEu3KslIh2+hk6MZYyYicKtoUiKL3SryN+c2OAEmOpj25eJSPuEFRDYj0DNguIxXuYul6/hAokV2tPTNjo/8laHPBrILRUMYk730AK1f0XTkt2LXF9KDQ== X-YMail-OSG: 8QZZphsVM1kjNf4tpR4khMnEZllSRS764gdNI7HJsbWwzMEqopB5CRkG3ep8gJM XJM4GjeKWXbEJOiQxKXWmRGk6OSFEpd0dUe3EcLKbNzg5S9nOeLuaTMXNX5HYBsSjRH5wNqocA8n dSERBeceplqfqEv.da7MYVZ7jJ23MduAfWSa1vx13R2aBdv7w.CP3ohZgyid88I1HJyj4FwKefwS 9v55x7Ny2Yu8_yVZMp6bCrCPjpaHrA2f8Gle4CYDUGZt5enw70mKHdUG_kujcFbS6K_QRde28pRV pROHCba6Lo_dWeTealtKKCXWIjmf2mS_0cO9TCNq535kU8j_60boHa1QR_d8CGLuaN13r4I4LQv9 .jNHekk_jMSRrGol8Q._z5yyqm4IpA4T60gsRnFYUd1OuTKKShTBXWNF3893r8QUmqlhvaLNC_4U lejdff_3zKdrmrer5NYaKu5RfdOnu0plplpNNFzO6zMM9SXySyI7vvF_cZtyL8qVWervT080_JTS oV1ysdbNBKtU8nmXVeHfD4IoK5G5o8OxX_u2cJ9ov_sllsm9OyOwiVwcb.XTvmRSHtXaO.9AyoA2 hFYxDi71e5Zo0fAHHr7FkhtHwoT.KXl1Czx6t3oLvnxxFRczsSCfpIyAZyFm0SJYZ_6ij.0xtSYi 1jHWNdmJxg6ZcQvKsj_1r.X5R4N2p.Ovkk.rtRsYIskyVGLF24lsvdUCbKYsGszZWMSvMLdxCcpu 1lw56KdUekdrREKX5Ahcdknm.rFN.AKn1rdUaHoYSCYJUFn3WtJhcXm4PlfkiV4lbSKXmhPv7REn HLl9gTn41GT5KHo4jRrytmTInWO5UsRl8YhdYtLEUOesQw9mR_DCEsYCu_r6dmoyCBWngaAQEauR 4ubugAxgPccaujBCALl0ZJYROYakXxjH6nCBvzc3QcDWfGdxHN9CmJopT8L2_KjaBEhMNSv0gOvO KheiDHvBH4YmcJEivZIiEGmZ8eQm_qW6CnvozHmPAuorbBmQWS9ojd72KER_MuM0M59i.zliGwHS toLEv3VlPN7fhfVTIgpCNSjfF_RF6IcP6uXQIxIfGQMfH192cvaW7RDVjao4DEXv4dZu_4GLuWO7 y_mKuhPuDf6ysxgCGbWYs0kobCXF_QImVcn6R3poO1iX9TkB0JVdDPKmdO3Wv.oNbtefWgVubq0E BQnCDRP2zdUp814Tg2beenYksE7EbIMN.MtYzLhs28I5xqMfZrhzBYyjwRIEYgtKeeDWYmP_XEng 4G.VxGEinFVdqvJ7_lLyOjl.9BfPoX6YurAZ6xbihgIIFqx2Y cc: Zsh workers In-reply-to: <893E5C01-39AA-41CF-9C5D-C780A0A1B149@dana.is> From: Oliver Kiddle References: <60418-1570439627.075514@NIya.iyMV.mGw3> <893E5C01-39AA-41CF-9C5D-C780A0A1B149@dana.is> To: dana Subject: Re: completion functions reorganisation and cleanup MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12230.1570957542.1@hydra> Date: Sun, 13 Oct 2019 11:05:42 +0200 Message-ID: <12231-1570957542.707781@D0H0.XUEh.rSze> 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