1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
//! The single answer to "is this line inside a code fence".
//!
//! Derived once per file and consulted by every check that needs it. The
//! alternative - each check carrying its own `in_fence` toggle through its own
//! loop - is how a `#!/bin/bash` line inside a bash sample got reported as a
//! malformed heading: the heading check's loop had a toggle, and a later
//! refactor moved the check out of the loop that maintained it. If a check in
//! this module's siblings ever tracks fence state itself, that is the bug.
/// A line that opens or closes a fenced code block.
///
/// `trim_start` rather than a bare `starts_with`: an indented fence (inside a
/// list item, say) is still a fence, and CommonMark allows up to three spaces
/// of indentation before one. Four or more makes it an indented code block
/// whose content happens to begin with backticks - a distinction drep does not
/// draw, deliberately, because both readings agree that the line is code.
/// Fence state for one file: which lines are code, and where the delimiters
/// are.
///
/// Both halves come from the same single pass. The unclosed-fence check needs
/// the delimiter positions and every other fence-aware check needs the mask;
/// deriving them separately would mean two definitions of "delimiter" that
/// could disagree about the same line.