pub fn scan_wikilinks(path: &Path, body: &str) -> Vec<Wikilink>Expand description
Scan body for wikilinks the way census/check/the rename machinery
actually should — never parse_wikilinks directly. When path’s
extension names a format twig understands, every code span (fenced/inline
code, raw escapes) is treated as opaque before the lexical [[…]] scan
ever sees it: each prose run between code spans is scanned on its own and the
results stitched back into body-relative spans. For an unrecognized
extension — or if the parse fails — this is exactly parse_wikilinks over
the whole body, the same behavior as before code-awareness existed.
The span is lexical either way: twig has no wikilink concept, so it
supplies the mask and nothing more. A caller about to rewrite what a span
covers wants parsed_link_spans instead, which reports only spans twig
itself identified as links.
Scanning prose runs separately, rather than scanning the whole body and
filtering the results (what exclude_code_spans alone can do), matters:
parse_wikilinks’ greedy scan finds each [[ a later ]], code or
not, closes — so one stray [[ in a code block (a Python
[[float('inf')] * width ...], DESIGN §8’s motivating example, life-sized)
can eat every ]] after it, including a real [[gone.md]] further down
the body, merging them into one bogus match that swallows the real link
whole. No post-hoc filter can get that link back — it was never emitted
as its own match. Keeping code spans out of the scan in the first place
is the only fix; this function is that fix.