Roundtripping emphasis like plain text results in emphasis

[ChristianMurphy]

Subject of the issue

(____

is stringified as:

(\__\__

which changes the structure

Your environment

• OS: Ubuntu
• Packages: mdast-util-to-markdown 0.6.5
• Env: node v15.5.1, npm 7.3.0

Steps to reproduce

parse

(____

which has the structure

{
    "type": "root",
    "children": [
        {
            "type": "paragraph",
            "children": [
                {
                    "type": "text"
                }
            ]
        }
    ]
}

and stringify it:

(\__\__

the resulting markdown has a different structure than the original

{
    "type": "root",
    "children": [
        {
            "type": "paragraph",
            "children": [
                {
                    "type": "text"
                },
                {
                    "type": "emphasis",
                    "children": [
                        {
                            "type": "text"
                        }
                    ]
                }
            ]
        }
    ]
}

📓 comparing how the two pieces of markdown text are being parsed with https://spec.commonmark.org/dingus it appears in both cases it is parsed as expected.

Expected behavior

structure is the same

Actual behavior

structure is different

[ChristianMurphy]

Some other examples

[____

<____

-____

[github-actions]

Hi! This was marked as ready to be worked on! Note that while this is ready to be worked on, nothing is said about priority: it may take a while for this to be solved.

Is this something you can and want to work on?

Team: please use the area/* (to describe the scope of the change), platform/* (if this is related to a specific one), and semver/* and type/* labels to annotate this. If this is first-timers friendly, add good first issue and if this could use help, add help wanted.

[andymatuschak]

I ran into this tonight and briefly looked into it. I fear it'll be somewhat tricky to fix. My understanding is that what we really want here is to make the "safe escape" semantics, as they apply to _ and *, obey the delimiter run rules described here in the CommonMark spec. That is, the reason that these underscores should not be escaped is that they will not be interpreted as emphasis characters. Unfortunately, I don't think those delimiter run rules can be encoded in a regular expression—or at least, it'd be one gnarly regex! I wonder if a facility for a more sophisticated safe matcher will be necessary.

[wooorm]

Did you find a real-world human-authored example where this was going wrong? The examples by @ChristianMurphy were generated by a computer, and all look a bit weird.

(edit: whoops I was writing a whole thing, but I think I got a solution, so disregard it)

[wooorm]

@andymatuschak Would love to get access to the failing input you had, to see if they now work with the simple solution in GH-43.

[andymatuschak]

I noticed this with text with faux "fill in the blank" spans:

Once activated, a service worker ______, then transitions to idle. From that state, it’ll handle fetch or message events until it eventually terminates.

[wooorm]

Thanks, added that as a test