[RFC] use optparse for option handling

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
> Aaron Bentley wrote:
> As an aside, it might be nicer if we could detect a few argument types,
> and pass them to the optparse parser, rather than using callback. But
> that can be something in the future.

I'd prefer that, too.

The docs seem to indicate that you need to subclass OptionParser to get
it to handle new types, and since we don't know all the types without
scanning every command, we wouldn't be able to.

> Why are you writing a '\n' *before* the output of 'format_option_help'
> it would seem to me that if anything, you need it after.
> - From what I see, the code is already doing outfile.write('\n') if the
> documentation doesn't end in a newline before it even calls
> help_on_command_options.

Imitating the previous formatting, which has a newline separator between
the last line of description and the options:

- -    outfile.write('\noptions:\n')
+    outfile.write('\n')
(more or less)

> Otherwise I'm happy to see us using optparse to generate the output.
> Since they already deal with wrapping, and all that.
> 
> It will mean quite a change to the output, though. Since instead of
> doing (log --help):

Actually, we can change that back, and it will be more correct in the
few cases where ARG is overridden.  (But I only see *one* case where ARG
is overriden: the --file option to commit)

> It isn't bad, but it is different.

I think I prefer the optparse way, but we can do either.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEtVrA0F+nu1YWqI0RAreCAJ9qb0jn3mN5O3W3L94TZWmIuSRgngCffBTR
YKrSjvqVhszoHjC9cB12yzQ=
=H5Qt
-----END PGP SIGNATURE-----