For an original publishing-tool example, a page draft contains the literal marker REPLACE_ME where its contact email belongs. The author needs a warning on that marker and a way to locate it. This small check helps find an unfinished placeholder. It does not establish that the whole page is valid or ready to publish.
Return ranges from the current editor document
In a CodeMirror 6 application build, define the marker check:
import { linter, lintGutter } from '@codemirror/lint';
function unfinishedMarkers(view) {
const source = view.state.doc.toString();
const diagnostics = [];
for (const match of source.matchAll(/REPLACE_ME/g)) {
diagnostics.push({
from: match.index,
to: match.index + match[0].length,
severity: 'warning',
source: 'Publishing markers',
message: 'Replace this marker with the verified contact detail.'
});
}
return diagnostics;
}
const publishingChecks = [
linter(unfinishedMarkers),
lintGutter()
];
Add these extensions to the existing editor configuration. Keep packages compatible with the installed CodeMirror release. The code assumes a browser application already creates the editing surface; it does not mount an editor by itself.
This checker intentionally flags every exact marker, including a marker in a comment or code sample. If legitimate examples contain the same text, use a syntax-aware rule or a narrower publishing convention. Do not silently describe a literal text scan as full HTML analysis.
Give the warning a precise meaning
For this source:
<p>Contact: REPLACE_ME</p>
the expected warning range covers only REPLACE_ME. The message asks for a verified contact detail; the checker has no directory from which to invent one. After the author replaces it with the approved address, this particular warning should disappear on the next lint pass.
CodeMirror runs the configured linter after document changes when the editor is idle. Its diagnostic markers, gutter, and optional diagnostic panel are separate presentation features. Use openLintPanel if the application needs a visible “Show problems” control, and forceLinting when a deliberate immediate refresh is appropriate. Lint API
Keep the warning text specific enough that an author can act on it. A count of zero from this rule means no matching markers were found. It does not confirm link destinations, accessibility, business facts, or successful saving.
Translate a real checker's positions deliberately
When connecting an external validator, map its results into CodeMirror's document offsets. Some checkers report a line and column; others report byte offsets or offsets into transformed text. Establish whether lines and columns are zero-based or one-based, and whether the checker read the exact source currently displayed.
Use a sample containing multiple lines and a character outside basic ASCII before the reported error. Confirm that the displayed range covers the offending source. A diagnostic pointing at the next tag can send the author toward the wrong repair.
For asynchronous checks, retain the source or revision associated with the request and use the library's supported lint integration. An older result should not be applied as if it described newly typed content. Avoid adding automatic fixes until you can define exactly which current range the fix may change.
Recheck the repaired source in the actual tool
Paste the contact fixture into your development editor. Confirm one warning on the marker, type a line before it, and check that the warning still identifies the marker after recomputation. Replace it with the approved detail and verify that this warning disappears. Save through the real publishing tool and reopen the record to confirm the replacement survived.
The HTML repair guide addresses markup repair with a separate tool. This CodeMirror integration makes a selected check actionable inside the source editor. Keep the check's name and coverage visible so the author knows which problem has actually been resolved.