zsh-users
 help / color / mirror / code / Atom feed
From: Eric Cook <llua@gmx.com>
To: zsh-users@zsh.org
Subject: When to (and not to) use _arguments -C with states
Date: Mon, 20 Sep 2021 15:09:11 -0400	[thread overview]
Message-ID: <b39d6abb-4b66-6660-5673-b896692a18e1@gmx.com> (raw)

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:

case $state in ...

Which made me question when is multiple ->string actions possible?

An contrived example being:
_foo() {
   local s expl state state_descr line
   local -A opt_args

   _arguments '1: :->foo' '-a[optional argument]:: :->bar' && return

   for s in $state; do
     case $s in
       foo) _wanted digit-tag expl 123s compadd 1 2 3;;
       bar) _wanted alpha-tag expl abcs compadd a b c;
     esac
   done
}
compdef _foo foo # foo -a <tab>

since -a uses ->string but it's argument is optional, the '1: :->foo' spec is also valid
so foo and bar are correctly in $state at once.

Are there other ways in which $state can contain > 1 elements?
I ask because i would like to know when it is safe to use _argument -C


             reply	other threads:[~2021-09-20 19:10 UTC|newest]

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

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=b39d6abb-4b66-6660-5673-b896692a18e1@gmx.com \
    --to=llua@gmx.com \
    --cc=zsh-users@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).