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,FREEMAIL_FROM,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 f062ce2a for ; Thu, 25 Apr 2019 08:01:54 +0000 (UTC) Received: (qmail 7835 invoked by alias); 25 Apr 2019 08:01:39 -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: 44252 Received: (qmail 19650 invoked by uid 1010); 25 Apr 2019 08:01:39 -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.101.1/25426. spamassassin: 3.4.2. Clear:RC:0(205.235.26.22):SA:0(-1.7/5.0):. Processed in 2.127273 secs); 25 Apr 2019 08:01:39 -0000 X-Envelope-From: SRS0=Bagk=S3=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=1556179256; bh=nHVSNfIEZ4HrY4UwCgPjdTUE2enGul8L7LHi0yGetSs=; h=From:References:To:Subject:Date:From:Subject; b=NAl1AkM4vcNe+uc2hOtGMJWFXcmJqCJTPLbjEKmdnXhqR/qnbvIJexge824hQCMysY689qc/SLkxX5i0GKYCZ6yPmVM2H5I3amCTzMGdbHQo6HrdxMEgBkM5JdSY6DOBdh1YmZyUI9vqXqop/wNyvZSK3vonkF3j27e/9kGI9BTG3OrgupWWDGKkNIOvi6U7Jkr8a37FX1obt6rGsbfswGn1jXHX+w1gn/nAVWJIkdfpmBlpKCK0CiLiZdKz0KULzO4ibiB0is47Fi12mAXiwqAyFV+edq4hrfCtcudHXpou3EejLkggHTzG91UmSzxshFpbE+QGtD0da3tm7C0Kww== X-YMail-OSG: kaZwNekVM1mULLBpzIr9IIHEFPD8pV7T5dlC8yhE5U_XODeZNMWE1_iT_aT0AfW OEe795zb7Lpq2nIhzMCI6g2ByoswtzzsV5SxJS_Hk2eepzUtFArOJBYd8ZvpJe8HpjYdg1vCO4.m _OJ_l2gWMdlr5erR9BwyrurWORHPU0orBzJGacM_BTxFg2dCK8mlJvoXm3IalnuIHVca8k4zyi4E X8MDBZX7ZuDrGoJPppouyYbym6f2TM6PmOMa4sGQflYNjgU3L_ruo69RSWCBEE3oi089hAf1UmLp rPeANUGF1PT5bopraqUCHdgQphD.aIwQ6dx_rAgxcGKKBWLTT1RAzWFJz_hVQUyn0EX8HcvoRl50 ZJyPM9.gWSTpDsU.CzyIomb0gR_FRfzSsAU4ldC2rBvRFIq6rCjnzmqpoOnnpoXFINuqk5pAT7vY vvqwOKhI_U4hCfxRAkYbpsvLOnLkfclJaKNL.SYBDx4_QchXH1VqIqx2XOFVD4.CRID6P1wu8FBi Wg_jpyaBHi558U2CyZb6OFkHr.BwObITPKopA_Xd7e0SIasU7OD2pJQji0Zxb8H2yt4HiQjpInVI akZRFlM6mZjw2UzlW1PHPplRUl1Lk8.bokVgLr5YCTcL5.m7Gl8pHX0LaL99DJuDoQ1uf9FmWIPz Ufo141ebiD3_MMoupWNjMnNao4KwOJrtY1z0IZXcndtqkqVUugS6cuegs7iKHJ.WhaFnhCTzqKcc _E__.0P1FQGfHhe_TCgfJHirCxj2.ZuDfY7NJLUfNlal4OUJvS.drdm5oZeJp.ZQCnU77RvvH4J9 sZ4MM1kJbHatbhLHwnwBEVTYuuUEV55hmey2vPuADI.1QcljJUm2fhJKa9CbKEZRg_Co3rR0E9Tm KVLxmN2VQrMsZB1xinRh5GX1SRJkeuuhXxtAL_1KDz3Ao1yUg8IL87c7Qx_a_4LZrVM89n8HY7wE dx9w0pG5LM4_i03E3z2UMtuTOAHwQyNi9TfcOXYUOM3eGzQlrp0ATqZ8nYWRPvJUmeFOxD.Hmqd0 WMWHU.VckZqnDurA6Q6gZwqXE3RH4AIWb8pcnwTgxQuZGwrXeCkGJ7w-- In-reply-to: From: Oliver Kiddle References: To: Zsh workers Subject: Re: [PATCH] Completion: Fix use of -A and -S options to _arguments MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <41572.1556179253.1@hydra> Content-Transfer-Encoding: 8bit Date: Thu, 25 Apr 2019 10:00:53 +0200 Message-ID: <41573-1556179253.473258@hVwb.tmqp.nbJZ> dana wrote: > Patch #2: Make use of the -A and -S options to _arguments consistent in these > functions. > > I can't think of any reason you would ever *not* want to use -S for these, but Generally, it's purely a question of does the command-line parser for the command in question allow options after ???--???. > someone did go out of their way to make it conditional in _ln ??? if anyone > knows why that might be, please tell me. I went to check on the assumption that it was likely to have been me but it wasn't. Given that it is done conditionally for GNU, I'd guess that ???-S??? got confused with ???-A "-*"???. In general, GNU tools tend to allow options after other arguments while it is less common elsewhere. -- is more widely recognised. > Aside: The use of *:: in _ln and _rm prevents those functions from offering > options after an operand has been given. I can't recall if this behaviour has > ever been discussed here before ??? is there a way to deal with it? It is behaviour I was aware of and know that I thought about it when I was making changes to the comparguments. There were at least a couple of such oddities that I was reluctant to change for backward compatibility reasons and there may have been reasons for it that are apparent when you dig into the code. In combination with a state, it isn't really fixable. I don't remember if it has been explicitly discussed as such. Oliver