Re: New options & arguments processing system for ZSH

[martin.ebourne@xxxxxxxxxxxx]

> - I like it a lot better than the XML version suggested by Felix, but
>   the ideal solution probably lies somewhere between the two.

Quite likely. Certainly I can see advantages of both systems, and even of
converting between the two. As to whether it'll ever be possible to come up
with a format that's ideal both for complicated programs such as find, and
simple ones as cat, I'm not so certain. Coupled with the fact that
different people like to do things in different ways, I think it's helpful
to have different systems.

> - It suffers from the same problems as my _arg_compile scheme, to wit,
>   every function that uses it has to do a lot of extra work that is not
>   directly related to the purpose of the function.

I like _arg_compile, it certainly makes the less than intuitive (in my
opinion anyway!) syntax of _arguments much more readable. However, with
parse_opts I was really trying to tackle a different problem. What I wanted
was something that would decode the command line when a program is run,
splitting options and arguments into data structures as required, and
performing any validation possible (sort of a zparseopts on steroids ;)). I
wanted this to simplify the writing of scripts/functions which were
complicated enough to need some code to parse the command line. While I was
on the way I found I could add automatic completion for almost no extra
hassle on the user's part, so I jumped at the chance.

As to the extra work done by the 'client' function, in terms of processing
there is a fair bit extra - mostly to do with decoding the help. However
since this is intended to be done mainly for functions which are used
directly by a person, not ones used by other functions in a larger system,
I don't think the processing overhead is really an issue. I can think of
some ways of caching this stuff though, which would be of most advantage to
speed when completing I think, and would probably almost eliminate the
overhead.

As to extra work in terms of code in the function, I don't think that's the
case. Most of the lines are real help text, and there's not much you can do
to shorten that apart from not provide it. I've done my best to keep the
calling syntax very simple, and hopefully managed it to a large extent. I
did go through most of my shell functions and convert them to this system.
Almost all functions that did any kind of options parsing, help, or
validation became shorter, and all of the functions became more functional
(long options, completion, etc). Even with a case like the 'yes' example,
the real code became noticably shorter, and the division of responsibility
between decoding and doing became much more clear.

> - Here-documents end up getting encoded as strings in the compiled
>   function definition in memory, so this is probably prohibitive for
>   general use except when using zcompile'd files with memory mapping.

I've already mentioned that most of the text is 'real' help, so that's no
different to you'd get if you provided that anyway. Personally I like
commands to be as helpful as possible, so that's a price I'm prepared to
pay - and as I've said, I don't see a major use for this in decoding
options for internal functions - ie. I wouldn't expect the completion
system or anything similar to use it internally! [nothing stopping it
though... ;)]

On the other hand, tt is fair to say that all of my functions are in
separate autoloaded files, and I do have them all compiled on a
per-directory basis. But then I did that anyway. ;)

> - You should have sent it to zsh-workers, not zsh-users. :-)

Yes, I can certainly see your point. I did think about it for quite a
while. The thing that tipped the balance for me was that I feel it is the
sort of thing that any users of zsh who are writing shell scripts might
find helpful, as opposed to just the developers of Zsh. After all, I'm in
the former category, and obviously find it useful! Also even on a slow
modem the download time should be < 15 seconds, so I didn't think it was
too bad.

Certainly all followup should be on workers, as has happened.

Thanks for looking at it, any further suggestions welcomed if you get
chance.

Cheers,

Martin.