Repository navigation
feat: adjust lazy-continuation for block quotes and parse > correctly - #231
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
That's a lot of passing |
a59a0b6 to
9703f25
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9703f251a3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "Codex (@codex) review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "Codex (@codex) address that feedback".
| // A paragraph lexes the markers in its text itself | ||
| if (markersStack.lastOrNull() is ParagraphMarkerBlock) { | ||
| return |
There was a problem hiding this comment.
Handle paragraph quote markers after list indentation
When a block quote paragraph is nested at least four columns into a list, this early return assumes the inline lexer will recognize a continuation marker that it cannot see as such. For example, - > foo\n > bar produces a Markdown:> token for the second marker and renders literal > bar, because the inline lexer sees four leading spaces while the block constraints know those spaces belong to the list. Paragraph continuation markers need to be emitted or otherwise communicated using the parsed constraints rather than relying solely on inline lexing.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
This is a pre-existing bug that can be fixed in a separate MR
No description provided.