From: Guenter M. <mi...@us...> - 2009-08-08 12:04:06
|
Dear Docutils developers, Currently, there are 15 command line options with --no-... for rst2latex and 16 ones for rst2html. Some of them belong to --some-feature --no-some-feature pairs. In other cases, the corresponding enabling/disabling option is missing, which becomes problematic if the default setting is changed in a config file. Instead of providing option pairs for all boolean settings, I would like to introduce support boolean command line arguments, i.e. --some-feature=True --some-feature=False (which should accept the same set of values as the config file). What do you think? Günter |
From: <gr...@us...> - 2009-08-12 11:05:35
|
On Sat, 8 Aug 2009, Guenter Milde wrote: > Dear Docutils developers, > > Currently, there are 15 command line options with --no-... for rst2latex and > 16 ones for rst2html. Some of them belong to > > --some-feature --no-some-feature > > pairs. In other cases, the corresponding enabling/disabling option is > missing, which becomes problematic if the default setting is changed in a > config file. > > Instead of providing option pairs for all boolean settings, I would like > to introduce support boolean command line arguments, i.e. > > --some-feature=True --some-feature=False > > (which should accept the same set of values as the config file). > > What do you think? Sounds reasonable. I lately had two problems with this: * section-numbering only works when activated in the document not from commandline * there is no datestamp option only no cheers -- |
From: Dave K. <dku...@pa...> - 2009-08-12 18:39:59
|
> From: Guenter Milde > Sent: Saturday, August 8, 2009 5:03:33 AM > > Dear Docutils developers, > > Currently, there are 15 command line options with --no-... for rst2latex and > 16 ones for rst2html. Some of them belong to > > --some-feature --no-some-feature > > pairs. In other cases, the corresponding enabling/disabling option is > missing, which becomes problematic if the default setting is changed in a > config file. > > Instead of providing option pairs for all boolean settings, I would like > to introduce support boolean command line arguments, i.e. > > --some-feature=True --some-feature=False > > (which should accept the same set of values as the config file). > > What do you think? > +1 Seems like an improvement to me. Can we put a note somewhere in the Docutils documentation so that implementers of writers in the future will know about this convention? - Dave K. -- Dave Kuhlman http://www.rexx.com/~dkuhlman |
From: Guenter M. <mi...@us...> - 2009-08-12 22:50:33
|
On 2009-08-12, gr...@us... wrote: > On Sat, 8 Aug 2009, Guenter Milde wrote: For some boolean option pairs (--some-feature --no-some-feature) >> ... the corresponding enabling/disabling option is missing, which >> becomes problematic if the default setting is changed in a config >> file. >> Instead of providing option pairs for all boolean settings, I would like >> to introduce support boolean command line arguments, i.e. >> --some-feature=True --some-feature=False >> (which should accept the same set of values as the config file). > Sounds reasonable. Unfortunately, there is no straigthforward support for a backwards-compatible solution with optional argument (accepting both ``--some-feature`` and ``--some-feature=True``). The optparse docs say: Typically, a given option either takes an argument or it doesn\u2019t. Lots of people want an \u201coptional option arguments\u201d feature, meaning that some options will take an argument if they see it, and won\u2019t if they don\u2019t. This is somewhat controversial, because it makes parsing ambiguous: if "-a" takes an optional argument and "-b" is another option entirely, how do we interpret "-ab"? Because of this ambiguity, optparse does not support this feature. So I am not sure whether its better to a) add missing "partner options", or b) introduce boolean arguments > I lately had two problems with this: > * section-numbering only works when activated in the document > not from commandline This is a feature, it must be *enabled* via command-line/config-file and *activated* in the document. Günter |