Add tightness and marker type to Tag::List - #1083
Open
SabrinaJewson wants to merge 1 commit into
Open
Conversation
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.
Add fields
tightandmarker_typetoTag::Listto allow inspecting these two properties of the list. This is a breaking change.These bits of information cannot otherwise be derived from the Markdown source. In particular,
pulldown-cmarkgenerates the same sequence of events for"- > first\n- > second"and"- > first\n\n- > second", even though the former is tight and the latter is loose.My use case is for cmarker.typ, which converts Markdown into Typst, and currently does not account for the tightness or looseness of lists for this reason.
The variants of
ListTypewere named after the Unicode names of the characters.There is currently a logical invariant that
startisSomeif and only ifmarker_type.is_ordered(). It would be possible to redesign the library such that the type system forbids this; for example:However, in favour of making the change minimally intrusive, I did not use this design.