CRLF causes bad parsing of steps, comments, tags, etc... about gherkin2

[aslakhellesoy]

FWIW - in order to check in files with "\r\n" to Git without Git trying to convert them - see http://github.com/aslakhellesoy/cucumber/blob/master/.gitattributes

[ghnatiuk]

Thanks! Had no idea github would do that. Will save me us troubleshooting time for sure.

[aslakhellesoy]

Not Github - Git :-)

[ghnatiuk]

Oh. Hah. yes, that.

[aslakhellesoy]

I saw you did some changes Greg, but it's still failing for me. Extra \r at end of line in the spec you added. Still WIP?

[ghnatiuk]

Yeah, still WIP unfortunately. the C lexer is having problems with \r in pystrings, though it looks to be passing in Java and Ruby. I haven't integrated the C# stuff yet to test with that.

[ghnatiuk]

Well, actually, I need to clarify the behavior a bit before I can say whether the ruby/java tests pass.

If a pystring contains \r\ns, should they be preserved as such within the py_string message?

[aslakhellesoy]

I believe they should be preserved as is, yes. (Likewise, I think the pretty printer in gherkin should use whatever line ending the source had when printing stuff back, but this is not a lexer issue - apart from perhaps detecting the most likely line ending for a particular file - sometimes they are mixed)

[aslakhellesoy]

Ruby and Java are now splitting and joining multiline strings with the most frequent eol.

The C and C# parser must catch up before we close this ticket.

[ghnatiuk]

I've got this working in C, though I'm going to clean it up a bit before pushing.

Should be pretty easy at this point to pass the result of the frequency count on to the listener. What do you think the signature of that should be? A separate message before sending feature...an optional 4th argument to .feature (e.g. crlf=false)?

The specs pass in C, but the feature comparing pretty-output of the cucumber DOS features fails (because of newline differences). For some reason, when running that scenario under jruby, the output is not seen as different even though the line endings are not the same.

[aslakhellesoy]

So only C# is left. That will be exposed when #45 is adressed, so I'm closing this for now. If C# needs a special CRLF ticket later we'll create a separate ticket.