Re: New options & arguments processing system for ZSH

[martin.ebourne@xxxxxxxxxxxx]

> I think this format is complimentary to the XML stuff with which I've
> been playing.  I think it would be possible to generate the parse_opts
> call from the XML format

I'm sure that it would be possible to convert XML -> parse_opts, and if
there are other tools that convert to XML from eg. man pages, I can think
of some uses too. However, for most small-medium sized shell scripts I'd
like to think that the format is simple enough to be coded directly.

> One thing I noticed when trying to complete options to the supplied
> "yes" function, was that it didn't provide much help for the options.
> It provided type information, but it didn't actually tell me what the
> options did.

I'm not quite sure what you mean here. It does use the help text for
options, so I'm going to make a couple of guesses what you might mean and
try and explain a little. My appologies in advance if I'm way off track!

The help text for each option/argument is extracted and stored against the
option/argument. It is also made use of in both cases. For options, it is
used in exactly the same way as for all the other completions I've seen,
which is when you are completing the option *name* it lists the
descriptions against that. When you are completing the option *value* it is
not used because there is a separate description for that, which tells you
the type to be completed. I have thought on occasion that it would be nice
to have the option description available at the point of completing the
value as well. parse_opts could be changed to do this but I think it's more
of a general issue. I guess probably _arguments could do this itself, based
on a style, by simply concatenating the option description onto the end of
the value description.

For arguments, there currently is no description of what the argument is
for in any of the completions I've seen - only a description of what you
are completing. I didn't want to waste the help text present in this case
so parse_opts does concatenate the argument help onto the end of the value
descriptions exactly as I've just suggested for options.

I'm sure you're aware that various styles need to be set to be able to view
the various descriptions.

> The format does provide a mechanism to do that.  Though
> it seems like that it requires duplicating information that is already
> there in the help text.  So it seems if it was somehow possible to reuse
> the help text already there that might be useful.

Again, I'm not quite sure what you mean about specifying the help text
separately. I can think of two angles:

1. Defining a type:
    #type newtype basetype completion_description completion_action
Here you can give a full description for the value to be completed, and
could duplicate the option help. As I mentioned before, I'd like to see
this done in a more central place though.

2. Defining an option with helptext override:
    # --option * help="the description"
This simply overrides the help extracted automatically from the help text.
I don't envisage this will be useful except in extremely rare circumstances
when it has trouble extracting help from the main text. The only reason
it's there is because it's a generic method of adding new settings
associated with an option/argument/type, and is also able to override all
current ones. The help specified in this case will be used in exactly the
way I've described above.

I would like to think that there's no need for duplication of information
when using parse_opts, certainly that's one of the major design goals.

> This format also gives the developer a bit of control over where&how
> option information is placed variables.  It would be nice if _arguments
> had richer control over that.  Though this extra control seems like it
> is more for command line parsing that for completion.

Since _arguments doesn't decode values for use I don't see how that would
work. Certainly this information is only used by parse_opts for the
processing of the options/arguments when the command is actually invoked,
not when completed.

Thanks for your interest,

Martin.