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

Make the parsing metadata more flexible #241

Closed
wants to merge 3 commits into from
Closed

Make the parsing metadata more flexible #241

wants to merge 3 commits into from

Conversation

atao60
Copy link

@atao60 atao60 commented Nov 6, 2015

This request answers to the three enhancements suggested by Make the parsing metadata more flexible(intelligent) #180:

  • Allow blank lines in header of content files
  • Allow spaces around equal of a header entry
  • Allow multi-lines value for header entry value

About this last point: any line starting with 2 spaces will be concatenated with the previous line.

See point #1 "the first line is blank" of issue "Make the parsing
metadata more flexible(intelligent) #180"
(#180)
See point #2 "each field has white space after equal sign" of issue
"Make the parsing
metadata more flexible(intelligent) #180"
(#180)
Any line starting with 2 spaces will be concatenated with the previous
line.

See point #3 "the field tags is multi-line " of issue
"Make the parsing metadata more flexible(intelligent) #180"
(#180)
@jonbullock
Copy link
Member

Thanks for the contribution.

@jonbullock jonbullock added this to the v2.5.0 milestone Nov 10, 2015
@jonbullock jonbullock self-assigned this Nov 10, 2015
@jonbullock
Copy link
Member

I've been reviewing this PR and I've come to conclusion that I won't be taking the change in. The reason being I don't want to complicate the structure of the metadata header, it's simple as is and while this fixes #180 I don't agree with part of the original change to allow multi line options. The structure of the header is clearly set out, one line = one option. Having said that, the other two suggestions I see as making the parsing code more tolerant which can be addressed with a couple of small code changes.

Thanks again for taking the time to contribute and apologies for the time it's taken in reviewing this PR.

@jonbullock jonbullock closed this Aug 21, 2016
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