Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Empty lines do not break options sections. #52

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

EVGVir
Copy link
Contributor

@EVGVir EVGVir commented Aug 1, 2016

There are several reasons why an options section can be split by an
empty line, among them are:

  • logically grouping;
  • aesthetic reasons.

Such style is used, for example, in man program.

An example:

Options:
  --before-empty-lines  An option before empty lines.

  --after-empty-lines   An option after empty lines.

There are several reasons why an options section can be split by an
empty line, among them are:
- logically grouping;
- aesthetic reasons.

Such style is used, for example, in 'man' program.

An example:
    Options:
      --before-empty-lines  An option before empty lines.

      --after-empty-lines   An option after empty lines.
@EVGVir
Copy link
Contributor Author

EVGVir commented Aug 1, 2016

It is possible to play with this new regular expression here.

@jaredgrubb
Copy link
Member

Although I think there's merit to this request, adding this test-case causes the Python version of docopt to fail. One of the missions is to maintain feature parity across the variants of docopt. Can you post this in the docopt-py forum; if it's accepted there, then I can accept your patch as the port of that feature.

@EVGVir
Copy link
Contributor Author

EVGVir commented Aug 3, 2016

I have created a pull request in the main docopt repository.

The proposed changes for docopt can be found in the pull request
[339](docopt/docopt#339).
@EVGVir
Copy link
Contributor Author

EVGVir commented Aug 4, 2016

Something went wrong with Boost regexs. Other tests are okay.

The wildcard `.` matches any single character including the newline
character in Boost.Regex. So, `[^\\n]` construction is used instead.
"(?:^|\\n)(" // A section begins at start of a line and consists of:
"[^\\n]*" + name + "[^\\n]*" // - a line that contains the section's name; and
"(?:" // - several
"\\n+[ \\t][^\\n]*" // indented lines possibly separated by empty lines.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that there is a better solution for this issue. But that is how it looks like now, so I decided that it is okay to re-use this approach. After all, this issue must be addressed rather in a parallel pull request than in this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants