Support for Hard and Soft line breaks about mdast HOT 10 CLOSED

One more thing, do you have a specification on the parser? Like parsing strategy and things like that. I might in the future also write the parser part instead of using Cmark to parse.

from mdast.

The CM soft line break is a \n in a string. So if you have:

alpha
bravo

it would be represented as {type: 'text', value: 'alpha\nbravo'}.

The CM hard line break is represented here as a break node, as can be seen in this example

from mdast.

That makes sense, my case is different, because I am implementing mdast syntax tree in Swift, and the parser is cmark.

from mdast.

Do you think it would make sense to have these separated types for supporting AST implementations with different parsers?

Even though the underlying parser is different but the specification can be followed...

from mdast.

Cool that you are using mdast in swift! So you are writing something that maps cmark AST nodes to mdast nodes?

Do you think it would make sense to have these separated types for supporting AST implementations with different parsers?

If we have soft-break in CM and \n in mdast, that allows us to map between them, transform from one to the other.
What is the benefit of having soft-break as a separate node in mdast?

from mdast.

Here is where I got so far: https://github.com/hebertialmeida/MarkdownSyntax

It uses Cmark as a parser and I map to mdast AST. In the Tests folder, I believe almost everything is implemented, I do need to add tests for Node positions. Purely Swift, so it can run on macOS, iOS, Linux and Windows I believe.

What is the benefit of having soft-break as a separate node in mdast?

To be honest with you I am not sure about the benefits and I still figuring out if there are any... in my case I feel that make sense to have because CM has it, but another approach would be whenever CM find a soft-break I could append something like: Text(value: "\n") and I would lose the SoftBreak node. Right know I append a newly created SoftBreak node: Parser.swift#L87.

from mdast.

Awesome! Cool to hear that mdast is getting used in non-JS places!

The reason for having an AST (as opposed to a CST, which we are also working on), is that it is easy to manipulate. I think that letting people insert a line feed in a string (whether it’s a code span or text in a paragraph) instead of having to split on line feeds and insert softbreak nodes makes the AST easier to use!

CM has an AST, but that tree is typically only used to go to HTML, and not really exposed to programs that inspect and transform the tree. So it doesn’t matter as much that its harder to use.

You are free to do it differently of course though!

from mdast.

CM has an AST, but that tree is typically only used to go to HTML, and not really exposed to programs that inspect and transform the tree. So it doesn’t matter as much that its harder to use.

Yes, that is my point on having an AST on top of it, I'm glad I found mdast, that specification helped a lot. I will continue working on this implementation and if I have any suggestions or problems I will reach open a discussion. Thanks!

from mdast.

Fun, I’m currently working on a parser!

The parser is called micromark. ± 6 years ago I made remark (which includes a parser, but does more things) and mdast. Over the years it helped us well, but there is room for improvement. That’s why we’re working on a replacement. As this replacement will also probably last 6 years (or more?), it’s good to spend extra time on building it well.

While thinking about how parse Markdown properly, I found myself writing a spec on how to parse Markdown (call it “readme-driven development”), which is slightly different from the CM spec (because CM is defined as input Markdown -> output HTML).
So the spec for a parser is WIP, but interesting! Currently called the common-markup-state-machine!

from mdast.

That's really cool, thanks for sharing that!

from mdast.