Repository navigation
A Markdown fence closes on its own length with no info string, and four spaces under a paragraph or inside a list item are prose - #341
Conversation
…ur spaces under a paragraph or inside a list item are prose The Markdown reader behind prose_regexp, which reads every document a prose rule selects and the pull-request and commit text the shim and --text hand it, disagreed with a CommonMark renderer in both directions. It dropped paragraph text. Any line indented four spaces was taken as indented code, so a continuation line under a list item, a bullet nested under an ordered item, and a lazy continuation of a paragraph were never read. CommonMark forbids indented code from interrupting a paragraph, and inside a list item counts the four spaces from where the item's text starts. It read code as prose. A fence closed on any line starting with three of its characters, so a three-backtick line inside a four-backtick fence ended it early, and so did a ```bash line inside an open ```sh block, although a closing fence may carry no info string. The fenced lines after it were reported as prose, and the fence the next closer opened ran on, so the rest of the file went unread. A fence now records its character, its length and the list column it opened under. It closes on a run of that character at least as long, followed by nothing but spaces, indented less than four past that column; a backtick run with a backtick in its info string is a code span and opens nothing. Indented code opens only after a blank line, a heading or a block that ended, and is counted from the innermost open list item's text column. Lists are approximated line by line, and the doc comment on of_document names what is not modelled: block quotes, a fence or code on an item's first line, the ordinal-1 rule for interrupting a paragraph, and a fence ended by its list item ending. A text file keeps its own reading: no indented code and no lists, with fences opening and closing at any indentation. It takes the new closing rule too, since the same ```sh block written there ended the same way. No existing test encoded the old behaviour. The reference table and its section say what a Markdown file's prose now is. Claude-Session: https://claude.ai/code/session_01TG5hbR4Re6gcEZTpBCBymc
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 8 minutes. View limit detailsLimit details: You’ve used the included review currently available. Review configuration: ⚙️ Run configuration
📒 Files selected for processing (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is
❌ Your patch status has failed because the patch coverage (98.59%) is below the target coverage (100.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #341 +/- ##
==========================================
+ Coverage 94.35% 94.37% +0.02%
==========================================
Files 46 46
Lines 22968 23091 +123
==========================================
+ Hits 21671 21792 +121
- Misses 1297 1299 +2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Prose rules read Markdown with a fence that closed on any shorter fence, and on a fence carrying an info string, and with every line indented four spaces taken as code. So list-item continuation lines, bullets nested under an ordered item, lazy paragraph continuations, and text after a four-backtick fence holding a three-backtick line were never judged. A
bash line inside an opensh block closed it, which flipped every fence after it and left the rest of the file unread.The reader now follows CommonMark §4.4 and §4.5. A fence closes only on a run of its own character at least as long as the opener, with nothing after it but spaces. A backtick fence whose info string holds a backtick is a code span. Indented code cannot interrupt a paragraph, and inside a list item the four spaces count from the column where the item's text starts. A lazy continuation line stays in its paragraph. Plain-text files keep their own reading (no indented code, no lists) but take the same closing rule.
Lists are approximated line by line. The doc comment on
of_documentlists what is not modelled: block quotes, a fence or code on an item's first line, the rule that only an ordinal-1, non-empty item may interrupt a paragraph, and a fence that ends because its list item ended.Tests: unit tests
an_indented_line_under_paragraph_text_continues_it,a_list_item_counts_its_indentation_from_its_text,an_indented_block_after_a_closed_list_or_a_heading_is_code,a_shorter_fence_inside_a_longer_one_is_its_content,a_fence_with_an_info_string_does_not_close_oneanda_fence_opens_and_closes_only_where_commonmark_saysinsrc/prose.rs, plus the CLI testa_prose_rule_reads_a_readme_by_the_lines_commonmark_calls_paragraphsintests/scan_cli.rs. docs/REFERENCE.md now says what a Markdown file's prose is.Differential check against markdown-it in CommonMark mode on a README of these cases: uphold now flags exactly the lines markdown-it calls paragraph text (3, 6, 8, 11, 16) and none of the fenced lines (20, 25).
https://claude.ai/code/session_01TG5hbR4Re6gcEZTpBCBymc