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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20941 invoked from network); 25 May 2020 22:33:46 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 25 May 2020 22:33:46 -0000 Received: (qmail 3567 invoked by alias); 25 May 2020 22:33:35 -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: 45916 Received: (qmail 792 invoked by uid 1010); 25 May 2020 22:33:35 -0000 X-Qmail-Scanner-Diagnostics: from mail-ot1-f45.google.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(209.85.210.45):SA:0(-1.9/5.0):. Processed in 0.971127 secs); 25 May 2020 22:33:35 -0000 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.210.45 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LkfG1i8DhqUHtxo1wxEo4ik33lEiV9C66BnBaY8QDA4=; b=cuh2Fcf4nDOxUH7VW5XL+CtVX6GdMCJdCaxg6wfywXTqi2o5u71e6nL7amYKDn0B3c Yi5WPW1RhKd+1AHpKyy5Gr82aVGysU6MqIAGpWc2SwiocKB/okQrNTWWZ3b6FqAb4YGe tFXaP+qH88dSIj9z09KvLJmQ2WjYNnU6CbtrORFxLM7Bc15bvE+NSmlXmuimJ/V9PPHy /C+UugrQzsn/CwV5had7TRvES/mb0a0GryrhJHRIVMHAcPykcKIpxFiUL/IoAHtDUlsJ 9DV1LrySsJNybMmnhzAVJr5oVJK3QC+pbcw0ZxGEsdxST2vtRc7GNlOnWhNH/RBz6js+ fntg== X-Gm-Message-State: AOAM532PHP5VJFFQIaNxmv/9N42Ueq7fFEyvkeYopc18htVt/XmaRS1+ FJ6E/+Y9OzkS9T5VQbjG/hnXidL3tMTGM3v2kOLMPT+bYOBAiQ== X-Google-Smtp-Source: ABdhPJzy03k5ILpwEU9YE4Ut/ETYnlOYF+00qUVCq1zIgQ/mUWH/DRRQYoBc86XnOxI4ScmkfeaprNo4AddUTsMjlhU= X-Received: by 2002:a9d:20e7:: with SMTP id x94mr23920051ota.260.1590445982065; Mon, 25 May 2020 15:33:02 -0700 (PDT) MIME-Version: 1.0 References: <20200523022807.08f3ba45@tarpaulin.shahaf.local2> <71744-1590427742.474587@WgsI.yCFx.n5vu> In-Reply-To: <71744-1590427742.474587@WgsI.yCFx.n5vu> From: Bart Schaefer Date: Mon, 25 May 2020 15:32:50 -0700 Message-ID: Subject: Re: _arguments optspecs (was Re: Editing the history in the shell) To: Oliver Kiddle Cc: Zsh hackers list Content-Type: text/plain; charset="UTF-8" (Thanks for copying me, that got around gmail's blocking list-forwards of yahoo.) On Mon, May 25, 2020 at 10:29 AM Oliver Kiddle wrote: > > > On Sat, May 23, 2020 at 2:30 PM Bart Schaefer wrote: > > > > > > all the desired combinations seem to work > > > and all the undesired ones seem not to. > > How about the following combination: > > zed -f -x2 -- Ah, I didn't notice that zed -f _zed -x2 is not accepted by zed itself. > > My uncertainty is around these three lines: > > > > > '(- 2):file:_files' \ > > > + '(-f -x 1)-h[edit history]:history file:_files' \ > > > + '2:history size: ';; > > The first thing to note is that if you leave the number out as in the > first spec, it will assign it the next number. So the 1 in the exclusion > list for -h does apply to the first spec. 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. > > 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? > > appears that sometimes the argument of -h is not counted as a > > non-option argument, and other times it is so counted, which is why > > it's "2:" in the third optspec and the (1) is required in the second > > optspec. > > 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. > 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? > '(-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".