@jensakejohansson Thank you for contributing to spectacle. Your pull request has been labeled as a release candidate 🎉🎉.

Merging this PR will trigger a release.

Please bump up the version as part of this PR.

Instructions to bump the version can found at CONTRIBUTING.md

If the CONTRIBUTING.md file does not exist or does not include instructions about bumping up the version, please looks previous commits in git history to see what changes need to be done.

Hmm, I wonder why it won't possible for the markdown renderer to handle these natively. Is this to do with variations of how tables can be defined in various markdown flavours?

Would it be possible to add/augment the functional tests to demonstrate the flavour/style you've tried to specifically handle?

There are some proposals in flight to handle multi-line string inputs in Gauge specs so want to see if we can avoid totally breaking that (although this plugin would presumably need to be augmented for that anyway).

Ah, this is a bit confusing. I thought it never worked (and was surprised it was never fixed). However it seems to be more complicated than that. The template example for Gauge seems to work(?), but my specs does not. Although I cannot see any obvious difference in how a table is defined:

Works:

Does not work:

I'm lost, I guess some debugging and time is needed if I'm going to understand what is happening here...

Some progress. It's a file format issue. I had two seemingly identical specs. The one that did not work used Windows-style format (different new line char). When converting it to Unix-style spectacle handled it correctly.

@chadlwilson Given this information do you have suggestion of a way forward to make the plugin handle both cases? Oherwise I will gladly dig further....

nopcommerce.spec did not work, example.spec did.

After conversion both were handled correctly by Spectacle.

Ok. Replacing any LF char with Unix style LF in the file before sending it to the renderer seems to do the trick. Updated the PR accordingly.

Yeah, that’s probably the issue. Would just intend to check how gauge itself parses the specs in a line-ending agnostic manner to see if it’s consistent.

Good idea. I browsed through the Gauge code, but didn't see anything in Gauge that changed my mind. You probably know the code better. I just found some replace statements similar to the one in this PR, but to me my browsing didn't reveal any 'unified strategy' for this that makes me update this PR. So I'll leave it as is.

My understanding is actually that this is a problem in golang-commonmark/markdown package, as I believe it's reasonable to assume it would handle both Windows & Unix formatting. The package is not used in other Gauge project from what I saw.

As always, I appreciate your feedback and time.

I imagine the gauge code might be different as it is actually lexically parsing the spec. The parser is possibly line oriented and line ending agnostic.

Theoretically the parser here should also behave that way but it seems to be some old golang library. Haven't looked at whether it can be told to operate differently without pre-processing.

I don't know the code super well, as I'm mainly just a minor maintainer and build wrangler, I've never implemented major changes, and also not a golang expert.

Then I hope someone is willing to approve this PR as it's simple and seems to solve a long-standing issue.

The plugin is infrequently used and probably even less frequently used by those on Windows especially 5hose who don't normalise their line endings on commit to their repo.

Looks like the parser moved domains from github.com to gitlab.com which is why it's not getting updates.

https://gitlab.com/golang-commonmark/markdown/-/commits/master

Probably should switch to that and see if it's fixed first, but then yeah, otherwise merge something like this in.

I dont think we need to be super defensive for this plugin, as this is something that is intended to aid local development/debugging.

But if we have to, then my only suggestion is to have this platform specific code in a platform specific go file. i.e. extract the crlf replacement logic into a platform specific file (example: https://github.com/andybalholm/crlf)

I wouldnt insist on it though unless you would like to do this nevertheless @jensakejohansson ?

@chadlwilson Yes. I saw that it was moved to GitHub. Didn't go down that road since moving multiple versions of the MD-renderer seemed like it could cause unforeseen issues - but in retrospect I should have done that!. I tried now and it seems that, yes, this issue is actually solved in the latest version.

So I will propose that change instead. That is, just updated to latest version of the dependency, that's it.

Note that I have close no experience in actually working in Golang, so if I've checked in files not needed or incorrectly, have patience. I just pushed what changed locally when I updated the dependency in my repo.

Yup, I'll take a look in a bit 👍

And yeah @sriv - given it had been broken for ages until yesterday on x64 (due to me,.probably) I'm not thinking we need to be too defensive either 😅

Thanks for merging and your engagement!

As for as I can see it also solved this issue:

#47