Option to use two spaces instead of backslash for hard line break

[vwkd]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Problem

I'd like to use two spaces instead of a backslash for hard line breaks.

Currently, remark-stringify seems to default to a backslash without any option to use whitespace instead.

Related issues #249 and syntax-tree/mdast-util-to-markdown#30.

Solution

An option to use multiple spaces instead of a backslash for hard line breaks.

It seems the serialization is done by mdast-util-to-markdown which hardcodes the backslash in lib/handle/break.js#L31.

Alternatives

None.

[wooorm]

Why?

Alternatives

None.

Well, the alternative is the current state, which works everywhere?

[vwkd]

Personally, it's visual preference. I prefer two spaces instead of a backslash. If the CommonMark spec explicitly defines it, IMO it should justify the existence of an option.

[wooorm]

There is a significant downside though: they are typically not visible, and tools typically remove them.

CM allows many things. Not all of them are good.
It is not a goal of these projects to allow serializing to all possible input.
It is a goal to create portable markdown.

[vwkd]

I understand the visibility argument and also if this behavior is not the preference of this project.

The CommonMark spec might not be ideal, but the behavior is defined and is already out there. For example, the tools I'm using use spaces by default. IMO there should at least be the possibility to the user of this project to use what is defined in the spec, even if it's not ideal. It can be turned off by default, be discouraged, etc... but possible.

[wooorm]

What tool are you using?
And why does it matter that this tool has a different, but equivalent, output?

[vwkd]

For example, turndown uses spaces by default for hard line breaks.

It's personal preference. Why give the option to choose between * and _ for emphasis or * and - for bullet points if these are equivalent?

It's fine if this tool has preferences and encourages specific default values. But the user should have the option to change them.

[wooorm]

turndown

The unified projects can also do what turndown does btw. In my opinion, rehype-remark is better. Even if you don’t think one is better/worse than the other, having one tool instead of several might be beneficial.

Additionally, if you choose to use two projects, this project is never going to match that project exactly. So why does this particular case matter?

It's personal preference

I argue that it isn’t just preference: trailing spaces have clear problems that escape doesn’t.
For * vs _, or vs -, there aren’t clear problems with choosing one or the other.

But the user should have the option to change them.

I disagree that we need to let humans optionally shoot themselves in the foot.

Historically, CM was not widespread, and so there was a commonmark option. The default was to use trailing spaces but only with that option, escapes were used.

Similarly, it is also possible to use GFM tables without initial and final pipes:

a
:-
b

a
b

As this format is frail and hard to read, and so options for this have been removed.

[vwkd]

I agree with the preferences. But I'd still argue for giving the conscious user the (generally not preferrable but in certain individual cases desirable) option that they explicitly asked for after very well confirming they know how to not "shoot themselves in the foot".

As mentioned, it can be turned off by default, can have big warning labels printed on it, etc. But for those that do know the risks, let them choose what's right for them.

I don't believe there exists an universal right and wrong. Perhaps there's the same right and wrong for most people, but then there are always some cases where the line is not so clear. This option should be for them. And the rest can be reasonably protected by it being turned off by default and burried in discouraging warning signs.

[wooorm]

I’m leaning against this.

I only see downsides to that style.

Perhaps other people have opinions, @Murderlon @ChristianMurphy @remcohaszing

[remcohaszing]

I have mixed feelings about this. I agree it's nice to support different syntaxes for formatting the output. On the other hand I believe using trailing spaces for syntax is the absolute very worst part of the commonmark spec that nobody should ever use.

IMO the best argument for supporting this, would be a practical example of a tool that only supports parsing line breaks using trailing spaces. However, the only argument given is that it's personal preference.

It's true there's not a universal right or wrong here. However, I consider spaces for line breaks really bad. I think it's in a way similar to the JavaScript with statement. It exists, and parsers should support it. However, it's really bad, and you should avoid it.

Also note that line breaks should typically not occur in text anyway. The only legitimate use case that comes to mind is poetry / song lyrics.

[mattly]

so it sounds like you're ignoring the published specification for the thing your project is basically infrastructure for based on ... personal taste?

[wooorm]

Who are you? What have you ever done for this project? Why do you attack people that maintain it?

There is an entire discussion with many valid points and you ignore them. Discuss those or leave.

[remcohaszing]

Nobody is ignoring the specification here. According to commonmark, both syntaxes are equivalent. remark parses those correctly and treats them as equivalent. This is about output formatting, which is not a part of the spec.

[wooorm]

I think trailing spaces are a really bad idea. I don’t see a good reason to support it. Even if there was say a super widely used markdown parser that supports spaces but not slashes, I’d lean to saying: well, they should support CM. That’s what everyone expects. Still, if there are good reasons, I’d like to hear it, and only then I might be open to it.

There is a way to support them: pass your own handler. That‘s supported and fine. If you really want it.

I’m closing this, as of yet, I don‘t think this is a good idea.