From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22081 invoked by alias); 21 Sep 2011 15:50:33 -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: X-Seq: 29791 Received: (qmail 24274 invoked from network); 21 Sep 2011 15:50:31 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <110921085012.ZM16562@torch.brasslantern.com> Date: Wed, 21 Sep 2011 08:50:12 -0700 In-reply-to: <17938.1316605147@thecus.kiddle.eu> Comments: In reply to Oliver Kiddle "Re: using the description from _arguments foo:description:->state" (Sep 21, 1:39pm) References: <110911111050.ZM11625@torch.brasslantern.com> <17938.1316605147@thecus.kiddle.eu> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh workers Subject: Re: using the description from _arguments foo:description:->state MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Sep 21, 1:39pm, Oliver Kiddle wrote: } Subject: Re: using the description from _arguments foo:description:->state } } Mikael Magnusson wrote: } > Can we add a new option to _configure which enables this, so if you } > say _arguments -d you also have to local state_descr. There's a couple } > of other variables that work like this already, -n for NORMARG, -C for } > curcontext. } } While we could, there's always the possibility that some function } somewhere has a -d that's intended to me an argument to be completed. That condition is already handled by using e.g. "_arguments -n : -n". More importantly, I don't think adding -d buys much. -C changes the meaning of ->state so that the caller doesn't need to copy from the context array to curcontext, but there's no equivalent for states or descriptions (unless we want to overload the name "descr" which is already used in a bunch of places, but I don't like that idea). } If you used a function instead of a state, it would be called with the } relevant arguments for the description unless you prefix it with a space } in which case, you'd have to dig around in $expl. Before producing my patch I first thought about digging around in $expl, but $expl is already marked up for use with _format, so that doesn't really work. Also $expl is only passed *down* from _arguments, not back up to the caller. } Unless you pass -C to _arguments there is the possibility of more than } one state being possible so any state_descr would need to be an array. Yes, that's what my patch does. $state_descr is an array parallel to the $state array. (Except in _values when $state is never an array, which I find a bit confusing but is probably too late to change.) } And we can't do arrays of arrays so a state_expl wouldn't be possible } (expl is already an array). That would put me off the whole idea } somewhat. Not an issue, _arguments declares "local expl" so it's never used with this form of state handling. } Personally, I'd be inclined to have a separate new-widget state in this } particular function. Yes, that would work in _zle, but other callers of _arguments are already passing a description which _arguments parses out, only to then throw it away. Shouldn't we keep that parsing in one place and make it useful?