The "this option should be documented" step needs improvement

[davetron5000]

It doesn't work when the terms contain regex-y characters (e.g. for --[no-]foo), and it gets cumbersome when you have multiple options. I think it needs to work like so:

Then the following options should be documented:
  | -i | --ignore-case | which is negatable
  | -c | --color |
  | --version |

Here, -c and --color aren't negatable, but for -i, we can check for --[no-]ignore-case.

[tamouse]

While you are in there, forcing the descriptive text to start with at least a 3-letter word is fail. Help syntax starting with a one or two-letter word should be possible.

[davetron5000]

I think it just requires that the help text is more than three characters
total, meaning that help text that is only one or two characters isn't
valid. I have to admit, I can't imagine useful help text that is only one
or two characters, but if you've got an example, I'd be willing to change
it (or a better way to test that certain options have been given
documentation)

Dave

On Fri, Dec 7, 2012 at 6:07 PM, Tamara Temple notifications@github.heygears.comwrote:

While you are in there, forcing the descriptive text to start with at
least a 3-letter word is fail. Help syntax starting with a one or
two-letter word should be possible.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-11150290.

[tamouse]

i wish:

the output should match /\s*#{Regexp.escape(option)}[\s\W]+\w\w\w+/

That means you have to have at least 3 alnum characters to start the
description.

My description started with "Do not (blah blah)" and it caused the step to
fail.

On Fri, Dec 7, 2012 at 6:20 PM, David Copeland notifications@github.heygears.comwrote:

I think it just requires that the help text is more than three characters
total, meaning that help text that is only one or two characters isn't
valid. I have to admit, I can't imagine useful help text that is only one
or two characters, but if you've got an example, I'd be willing to change
it (or a better way to test that certain options have been given
documentation)

Dave

On Fri, Dec 7, 2012 at 6:07 PM, Tamara Temple notifications@github.heygears.comwrote:

While you are in there, forcing the descriptive text to start with at
least a 3-letter word is fail. Help syntax starting with a one or
two-letter word should be possible.

—
Reply to this email directly or view it on GitHub<
https://github.com/davetron5000/methadone/issues/37#issuecomment-11150290>.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-11151984.

--Tamara
aka tamouse__

May you never see a stranger's face in the mirror.

[davetron5000]

This should now be in 1.2.3 and remove the constraint of a three-letter word - don't know how I missed that, but thanks for the bug report!

[pvdb]

Hey @davetron5000,

The changes in 3ab4088 have broken "compatibility" with Trollop-style command-line options:

Options:
    --verbose, -V:   Run  verbosely
    --version, -v:   Print version and exit
       --help, -h:   Show this message

Before that commit, you could use the following examples table (cheating a wee bit, but at least it worked):

     And the following options should be documented:
         | --verbose, -V:   |
         | --version, -v:   |
         | --help, -h:      |

... but that no longer works. None of the suggested alternatives work either:

     And the following options should be documented:
         | --verbose, -V   |
         | --version, -v   |
         | --help, -h      |

(the options get split on the "," but still no joy)

     And the following options should be documented:
         | --verbose | -V   |
         | --version | -v   |
         | --help    | -h   |

(still doesn't work because of the ":" in the output AFAICT)

I'll submit a pull request but thought I'd give you a heads up...

[davetron5000]

Interesting - you are using this step to tdd a trollop app? Talk about unintended uses! :)

Yeah, this step is still pretty badly concieved, so anything you can do to improve it is good - it was designed around exactly what methodone/OptionParser produces, but if we can make it a bit more flexible, that's cool with me.