zsh-users
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <opk@zsh.org>
To: Eric Cook <llua@gmx.com>
Cc: zsh-users@zsh.org
Subject: Re: When to (and not to) use _arguments -C with states
Date: Tue, 21 Sep 2021 17:20:52 +0200	[thread overview]
Message-ID: <439-1632237652.253313@73O7.mb_i.71xZ> (raw)
In-Reply-To: <b39d6abb-4b66-6660-5673-b896692a18e1@gmx.com>

Eric Cook wrote:
> I think that i mostly already figured it out but this piece of zshcompsys(1) always confused me.
>
>   Where _arguments encounters action in the `->string' format, it will strip all leading and trailing whitespace from string and
>   set the array state to the set of all strings for which an action is to be performed.  The elements of the  array  state_descr
>   are assigned the corresponding message field from each optarg containing such an action.
>
> In the majority of completers that i have written that used ->string actions, only one action was
> `action`able at a given time. meaning $state is only a single element, with code that assumes as much like:

In the vast majority of cases this is true – which allows you to pass -C
and have it modifiy $curcontext instead of needing to pick out the
correct element of $context.

> Which made me question when is multiple ->string actions possible?
>
> An contrived example being:

This is probably the most obvious case – optional arguments in
conjunction with normal arguments. Fortunately even that is rare.
Optional arguments often require an = or no space between option and
argument.

It is also fairly easy to contrive cases using the sets feature of
_arguments, e.g something like:

  _arguments - first '-f' '1:foo' - second '-f:bar'

Sets with overloaded options does happen and can require a little care
(and sometimes the application of _guard for numeric arguments).

You can also get into the question of normal arguments that look like
options. _arguments doesn't always handle that perfectly but given that
argument parsing libraries generally don't cope either it isn't really
something we need to worry about.

The rare cases where you can't use _arguments -C are usually fairly
obvious. It tends to be otherwise apparent that they've got weird
argument parsing to begin with. For some such things, _regex_arguments
can be a better choice.

Oliver


      reply	other threads:[~2021-09-21 15:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-20 19:09 Eric Cook
2021-09-21 15:20 ` Oliver Kiddle [this message]

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=439-1632237652.253313@73O7.mb_i.71xZ \
    --to=opk@zsh.org \
    --cc=llua@gmx.com \
    --cc=zsh-users@zsh.org \
    --subject='Re: When to (and not to) use _arguments -C with states' \
    /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

Code repositories for project(s) associated with this 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).