Zsh Mailing List Archive
Messages sorted by:
Re: _arguments optspecs (was Re: Editing the history in the shell)
- X-seq: zsh-workers 45916
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- Subject: Re: _arguments optspecs (was Re: Editing the history in the shell)
- Date: Mon, 25 May 2020 15:32:50 -0700
- Cc: Zsh hackers list <zsh-workers@xxxxxxx>
- In-reply-to: <71744-1590427742.474587@WgsI.yCFx.n5vu>
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- List-unsubscribe: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CAH+w=7ZFt7jshjv1FCEbmP_PgADvdKwymRutrzwJAvzNpsfOmA@mail.gmail.com> <firstname.lastname@example.org> <CAH+w=7aWxdY3KuTaYym1GiAowRRHBc=2AJPPgqOmN8G6L0xT2A@mail.gmail.com> <CAH+w=7ZxOQQCwzCzYm6NX1NP-HPspACV_Yf56b0O3VZP=jsfPA@mail.gmail.com> <71744-1590427742.474587@WgsI.yCFx.n5vu>
(Thanks for copying me, that got around gmail's blocking list-forwards
On Mon, May 25, 2020 at 10:29 AM Oliver Kiddle <okiddle@xxxxxxxxxxx> wrote:
> > On Sat, May 23, 2020 at 2:30 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > >
> > > all the desired combinations seem to work
> > > and all the undesired ones seem not to.
> How about the following combination:
> zed -f -x2 -- <tab>
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' \
'(- 2)1:file:_files' \
?? 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
Messages sorted by: