From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,MAILING_LIST_MULTI,MALFORMED_FREEMAIL,RCVD_IN_DNSWL_NONE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 15324 invoked from network); 26 May 2020 07:57:25 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 26 May 2020 07:57:25 -0000 Received: (qmail 5113 invoked by alias); 26 May 2020 07:57:12 -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: 45919 Received: (qmail 3484 invoked by uid 1010); 26 May 2020 07:57:12 -0000 X-Qmail-Scanner-Diagnostics: from sonic307-53.consmr.mail.ir2.yahoo.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25821. spamassassin: 3.4.4. Clear:RC:0(87.248.110.30):SA:0(-0.9/5.0):. Processed in 2.039495 secs); 26 May 2020 07:57:12 -0000 X-Envelope-From: okiddle@yahoo.co.uk X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.mail.yahoo.com designates 87.248.110.30 as permitted sender) X-YMail-OSG: DDDnIQ4VM1kEXVc_EIZptPoJxeDFAz2ChSjWrNxnnPggv8JxVRe4Ym1YHUM8qYR kmq0jO2QVhTK1da7H2BnBGrmi3p.avhX7_.o9r0fEqlyI.nx_tWQDfpyMD_dzg7DcKTYAQJhViNr BNk._i8UHCnEN5wNUFM4tl83qhRGIZqPzsRiw7wQGCSR7Hwintz0CW2AzO2NkTbqPoXJhMX86fun FcfQ_1yJr3irvnM4rm6kvwbcq50nHMiwIzzJEtS3Y5c2qr8w_bsfey6oBSNZR9Yzs3Ac1i6oJZ1Y LAfcBoQjk_MnaOjIM9Z5bbKuEQzT03EpTkDgquPBBSiEprW726ADE8q7r_ZAcefsoAoSFHCj6svC kmurYzn9W5T5nXZnnj9g7vIc6VoLI1l8KA8G_avuxB.d.369o7EoPn2KJJaMHCsRWnXBJJe6pLXd mHe7ZhSy7FWdCLFVpy5y6SCakCCYxFY.XVlawtY_jXx0dpAD2ABU5LpV4LO7hW_O17M6kow5XBiN hNKu6QGAF_L42c3k6JcBEuA2xYSc_6RTv34vLWVYbQMbgE24nYpbiUhYc9J9sLDwGZXRnoCfMwEw 66Z0LFeA3RBoXAhkmLwBtSFIi5Pxb76NFz0i3S.tlpi7dbCJyYhb6ke8CzUCTAgc5JVUDuu5JfPf nxGuqD5.7b8IbUrPoWVI9HUo_8PxGdE9_MDfzWKLRH4_se5mTXG2LqNPwA29lyP_M0nO1SiOXs3F NiQ2SfAte2NkdvyKP3xZB19kLnLjPTb1wv5RywteBwvD6WmIrPNdVCqPFYJYasli2tx_O7s.80Fv HdWthyDq88rQl3fzi1YwdOQkHpGx0uewWzRJrWXnI8rYsH_.9M07VZ8BKZnpJ0Rvi_LZlWvOR4L4 cFTS_2tFq5LOavc1YljnUyLk9tZEpvOKL0j57Y4m.jhR.l51bcIh8WS1y_ElKZGJdKyv5S.070uj RL6xwlVmB9UQuxRTitL2VG.QbxNkP83qYhnDscPD.ht2drGYilvJjmORlBsFpL6nSdStQBIcFJc9 NAr_TR_3IaCbl02RU53RXAfN_iHBwtt2jk_RLqo7J2Lxkh0JiW4.p9Kv65BRvLsXLevpPLOr7Rjx UdyRtrPq9qS6Ecqo5pIOwOZt5da9C3ZdRnGTCraTpA8jnAiIY1T_rkkHyBv2XM5DZMCP8dekFp3h 0Ui9QdHBkT_9ytvUFSuqE2e8OTAXcEJFXDE4R9KWh89Wic9OruRmiIYAZnd_ekTcf2hUJ_nPR7yF Zof328edjZMFPHZYzdjv.ooGvCUCa6oWjOXXZb83oxw7ozPnoWV0Q.k91hw3wUUa.QTOCCI.cnUD L_O1nR5wpYXJXr8fHYwgzm1_KOSskmXjEsreWfuRN06AzaRpYuNXyLbZdCEqo3OYaPdxtrQwo7ia AWpd.H.0rTBgSy2wwGyc- cc: Zsh hackers list In-reply-to: From: Oliver Kiddle References: <20200523022807.08f3ba45@tarpaulin.shahaf.local2> <71744-1590427742.474587@WgsI.yCFx.n5vu> To: Bart Schaefer Subject: Re: _arguments optspecs (was Re: Editing the history in the shell) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <89017.1590479786.1@hydra> Content-Transfer-Encoding: 8bit Date: Tue, 26 May 2020 09:56:26 +0200 Message-ID: <89018-1590479786.775145@0MSv.YwO6.IDjS> X-Mailer: WebService/1.1.15960 hermes_yahoo Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Bart Schaefer wrote: > zed -f _zed -x2 > > is not accepted by zed itself. Yes, -f changes the interpretation of the normal arguments rather than taking an argument itself. I assume that's also true for the new -h. > > ... I try to avoid leaving the > > number out for any spec that is the target of an exclusion. > > Do I understand, then, that you would have written the original > '(- 2):file:_files' \ > '(1):shell function:_functions' > as > '(- 2)1:file:_files' \ > '(1)2:shell function:_functions' > ?? I can see where that might have puzzled me less. Yes, exactly. > > > The second spec offers -h followed by "history file" as the argument > > > to -h, and won't offer -f or -x or a first non-option argument. > > > > Yes. And in excluding the first non-option argument, it will move on and > > offer the second one in the first position. So you get "history size" in > > position 1 despite it being labelled as 2. > > OK, that explains my confusion then. Why does it do that? If I > wanted to indicate that _arguments was NOT meant to "move on and offer > the second one in the first position", would I have to write > '(1)2:history file: ' > ?? Or is there a way to say "exactly the Nth position" without also > specifying the (N-1)th position? I don't think that's possible. And in practical reality, I don't think it would be especially useful. I guess the answer to why it does that is because it is useful. Note that exclusions apply to later arguments only so excluding (1) from 2:history␣file is meaningless. > > I can't find any arrangement of words on a command-line that gives the > > argument after -h as being anything other than "history file". Neither > > is it being counted as one of the non-option arguments. > > "count the argument after -h as a non-option argument" and "offer the > second one in the first position" have equivalent results from the > point of view of a black-box test. I just didn't know how to explain > what I was seeing. Yes, I can see that would be the case. The tag (as indicated by _complete_help) will be different, however. > > There's a list of possible states. In each state, individual specs > > are disabled if an option is found which would disable it. If you > > exclude positional arguments, subsequent ones become active at an > > earlier position. > > Is that "subsequent" part stated in the doc anywhere that you can point to? No. The only reference to putting numbers in the exclusion lists at all is an example giving `(-two -three 1)`. > > '(-h 1 3 4)-f[edit function]' \ > > '(-h 1 3 4)-x+[specify spaces to use for indentation in function expansion]:spaces' \ > > '(-f -x 1 2)-h[edit history]' \ > > '(- 2 3 4)1:file:_files' \ > > '(3 4)2:shell function:_functions' \ > > '3:history file:_files' \ > > '4:history size';; > > I would never have thought of that, because without the implicit > "become active earlier" there is no third or fourth position. > > Perhaps the way to explain/understand this is that "position" here > does not mean "position on the command line", rather it means "order > in which to attempt to fill the next available position on the command > line". Yes, regarding the numbers as a priority for ordering may be a good way to explain this in the documentation. The exception to this is if you specify them upfront with a gap: _arguments '5:five' that'll complete nothing in positions 1-4 which is fairly useless. This might be regarded at least as being undefined behaviour and perhaps as a bug. The documentation could also be clearer for the case where the number is omitted. It is allocated by simply incrementing the number from the most recent one. Note:- _arguments '5:five' '2:two' ':three' '3:trois' results in: _arguments:comparguments:325: doubled argument definition: 3:trois > One other thing ... > On Mon, May 25, 2020 at 10:29 AM Oliver Kiddle wrote: > > > > '4:history size';; > Doc says: > The forms for ACTION are as follows. > (single unquoted space) > This is useful where an argument is required but it is not > possible or desirable to generate matches for it. The MESSAGE > will be displayed but no completions listed. Note that even > in this case the colon at the end of the MESSAGE is needed; it > may only be omitted when neither a MESSAGE nor an ACTION is > given. > That seems to imply that you can write "4:" or "4:history size: " but > not what you did write. Is the doc wrong? That was introduced in workers/11554 and I'm fairly certain it is wrong. As a hunch, the _arguments source was followed when listing the possible action forms and the subtlety that the empty string matches in the following line (411) was overlooked: if [[ "$action" = \ # ]]; then For what it's worth, I tend to leave the action out (going back to before that documentation change) because it keeps the spec a tiny bit shorter. And all too often _arguments specs are rather too long. Oliver