fix(convert): move a mark's edge whitespace outside its delimiters - #215
Merged
Merged
Conversation
read trimmed the whitespace at the edge of a bold, italic or strikethrough span and did not put it back, so "<strong>bold </strong> next" read as "**bold**next" and published as one word. The editor leaves a space typed at the end of a bold run inside the run, so this shape is common. The whitespace now moves outside the delimiters: "**bold** next". It cannot stay inside, since CommonMark refuses "**bold **" as emphasis. A mark holding only whitespace rendered as "****" and now renders as the whitespace. A <br /> at a mark's edge was dropped and now moves out with the rest. Where moved whitespace meets whitespace beside the mark, one space is kept, and whitespace before a hard break is trimmed, since storage loses both on the next publish and the Markdown would not be a fixed point. The last also fixes "a <br />" reading as three trailing spaces rather than two. The split-marks golden recorded the bug: its partly-bold link case lost the space after "a". Fixes #204.
The whitespace renderMark moved outside a mark was trimmed again by any wrapper Markdown has no syntax for, so coloured bold text (a <span> around a <strong>) still read as "**bold**next", and <u>/<sup> lost their edge spaces outright. Such a wrapper now returns its run untrimmed and leaves the whitespace to the run around it. Link text was trimmed the same way, so "<a>see </a>here" read as "[see](url)here". The whitespace now stays inside the brackets, where Markdown allows it and publishes it back. A heading is one line, so a hard break in one, now reachable from a break at a bold run's edge, ended it and published the rest as a paragraph. A break in a heading stays a literal <br />. renderInlineRun builds into a byte slice rather than concatenating strings, which was quadratic in a paragraph's inline children, and renderMark trims each edge once. The table property test now generates a space at a mark's edge, from a stream of its own so every existing seed's table is otherwise unchanged, and follows such a mark directly with the next piece of text. Its model treats a space at a mark's edge as the same inside or outside, and two runs of one mark separated only by a space as one run, since both look the same in Confluence. With the converter from before #204 it fails at seed 5.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #204.
read/exporttrimmed the whitespace at the edge of a bold, italic or strikethrough span and never put it back. So<strong>bold </strong>nextread as**bold**nextand published as one word, as on the incident table in #204 ("features for13.5h"). The editor leaves a space typed at the end of a bold run inside the run, so this is a common shape.What changes
renderMark): whitespace at a mark's edge, Unicode whitespace included, moves outside the delimiters:**bold** next. It can't stay inside, because CommonMark refuses**bold **as emphasis.<span>,<u>,<sup>) no longer trim their edges. Without this, coloured bold text would still read as**bold**next.[see ](url)here). Markdown allows that and publishes it back.****; it now renders as the whitespace.<br />at a mark's edge was dropped; it now moves out with the rest.a <br />read as three trailing spaces and then two, so the Markdown wasn't a fixed point.<br />.Testing
storage2md/mark-edge-whitespacecase: the issue's three rows, a leading space, a no-break space, nested marks, a whitespace-only mark, breaks at a mark's edge, a coloured<span>and<u>, links, headings, and the incident table cell. It also runs through the round-trip fixed-point check.split-marksgolden andTestStorageToMarkdownCoalescesSplitMarkshad recorded the bug (**a**[b…for<strong>a </strong><a>b…); both are corrected.main's converter it fails at seed 5; with this PR, all 3000 seeds pass, as did a 60s fuzz run (~200k execs).make checkpasses.Left for later
main. Since this change a<br />at a bold run's end followed by another<br />hits it too, where before the first break was simply dropped.a**(b)**) still fails CommonMark's other flanking rule and reads back as literal asterisks. This PR doesn't change that behaviour.