You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The only reference to precedence I could find in the spec is this:
If there are multiple matching reference link definitions, the one that comes first in the document is used. (It is desirable in such cases to emit a warning.)
The issue is that when you define a LRD (link reference definition) in a Setext heading (or a probable Setext heading*), this link will populate the refmap before any paragraph LRDs are parsed, which occurs at the document finalization step.
*A paragraph interrupted by a setext heading underline that only contains links, thus creating an empty <p>, which is immediately unlinked from the AST.
Example inputs:
[x]: fizz
[x]: buzz
===
[x]
has an href=buzz,
Whereas
[x]: fizz
[x]: buzz
[x]
has an href=fizz.
My interpretation of the spec is that both should result in href=fizz as that is the first LRD.
Assuming this is a bug, my idea of a fix would be to use a modified Parser.refmap where it has an Map<number, Array<LRD>> and the key would be the line number of the containing paragraph (sourcepos[0][0]), as the exact lines don't matter as long as the array is populated in-order.
So if this was the input
[line1]: a
[line2]: b
rest of paragraph
[line5]: e
===
would have the map
{
5: [e],
1: [a, b]
}
(where a, b, e are objects of typedef LRD {destination: string, title: string, label: string} with map def Map<number, Array<LRD>>)
Then setext headings' block start and document finalization can occur in the order they do, but could add another step after document finalization. E.g.
Something like that should work, its just a matter of adding to the placeholder refmap correctly, which is a bit trickier since inline.js needs a reference to it and mutates it.
The text was updated successfully, but these errors were encountered:
The only reference to precedence I could find in the spec is this:
The issue is that when you define a LRD (link reference definition) in a Setext heading (or a probable Setext heading*), this link will populate the
refmap
before any paragraph LRDs are parsed, which occurs at the document finalization step.*A paragraph interrupted by a setext heading underline that only contains links, thus creating an empty
<p>
, which is immediately unlinked from the AST.Example inputs:
has an
href=buzz
,Whereas
has an
href=fizz
.My interpretation of the spec is that both should result in
href=fizz
as that is the first LRD.Assuming this is a bug, my idea of a fix would be to use a modified
Parser.refmap
where it has anMap<number, Array<LRD>>
and the key would be the line number of the containing paragraph (sourcepos[0][0]
), as the exact lines don't matter as long as the array is populated in-order.So if this was the input
would have the map
(where
a, b, e
are objects of typedef LRD{destination: string, title: string, label: string}
with map defMap<number, Array<LRD>>
)Then setext headings' block start and document finalization can occur in the order they do, but could add another step after document finalization. E.g.
Something like that should work, its just a matter of adding to the placeholder refmap correctly, which is a bit trickier since inline.js needs a reference to it and mutates it.
The text was updated successfully, but these errors were encountered: