Skip to content
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

Closed
rubys opened this issue Jul 24, 2018 · 7 comments
Closed

Full reference links should have a fallback #20

rubys opened this issue Jul 24, 2018 · 7 comments
Labels
🗄 area/interface This affects the public interface 💪 phase/solved Post is done 🧑 semver/major This is a change 🐛 type/bug This is a problem

Comments

@rubys
Copy link
Contributor

rubys commented Jul 24, 2018

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:

t.deepEqual(
to(
u(
'linkReference',
{
identifier: 'delta',
referenceType: 'full'
},
[u('text', 'echo')]
)
),
u(
'element',
{
tagName: 'a',
properties: {
href: ''
}
},
[u('text', 'echo')]
),
'should not fall back on full `linkReference`s'
)

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?

@wooorm
Copy link
Member

wooorm commented Aug 5, 2018

@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 mdast-util-to-hast produces an AST that’s stringified differently than how commonmark/github does it, it’s a bug. It shouldn’t deviate, and I welcome a PR!

@rubys
Copy link
Contributor Author

rubys commented Aug 5, 2018

mdast-util-to-hast does indeed produce an AST that is stringified differently than how commonmark/github does it. You can quickly verify this by entering [foo][bar] in the commonmark dingus page.

A PR, with updated test cases can be found at #21

@wooorm
Copy link
Member

wooorm commented Aug 5, 2018

Oh sorry, missed it!

@wooorm wooorm closed this as completed in 742a780 Aug 5, 2018
@rubys
Copy link
Contributor Author

rubys commented Aug 6, 2018

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 remark-rehype).

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 mdast-util-to-hast can optionally pass the file.contents as an option. If that option is present, and position information is present, and an undefined reference is encountered, then the undefined reference will be replaced with the original text from the file contents. If any one of these conditions is not met, the current fallback logic will be used.

Thoughts?

@wooorm
Copy link
Member

wooorm commented Aug 6, 2018

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?
The downside is that this could result in inconsistent trees, but maybe we could work around that somehow?

@rubys
Copy link
Contributor Author

rubys commented Aug 7, 2018

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?

wooorm added a commit to syntax-tree/mdast that referenced this issue Aug 31, 2018
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
wooorm added a commit that referenced this issue Nov 11, 2018
Closes GH-22.
Related to GH-20.
Related to syntax-tree/mdast#23.
Related to remarkjs/remark#346.

Co-authored-by: Sam Ruby <rubys@intertwingly.net>
wooorm added a commit that referenced this issue Nov 11, 2018
Closes GH-22.
Related to GH-20.
Related to syntax-tree/mdast#23.
Related to remarkjs/remark#346.

Co-authored-by: Sam Ruby <rubys@intertwingly.net>
@wooorm wooorm added ⛵️ status/released 🐛 type/bug This is a problem 🗄 area/interface This affects the public interface 🧑 semver/major This is a change labels Aug 11, 2019
@wooorm wooorm added the 💪 phase/solved Post is done label Apr 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🗄 area/interface This affects the public interface 💪 phase/solved Post is done 🧑 semver/major This is a change 🐛 type/bug This is a problem
Development

Successfully merging a pull request may close this issue.

2 participants