zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: _arguments optspecs (was Re: Editing the history in the shell)
Date: Tue, 26 May 2020 09:56:26 +0200	[thread overview]
Message-ID: <89018-1590479786.775145@0MSv.YwO6.IDjS> (raw)
In-Reply-To: <CAH+w=7aaZCLsnd5c0AaWD5AmmibGwy47xnibhXwu-osv-zBfDA@mail.gmail.com>

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 <okiddle@yahoo.co.uk> 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

  reply	other threads:[~2020-05-26  7:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-22 22:24 Editing the history in the shell Bart Schaefer
2020-05-23  2:28 ` Daniel Shahaf
2020-05-23 21:30   ` Bart Schaefer
2020-05-24 22:02     ` _arguments optspecs (was Re: Editing the history in the shell) Bart Schaefer
2020-05-25 17:29       ` Oliver Kiddle
2020-05-25 22:32         ` Bart Schaefer
2020-05-26  7:56           ` Oliver Kiddle [this message]
2020-05-25 22:42         ` Bart Schaefer
     [not found]     ` <20200525023515.7855610a@tarpaulin.shahaf.local2>
     [not found]       ` <CAH+w=7bTCCC2XBr+_HCAPqXWuOV_YOrDv+36C6jJScKrxZjhLQ@mail.gmail.com>
2020-05-27  3:32         ` Fwd: Editing the history in the shell Bart Schaefer
2021-04-25 21:56           ` [PATCH] " Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=89018-1590479786.775145@0MSv.YwO6.IDjS \
    --to=okiddle@yahoo.co.uk \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).