Properly parse line breaks in Markdown without adding extraneous <br> tags

[dnotes]

Version

2.5.3

Test Environment

Firefox (current), MacOS

Current Behavior

Writing a line break in the markdown editor results in a <br> being added to the html output for both the preview pane and the wysiwyg editor:

this is a paragraph
which should not be split

is rendered as

<p>this is a paragraph<br>
which should not be split</p>

Expected Behavior

In the GFM specification a line break is specified as a soft line break, and though viewers may choose to display such breaks as either a line break or a space, it is clear from the example that the resulting HTML should not have a <br> tag in it. So for the above example:

this is a paragraph
which should not be split

should be rendered in the Toast UI preview and WYSIWYG editors as

<p>this is a paragraph
which should not be split</p>

[dnotes]

Note that while this seems to be related to #299, I don't think it's a duplicate, because that issue has more to do with what happens when pasting text into the WYSIWYG, and not strictly with the markdown rendering.

[sohee-lee7]

Currently we are supporting that 'soft line break' render like 'hard line break'. But if you needs to support 'soft line break', we will provide to option to be able.

reference: github/markup#1050

[dnotes]

Yes I definitely need this option, and it would let Toast UI conform to GFM as well, as in the spec it says "a renderer may also provide an option to render soft line breaks as hard line breaks." Thanks!

[parthshah31]

We also are in need of this. Our users are expecting a hard line break in the wysiwyg when they create a new line. However when the generated markdown is rendered with a variety of tools, there is no line break.

[benjaminbaker]

Ran into this problem as well. Unfortunately, due to this issue, it makes it nearly impossible for us to combine it with other markdown tools.

[js87zz]

@dnotes @parthshah31 @benjaminbaker
Sorry for late replying.
The soft break is rendered as hard break for syncing the content in our WYSIWYG. So, if changed, it could be a problem in WYSIWYG.
If it doesn't matter, You can change the soft break default operation through the customHTMLRenderer option as below.
(customHTMLRenderer option can be used above the v2.x)

const editor = new Editor({
  el: document.querySelector('#editor'),
  customHTMLRenderer: {
    softbreak(_, { options }) {
      return {
        type: 'html',
        content: options.softbreak
      };
    }
  },
  // ...
});

[parthshah31]

@js87zz

Thanks for your response. But I was more looking for a toMarkdown function that returns those as hard breaks. The above code didn't change the getMarkdown()'s result.

[parthshah31]

For example when I write in the wysiwyg

a
a
a

a

I want the get markdown to return the following spec-compliant result:

a\
a\
a\

a

[js87zz]

@parthshah31
Yes, there is a problem in WYSIWYG when using the soft break, because squire(our WYSIWYG editor used internally) adds br automatically.
There is no perfect solution for this issue in the current structure without totally changing our WYSIWYG.
It's not official API, but it can be a little better if you specify options as below.

var editor = new Editor({
 // ...
});

const default = editor.toMarkOptions.renderer;
const renderer = defaultRenderer.constructor.factory(default, {
  BR(node) {
    return node.previousSibling.tagName === 'BR' ? '  \n' : '\n\n';
  }
});

Object.assign(editor.toMarkOptions, { renderer });

However, as mentioned above, it is not a perfect solution.
We are aware of this limitation, and we are planning to replace our WYSIWYG Editor in the next major version to further upgrade the sync between Markdown and WYSIWYG.
Since it's an old issue but an important issue, I will make sure to reflect it in the next version of the work.
Thank you for your contributing!!

[Powersource]

Any news on this? Or recommendations on how to work around it? I'm currently rendering my markdown using remark-gfm (plugged into react-markdown) but if I write this in the wysiwyg editor

a


b

then the final rendering fails and just displays

a
<br> b

edit: not actually sure it's the same bug as this issue. i'm confused 🤔 something is not following the gfm spec at least

[Powersource]

I think I've come up with a workaround that works well enough for now for me, I'm filtering away BR tags with a regex in the onChange handler cobudget/cobudget@f184ee9

[eloise-mcintyre]

Is there any update on this? I'm using the next major version, and it's still broken