Repository navigation
Provide offset/lengths for nodes #1287
Description
There are some places in the analysis server that could benefit from parsing Markdown. For example Dart-Code/Dart-Code#3330 relates to code blocks no longer being highlighted in VS Code when Semantic Tokens are enabled (Semantic Tokens replace the old regex-based colouring, but the server doesn't produce highlights regions for the code blocks nested inside markdown).
Parsing the comments using this library produces code elements for the things I'd like to highlight, but it appears the offset/length are not provided on the nodes so it's not possible to produce a highlight region for that code.
If this seems like a reasonable extension, I'm happy to have a go at implementing it if someone is happy to provide pointers and/or reviews. Thanks!
Reacted by crkit-chan, Absaar, Felipe Morschel, Stephen Vaudreuil and Jonas Finnemann Jensen
Reacted by crkit-chan
Activity
srawlins commentedon May 17, 2021
This is in the works. I hope to land it this quarter (in the next 6 weeks). It involves a huge refactoring of how markdown is parsed; currently there is no Markdown source parse tree; only an output HTML AST.
DanTup commentedon May 17, 2021
Neat! I did wonder if the current AST might cause issues for non-HTML uses, so this sounds ideal. Thanks!
frmatthew commentedon Aug 13, 2021
Any update on this issue? Thanks.
srawlins commentedon Aug 19, 2021
My teammate and I with whom I planned to work on this had a lot of non-overlapping vacation this summer, so I didn't get to land anything in June as I hoped. My new target is end of September. 🤞
DanTup commentedon Jan 18, 2022
@srawlins out of interest, is this still on your radar?
srawlins commentedon Jan 18, 2022
Oof, it is, but it keeps getting bumped by other slightly higher priority projects. :/ I should not announce a new target date.
DanTup commentedon Jan 18, 2022
lol, I know the feeling. It's not urgent to me, it's just useful to know if it may be on the way in the near-term or not :-) Thanks!
crkit-chan commentedon Jan 5, 2024
2024 - Any updates yet?
Concerning Issue #3648 - Comment References
I would really appreciate this, since this is the reason that documentation comment references cannot be parsed.
Since this is a pretty big bug, I think this issue deserves more attention.
For me, it is one of the only problems with the otherwise nearly-perfect Dart extension for VSCode.
Note
This works in JavaScript, maybe something could be copied over from that?
srawlins commentedon Jan 5, 2024
2024 - No updates.
I would appreciate it as well. Sorry, it has not made it to the top of our priorities.
[markdown] track offset/length for inline `code` spans (dart-lang#1287)
FMorschel commentedon Aug 17, 2026
I opened #2530 that adds
offset/lengthtracking to inline code spans (`code`), addressing this issue for that case. It's intentionally missing some cases and not a complete fix for every node/context, yet:Offsets are populated for code spans in top-level paragraphs and atx headers — the common cases for things like dartdoc comments.
Offsets are still
nullfor code spans nested inside constructs that rebuildLinecontent from a stripped source line — currently blockquotes, list items, footnote definitions, and GitHub alert blocks. For example:The span itself still renders correctly (blockquotes/lists fully support inline markdown); only the position metadata is missing there. This isn't a correctness bug —
ContentOffsetMapper.map()deliberately returnsnullrather than a guessed/wrong offset whenever a contributingLinedoesn't carry a known source offset.This is because block syntaxes like
BlockquoteSyntax,*ListSyntax,FootnoteDefSyntax, andAlertBlockSyntaxconstruct newLines from a marker-stripped substring (e.g.Line(currentLine.content.substring(markerEnd))) without passing along the corresponding sourceoffset. Each of these syntaxes already knows how many characters it stripped, so propagatingoffset: currentLine.offset == null ? null : currentLine.offset! + markerEnd(adjusted per syntax) would fix this.I've decided to land the paragraph/header case first and follow up with nested-block offset propagation separately, since it touches several block syntaxes and I think it might be easier to review these changes separately.
Also, keep in mind that the block-level
codeis already handled (see dart-lang/sdk#63739 and related issues for more info).[markdown] track offset/length for inline `code` spans (dart-lang#1287)