oxidecomputer / oxidecomputer/prettier-plugin-asciidoc
A shorthand xref spanning a source line break is invisible to our inline reader until reflow joins it
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
Found by the reparse gate (format, re-read the output with our own reader, compare) running over the vendored corpus: links_test.rb#xref using angled bracket syntax with multi-line label inline with text.
input : "Want to learn <<tigers,about\ntigers>>?\n\n[#tigers]\n== Tigers\n"
output: "Want to learn <<tigers,about tigers>>?\n\n[#tigers]\n== Tigers\n"
Our inline reader mints no xref node for the input: the shorthand's bracket text spans a source line break and no rule matches across it, so the paragraph is one text node holding the literal <<tigers,about tigers>>. Asciidoctor does mint the reference, because sub_macros runs over the paragraph's joined text and InlineXrefRx is not line-anchored. Reflow then joins the two lines, and the SAME bytes now read as a real xref to us as well.
The render does not change (both sides render the cross reference), and the printed bytes are the ones the author wrote, so nothing is corrupted today. What is wrong is the SOURCE reading: for the length of one source line break our AST disagrees with the oracle about whether a construct is there at all.
Two consequences worth the issue:
- It is a conformance divergence in its own right: any decision keyed on "is this text or a reference" is wrong for the unjoined spelling. The escaped-text sibling (
<<a,\+[x]+`>>` split across lines) is the same shape. - It is a false positive for a verify-and-retry printer. A printer that decided a join by re-reading its own output would refuse this join forever, because the re-read legitimately differs, and it would refuse it for a reader gap rather than for a hazard.
Same class as the constrained-span rules that are line-anchored where the oracle's gsub is not; distinct from #78, which is about a macro whose text we DO read and whose interior newline we then collapse.
Fix direction: the shorthand xref rule (and the other bracket-text macros) should match over the paragraph's joined text the way sub_macros does, or the tokenizer should be handed the block's text rather than a line.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with links_test.rb#xref using angled bracket syntax with multi-line label inline with text and trace the inline reader alongside sub_macros and InlineXrefRx. Check the reparse gate and the escaped-text sibling case; done means the source spanning a line break produces an xref node consistently with the oracle without changing rendered output.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- developer-experience, tooling
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100