Re: using the description from _arguments foo:description:->state

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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?