Beaker: Markdown parser line-breaks

[johanbove]

Describe the bug
The markdown parser does not take "double-space" line-breaks into account and adds <br> on every line-break.

To Reproduce
Steps to reproduce the behavior:

1. Create a markdown.md file
2. Write a sentence and add a newline
3. Notice how the parser is adding a <br> on every newline - unexpected
4. Write another sentence and end the line with double spaces
5. Notice how the parser is still adding a <br> on this line - expected

Expected behavior
The markdown parser should not add a newline on every line-break. Only when the line ends with double spaces, should the parser add a <br>.

Screenshots
Beakerbrowser parser result:

Visual Studio Code markdown parser result:

Desktop (please complete the following information):

• OS: Windows 10
• Browser: Beaker Browser
• Version: 1.0.0-prerelease.1

Electron: 9.0.0-beta.22
Chromium: 83.0.4103.34
Node: 12.14.1
Hyperdrive: 10.10.3
API: 0
Daemon: 1.13.6
Client: 1.14.5
Schema: 1.9.1
Fuse Native:
Fuse:

Test file:

Additional context
Would be good to make the markdown parser configurable.

[pfrazee]

Making it configurable is a little difficult. For now I'm open to discussing what the default should be.

[johanbove]

I'd like to make the "hard-wrapper" text paragraphs default as first described by "Daring Fireball" John Gruber

The implication of the “one or more consecutive lines of text” rule is that Markdown supports “hard-wrapped” text paragraphs. This differs significantly from most other text-to-HTML formatters (including Movable Type’s “Convert Line Breaks” option) which translate every line break character in a paragraph into a <br /> tag.
When you do want to insert a <br /> break tag using Markdown, you end a line with two or more spaces, then type return.
Yes, this takes a tad more effort to create a <br />, but a simplistic “every line break is a <br />” rule wouldn’t work for Markdown. Markdown’s email-style blockquoting and multi-paragraph list items work best — and look better — when you format them with hard breaks.

[dym-sh]

github inserts <br> on every line-break tho

line1
line2
line3

this makes unnecessary long paragraths more readable,
plus spotting double spaces on line-ends is not particularly enjoyable task

imo, github-favoured-markdown is a better variation, more suited for intended use

[johanbove]

@dym-sh Thanks four your point of view, but I disagree.

My counter use-case is plain text files, as .md files, which I created a collection of, which have manual line-breaks to cope with the recommended "max-column" width of 70 characters. This looks great in consoles and reads fine in most clients. However, when parsed to HTML, the normal rendering of a line, according to the original Markdown spec by John Gruber, should be that the text renders without break tags, to make best use of the full screen width in browsers.

So different use-cases would require this to be configurable.

So if users could select which Markdown parser to use then this would fix my use-case and allow users to decide.

So perhaps this issue should be a feature-request and not a _bug_.

[dym-sh]

if you have them as .txt anyways,
converting straight to .html will be just a little more work,
by simply replacing \n\n with <p>

[johanbove]

@dym-sh Sorry, I had to be more specific. With "plain text", I also included .md files.

[johanbove]

@dym-sh Here's a test markdown file to check how GitHub is rendering Markdown to HTML and it - fortunately for me, shows GitHub is following the "hard-wrapper" convention.

[pfrazee]

I think defaulting to the original spec is a fair thing to do for now because this is such a matter of preference, but I do agree making it configurable would be wise. The question is: how do we store that config? Should we consider adding front-matter support?

[pmario]

text/markdown is specified at RFC7763 The text/markdown Media Type

It mentions markdown-variants in chapter 10

Some variants are registered / described in RFC7764 Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations

CommonMark is mentioned on page 14. CM contains a spec for space-space-nl "hard linebreaks"

... Depending on the library, that is used, it may be possible to select different variants. IMO it depends on the personal usecase, which setting makes sense.

[johanbove]

how do we store that config?

I am not aware of the current options of where users can configure "stuff". I would store the Markdown _options_ in the index.json file for the Hyperdrive the Markdown files are located in.

Should we consider adding front-matter support?

Yes please. Similar to how Jekyll parses YAML front-matter would be great, but would be a little out of scope of line-break issue, no? It would make it super easy to generate HTML straight from the markdown files.

Refs:

• https://jekyllrb.com/docs/front-matter/
• https://jekyllrb.com/docs/configuration/front-matter-defaults/

[pfrazee]

Closed this issue to help me track my workload (changed the default to reflect the original spec).

Let's open a new issue to discuss configuration. @johanbove to answer your question, the challenge is that individual files need to carry their settings sometimes. Consider, for instance, an app rendering .md from other drives (like the microblogging app). It needs to know which setting the file is using when it calls beaker.markdown.toHTML(str)