Setext Heading LRDs take precedence over Paragraph LRDs

已关闭
  • 哪里不对？
#298 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

@cpruijsen 已经在做这个了。

开始于 2026年10月12日。

  • #313 来自 @cpruijsen —— 未关闭
  • #314 来自 @afifm561 —— 未关闭

评估

难度
4/5
预计耗时
3-5 天
新手友好度
38/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
停滞
技术栈
javascript
领域
compilers

调研方向

重现这两个示例，并检查 Parser.refmap、inline.js 和文档最终化步骤，以追踪 Setext 和段落 LRD 何时被记录。验证如何应用建议的排序，同时不破坏 inline.js 的变更。完成标准是：重复标签始终解析为文档顺序中的第一个 LRD，包括 Setext 标题的情况。

由索引模型根据 Issue 内容生成。

描述

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.

/**
 * @param {Map<number, Array<{destination: string, title: string, label: string}>>} unorderedRefmap
 */
function getFinalRefmap(unorderedRefmap) {
  const sortedKeys = [...unorderedRefmap.keys()].sort((a, b) => a - b);
  const finalRefmap = {};
  for (const k of sortedKeys) {
    const values = unorderedRefmap.get(k);
    for (const v of values) {
      if (!finalRefmap[v.label]) {
        finalRefmap[v.label] = {destination: v.destination, title: v.title};
      }
    }
  }
  return finalRefmap ;
}

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.

主要语言
JavaScript
星标
1.6k
派生
234
平均合并
1 天 27 分钟
30 天内合并 PR
1

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

commonmark/commonmark.js 的其他 Issue

查看 commonmark/commonmark.js 的全部 Issue

相似的 Issue

更多 JavaScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。