-
-
Notifications
You must be signed in to change notification settings - Fork 43
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
Full reference links should have a fallback #20
Comments
@rubys Sorry for the slow reply! The reason that this isn’t represented in the AST is that it is based on the output. Markdown stringifies those differently than HTML. However, if |
A PR, with updated test cases can be found at #21 |
Oh sorry, missed it! |
Thanks! It looks like I will have a follow-on issue that will require a slightly bigger change (not so much in terms of lines of code, but affecting not only docs, but also a small change to The issue is that remark-parse's mdast tree for potential link or image reference is lossy... for example, the identifier is converted to lowercase. The fix I suggest is that callers to Thoughts? |
In fine discussing this! It does sound like a lot of logic, couldn't we perhaps add a new 'reference' property to references that define the value that was used, next to reference type? |
I don't understand the 'inconsistent trees' part, but looking into it, I agree that that is a better approach. Looking at the VFile content, even when augmented by position information, doesn't guarantee that the original source was markdown. Conceivably somebody could have a unified pipeline where there was some other source format which is subsequently converted first to markdown and then to HTML. Unlikely, but possible. So the outline for the set of PRs I will be developing: first to MDAST itself describing the new property to all three of LinkReference, ImageReference, and FootnoteReference. Then there will be a PR for remark-parse to add this property in those three cases. And finally a PR to md-to-ast to look for this property and use it as the fallback if it is present, and if not, continue with the current logic. Anything I'm missing? |
This change adds support for a new optional field on the association mixin, used by `definition`, `footnoteDefinition`, the `Reference` mixin (in turn used by `linkReference`, `imageReference`, and `footnoteReference`). The value of the `label` field must, when present, hold the non-normalised value of the `identifier` field. This allows references that are not association with definitions to be represented correctly as raw text again. Closes GH-23. Related to syntax-tree/mdast-util-to-hast#20 Related to syntax-tree/mdast-util-to-hast#21 Related to syntax-tree/mdast-util-to-hast#22 Related to remarkjs/remark#346
Closes GH-22. Related to GH-20. Related to syntax-tree/mdast#23. Related to remarkjs/remark#346. Co-authored-by: Sam Ruby <[email protected]>
Closes GH-22. Related to GH-20. Related to syntax-tree/mdast#23. Related to remarkjs/remark#346. Co-authored-by: Sam Ruby <[email protected]>
Background: I'm converting node.js from marked to unified/remark/rehype, and found a regression. It seems that mdast-util-to-hast intentionally does not have a fallback for link references:
mdast-util-to-hast/test/link-reference.js
Lines 22 to 44 in f2e3ec5
This varies from the commonmark spec and other implementations:
https://spec.commonmark.org/0.28/#full-reference-link
https://spec.commonmark.org/dingus/?text=[foo][bar]
Is there a reason for this deviation?
The text was updated successfully, but these errors were encountered: