-
-
Notifications
You must be signed in to change notification settings - Fork 170
Inline sourcepos fixes. #542
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Run on Fri Feb 28 05:30:17 UTC 2025 |
3ff5374 to
4681adf
Compare
|
/run-bench |
3560efb to
997197c
Compare
Pretty unsure about the "+ extra" but we'll see!
For consistency with other inlines, we should include the opening and closing $ / $$ / $`; there shouldn't be characters in the source document not covered by sourcepos.
Need to check the other kind.
Need to set the inner text sourcepos, as well as propagate any rewind adjustments to previous nodes' sourcepos.
This one will be a bit of a pickle, and entails differing from cmark-gfm (which currently gives these "-4:0" sourcepos ends for the list and last item on the same test).
Test some more content literals, too.
Also test text content of links, images, frontmatter, and support testing both text and children (since many nodes have both).
997197c to
642ba7b
Compare
|
|
I think the better fix for 8964f32 is to remove the paragraph, as one doesn't actually exist. |
|
Dang, some serious work into this. Nice job @kivikakk! 🚀 |
|
Thank you! Just got the last block issues to fix (which afaict are all the one issue, also present upstream), and then we might have full, complete sourcepos! |
|
Dang. Super nice! |
|
@kivikakk I don't think |
|
Indeed, it intentionally did not! I'll do a release. Keep in note there are still outstanding block-level cases. |
|
Thanks! 🚀 I have a specific bug open in our code on inline code, so want to finish that off.
No problem - I don't think any of the block-level ones that were working are now broken, so it shouldn't be an issue. |
sourceposfor two link types #478.sourceposis Unicode-naïve. #495 — not by doing anything, but by resolving that we can only really use byte-oriented sourcepos when referring to the source document, and being careful when we transform the source in any way while interpreting it (such as with smart punctuation). Anything else is making stuff up.HtmlInline(and possibly other inlines) incorrect end line calculation #501.sourceposnot correct for inline code #503.Aim is to fully address Fix inlinesourceposlisted insrc/tests/sourcepos.rs. #541.cmark-gfmwe match. Does upstreamcmarkalso report them that way?sourceposis incorrect for<script>tags #448,sourceposfor description lists not correct #502, Incorrectsourceposfor a html comment ofHtmlBlock#507. commonmark/cmark@3460cd8 doesn't get<script></script>right and I assume not others either.Still to do:
To be merged after 0.36.0 release; no voy a publicar esto un viernes ..!