In the course of resolving #45 and discussing #46, I uncovered that the Rust parser's representation of blocks is not well aligned with the spirit of the spec.
This change updates the block semantics of the Rust parser to align much more closely to the spec. Now, list blocks are broken out into individual items (previously sequential list items would accrue to a single block). Similarly, blanks are broken up by line (where previously they would accrue to a single block).
This revision gave rise to an opportunity to simplify parsing conditions significantly. Most notably: all sigil-specific code paths have been collapsed into one path.
In addition to the above changes, this change introduces two other meaningful updates:
We changed the representation of the underlying shared string to be thread-safe
A to_text_content() method was added for efficiently stringifying a block in a way that is aware of both sigils and leading whitespace
The revisions to the parser that were necessary to implement to_text_content() should set us up to easily revise things in the future if we decide that leading whitespace is significant for list blocks (per details in #31 and #46).
In the course of resolving #45 and discussing #46, I uncovered that the Rust parser's representation of blocks is not well aligned with the spirit of the spec.
This change updates the block semantics of the Rust parser to align much more closely to the spec. Now, list blocks are broken out into individual items (previously sequential list items would accrue to a single block). Similarly, blanks are broken up by line (where previously they would accrue to a single block).
This revision gave rise to an opportunity to simplify parsing conditions significantly. Most notably: all sigil-specific code paths have been collapsed into one path.
In addition to the above changes, this change introduces two other meaningful updates:
to_text_content()method was added for efficiently stringifying a block in a way that is aware of both sigils and leading whitespaceThe revisions to the parser that were necessary to implement
to_text_content()should set us up to easily revise things in the future if we decide that leading whitespace is significant for list blocks (per details in #31 and #46).Fixes #45