fix: report inline columns as written inside an escaped table cell

[akiomik]

Closes #403.

The defect

comrak unescapes a table cell before it parses the cell's inlines, so every \|
written earlier in the cell drops a byte from the string the inline parser
measures sourcepos against. Every inline after the escape is recorded one
column to the left of where it was written, and one more for each further
escape. The rules forwarded that unchanged, so the caret landed on the wrong
character.

| a | b |
| --- | --- |
| x\|y `` pad `` | c |
| x\|y [ t ](http://e.com) | c |
| x\|y ** b ** | c |
| x\|y <br> | c |
| x\|y http://e.com | c |

The inline starts at column 8 on every row. Before, mado reported column 7 for
MD038, MD037, MD033 and MD034, and column 8 for MD039 — which #403 read as MD039
being unaffected. It is not: MD039 reports the link's text, which is at column
9, so it was shifted by one like the rest and only looked right against the
issue's yardstick. All five now report the column the character was written at.

\| inside the inline shifts its end one further than its start, and both are
put back independently.

The fix

Document records, for each line where the two columns part company, which
column comrak's column was written at, and written_position maps one to the
other. The table is built from the cells' own sourcepos, which comrak takes
from the raw line and so does not shift, and a document with no \| in it
builds nothing.

comrak unescapes one other region the same way — the paragraph it splits off a
table's header row (table.rs:299) — so text written directly above a table
carried the shift too. That paragraph is the one ending on the line directly
above a table it is a sibling of: a table can only begin by converting an open
paragraph, so without a blank line between them the two came from one block, and
with one there is a line between them. It is corrected the same way, per line.

A column is put back on the line by the character comrak reports at it, so a
column naming the byte after a span answers for whatever is there. MD034's end
is one of those: with a \| directly after a bare URL, the end followed the
escape past the URL it was meant to bound. MD034 maps the URL's last byte and
steps one past that instead, which is the same column it always was outside a
table.

A line is stored as the regions comrak unescaped — each a start column and the
columns dropped from it — so the memory is the escapes rather than the length of
the line. A column is answered for by the last region beginning at or before it,
and a region reaches to where the next begins rather than to where its content
stops, so a column at a region's end still carries its shift. A row's cells are
recorded together, which is how a cell after an escaped one says the shift stops
there.

MD033, MD034, MD037, MD038 and MD039 report through it:

• MD034 and MD037 add their own byte offsets into the unescaped text on top of a
  start that has already been shifted. Mapping the position they arrive at
  covers both, because that position is in the same coordinates comrak reported.
• MD038 keeps measuring its span against the columns comrak reports — those are
  the ones that describe literal — and maps only the report. Its existing test
  asserted the shifted column and named this issue; it now asserts the written
  one.

\\| is an escaped backslash rather than an escaped pipe, and comrak drops
nothing for it, so the escapes are found by walking the backslash run rather
than by matching the pair. Matching pairs shifted a column that was never
shifted, which is what the written_position_with_escaped_backslash test pins.

Verification

• cargo test --all-features --workspace: 370 tests pass, including new
  table-cell tests in each of the five rules and eight for written_position.
• cargo clippy --all-targets --all-features --workspace -- -D warnings and
  cargo fmt --all --check are clean.
• Ran the built binary over scripts/acceptance/data/markdownlint/test/rule_tests
  and over this repository's own Markdown, before and after: byte-identical
  output, so nothing outside an escaped table cell moved.
• Checked by hand that a table inside a blockquote or a list item, a header row,
  an escape written after the inline, and multibyte cell content all report the
  column as written.

Where the correction stops

The pipe is the only escape this reaches, and only where it is resolved ahead of
the inline parser rather than by it — inside a table cell, or in the paragraph
split off a header row. Written anywhere else, \| is resolved like any other
escape, and so is every \<punctuation> everywhere: the columns MD034 and MD037
count off a text node come from a literal CommonMark had already resolved the
escape in, and comrak never shifted the column they add to, so
written_position has nothing to find.

x \. y http://www.example.com/ z    reports 1:7 for a URL at 1:8
see x\|y http://www.example.com/     reports 1:9 for a URL at 1:10

That is a separate defect, present on main and unchanged here; it is filed as
#406, and written_position, MD034, MD037 and the changelog entry say where the
guarantee stops.

Left open

#403 also asks whether the fix belongs upstream in comrak. This one is in mado,
where the reported position is assembled; it does not change what comrak
records, so an upstream fix later would make written_position a no-op rather
than conflict with it.

🤖 Generated with Claude Code

https://claude.ai/code/session_011xqGos7Q8MiBm6G59sh4FV

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.80%. Comparing base (6479490) to head (0738222).

Additional details and impacted files

@@           Coverage Diff            @@
##             main     #405    +/-   ##
========================================
  Coverage   99.79%   99.80%            
========================================
  Files          72       72            
  Lines        7715     8082   +367     
========================================
+ Hits         7699     8066   +367     
  Misses         16       16            

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.