You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Markdown rendering of description can be surprisingΒ #225
People are surprised when deliberate newlines disappear when their features are rendered.
β¨ What's your proposed solution?
I suggest adding a title element somewhere that contains the original raw text from the description field so there's a bit more transparency about what's happening.
β Have you considered any alternatives or workarounds?
We could also add some kind of option to toggle markdown rendering (and if markdown's disabled, just use a fixed-width font for the description)
Looking at the raw source which is present inside the html, the original quantity of newlines is present, but it's one huge data-chunk, as opposed to split up ones. The full raw text from the .feature file is present in this stream.
A partial example is
{"line":53}}}},
{"source":{"uri":"features/foo/bar/baz.feature","data":"Feature: Forgot Password\n\n As an existing customer\n I want to be able to reset my password if I have forgotten it\n So that I can continue to use the thing\n\n This requires a foobarbaz\n They then must subsequently do a barbazbay\n\n Scenario:
We could also add some kind of option to toggle markdown rendering
FWIW, I think we are slowly rolling towards having some kind of options mechanism for the HTML formatter. There's stuff like #181 and also theming - nothing has yet been compelling enough on its own, but maybe collectively it's worth a look.
(and if markdown's disabled, just use a fixed-width font for the description)
Minor point, but rather than a monospace font I think we'd just use the regular font and white-space: pre-wrap in order to preserve the original spacing.
Activity
luke-hill commentedon Jun 23, 2022
Looking at the raw source which is present inside the html, the original quantity of newlines is present, but it's one huge data-chunk, as opposed to split up ones. The full raw text from the .feature file is present in this stream.
A partial example is
davidjgoss commentedon Jun 23, 2022
FWIW, I think we are slowly rolling towards having some kind of options mechanism for the HTML formatter. There's stuff like #181 and also theming - nothing has yet been compelling enough on its own, but maybe collectively it's worth a look.
Minor point, but rather than a monospace font I think we'd just use the regular font and
white-space: pre-wrapin order to preserve the original spacing.mattwynne commentedon Jun 23, 2022
Interestingly, these comment blocks in Github (which I assume use GFM) do preserve newlines:
First line
Second line
Which comes out as:
That doesn't match my reading of the spec. I wonder what's going on?
davidjgoss commentedon Jun 23, 2022
This seems to be the loophole?
mattwynne commentedon Jun 23, 2022
Ha! So maybe we can just turn that on in order rendering component?
Looks like we might need https://github.com/remarkjs/remark-breaks maybe?
mattwynne commentedon Jun 30, 2022
π thanks @davidjgoss!