Re: [Structuredtext-develop] Some problems with option lists

[David G. <go...@us...>]

Richard Jones wrote:
> 1. the leading dashes are removed from the short_option and long_option. Is
> this intentional? If so, I'll re-add the dashes, but it seems odd.

Yes, it's intentional. The various option types are uniformly represented in
the tree. Once the options have been parsed into "long_option" or
"short_option" elements, the dashes are implicit; they're boilerplate text,
redundant and uninteresting. It's text to be inserted by the Writer.

> 2. similarly, the arguments lose the '='.

"=" are lost for the same reason: redundancy. The back-end Writer may choose
to always use "--option=arg" or always use "--option arg", but it should be
consistent.

> This becomes ambiguous:

I don't see the ambiguity. Please explain.

> 3. short options can't have '=' arguments:
> 
>       -DC_DEFINE_FLAG=value
> 
> results in an error.

Correct. Short options never have '=' (not on any system I've seen, anyhow).
Short option names are never more than one letter long, either -- that's why
they're short! Your example is actually equivalent to::

    -D C_DEFINE_FLAG=value

While this may be valid as an actual option (i.e., as entered on the command
line), it doesn't make sense as a placeholder.

The option list syntax is based on common practice in command-line tools
such as GNU utilities, and on the command-line parsers that they use, such
as getopt.py and Optik.

> 4. any chance of a format like:
> 
>        -i / --info      get information

I chose ", " as the separator from observation of the "--help" output of
various tools. I don't see the need for two ways to spell it. Also, "/" is
used for VMS/DOS-style options, so it may be confusing here.

-- 
David Goodger    go...@us...    Open-source projects:
 - Python Docstring Processing System: http://docstring.sourceforge.net
 - reStructuredText: http://structuredtext.sourceforge.net
 - The Go Tools Project: http://gotools.sourceforge.net