fix: distinguish unclosed YAML front matter from missing front matter (new YamlFrontMatterUnclosed rule)#1
Conversation
Add a new YamlFrontMatterUnclosed rule that fires when a file starts
with a --- YAML delimiter but has no matching closing --- or ... line.
Previously, the existing NoYamlFrontMatter rule would fire in both
cases -- true absence of front matter AND unclosed front matter --
because both result in iYamlEndLine == 0.
Changes:
- Add static bool bYamlOpened field in mdModule
- In parseYaml(): set bYamlOpened=false at entry, true after the
opening --- is confirmed
- In metadata(): change iYamlEndLine==0 gate to two-stage:
if (!bYamlOpened) -> NoYamlFrontMatter (no opening --- at all)
else if (iYamlEndLine==0) -> YamlFrontMatterUnclosed (new rule)
- Add YamlFrontMatterUnclosed to writeRulesCsv() rule registry
This distinction matters for accurate remediation guidance:
- NoYamlFrontMatter: 'add a front matter block'
- YamlFrontMatterUnclosed: 'add the missing closing --- delimiter'
Discovered during implementation of the same rule in the GLOW
Accessibility Toolkit (github.com/jeffbish/glow) where it is tracked
as MD-YAML-UNCLOSED-FENCE.
There was a problem hiding this comment.
Pull request overview
This PR updates the Markdown (mdModule) YAML front matter detection so the checker can distinguish between (a) missing YAML front matter and (b) YAML front matter that was started but never closed, introducing a new YamlFrontMatterUnclosed rule to avoid confusing remediation guidance.
Changes:
- Add
YamlFrontMatterUnclosedto the rule registry output (writeRulesCsv()). - Track whether a YAML front matter opening fence was seen (
bYamlOpened) duringparseYaml(). - Update
metadata()to emitNoYamlFrontMattervsYamlFrontMatterUnclosedbased onbYamlOpenedandiYamlEndLine.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| static void parseYaml() { | ||
| bYamlOpened = false; | ||
| if (aLines.Length < 2 || aLines[0].Trim() != "---") { |
There was a problem hiding this comment.
parseYaml() returns early when aLines.Length < 2 even if line 1 is ---, leaving bYamlOpened false. For a file that contains only the opening fence (or ends immediately after it), this will still report NoYamlFrontMatter instead of the new YamlFrontMatterUnclosed. Consider removing the length check (or moving it after confirming the opening fence) so bYamlOpened is set true whenever the first line is ---, and the loop can simply no-op when there are no subsequent lines.
| if (aLines.Length < 2 || aLines[0].Trim() != "---") { | |
| if (aLines.Length == 0 || aLines[0].Trim() != "---") { |
Summary
This PR fixes a logic bug in
mdModule.metadata()and adds a new rule to distinguish between two distinct document problems that currently both fireNoYamlFrontMatter.The bug
When a Markdown file starts with
---but has no closing---or...delimiter,parseYaml()setsiYamlEndLine = 0(same as when no front matter exists at all).metadata()then firesNoYamlFrontMattereven though the author clearly intended to write front matter — they just forgot the closing fence. The remediation message "Add a YAML front matter block" is confusing because the block already exists.Example that currently misfires
Changes
mdModulefieldsstatic bool bYamlOpened;parseYaml()bYamlOpened = falseat entry; setbYamlOpened = trueafter the opening---is confirmedmetadata()if (iYamlEndLine == 0)with two-stage check:if (!bYamlOpened)→NoYamlFrontMatter;else if (iYamlEndLine == 0)→ newYamlFrontMatterUnclosedwriteRulesCsv()YamlFrontMatterUnclosedrow afterNoYamlFrontMatterrowNew rule
YamlFrontMatterUnclosedMSAC---on line 1 has no closing---or...delimiter. Pandoc will not process it as front matter.---or...line immediately after the last YAML field, before the document body begins.Origin
This issue was discovered while implementing the same rule (
MD-YAML-UNCLOSED-FENCE) in the GLOW Accessibility Toolkit, an open-source VS Code agent toolkit for auditing Office documents and Markdown files for accessibility compliance. We wanted to contribute the fix back to extCheck as thanks for the inspiration.Tested by manual inspection of the state machine changes. No new dependencies introduced.