Repository navigation
Conversation
) When a paragraph contains only link reference definitions and is followed by a setext heading underline, the setext block start stripped the definitions from the paragraph before deciding not to create a heading. The emptied paragraph was then skipped by removeLinkReferenceDefinitions and rendered as <p></p>. Parse the definitions on a copy of the paragraph content, so the paragraph is only changed when it actually becomes a heading.
Member
|
Superseded by #313 |
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
2 participants
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 the first point of #262.
gave
<p></p>followed by<hr />. It now gives only<hr />.Cause. The setext heading block start in
lib/blocks.jsstrips leading link reference definitions fromcontainer._string_contentbefore it checks whether any heading text remains. When nothing remains, no heading is created, but the paragraph has already been emptied.removeLinkReferenceDefinitionsonly unlinks paragraphs whose definitions it parsed itself, so this paragraph survives and renders as<p></p>.Fix. Parse the definitions on a local copy of the content. The paragraph is changed only when it actually becomes a heading. Otherwise it keeps its definitions, and
removeLinkReferenceDefinitionshandles it like any other paragraph.Not changed. The second question in #262, whether
---here should be<hr />or<p>---</p>(which cmark 0.30.2 gives), is left as is. The===case already gave<p>===</p>and still does.Tests. I added 4 regression tests to
test/regression.txtcovering---,===, both in one document, and a definition followed by real heading text.npm testpasses with 752 tests. Without the change inlib/blocks.js, 2 of the new tests fail.Relation to #313. #313 also fixes this, as a side effect of fixing #298, the definition-order issue. This PR does not fix #298. This PR is a smaller alternative scoped to #262 only: +8/−11 in
lib/blocks.js, with no change to heading sourcepos. If #313 is preferred, the extra regression cases here may still be useful there, and I'm happy to close this one.