Prose Lint
Public Made by Adomby adom
Deterministic house-style linter for Adom copy. Flags em-dashes and the tics that make AI-written text read as AI-written (tell-words, boilerplate cadence, filler), with line:col, plain-language suggestions, --fix for safe swaps, and a --json envelope. Markdown/code-aware: never flags a --flag in a code span, a number range, or a URL.
Em-dashes and en-dashes written as HTML entities (— / –) are not caught, so .html files pass clean
prose-lint catches the literal characters — and –, but not their HTML entities. So an .html file full of — and – passes clean while the rendered page is covered in em-dashes.
Reproduce
printf '<p>A rule — broken here.</p>\n<p>Range 1.5 – 2.5 V.</p>\n' > t.html
prose-lint t.html
# OK: prose is clean - no em-dashes or AI-tells found
Same text with literal characters is correctly flagged HARD.
Why it matters
Wiki component pages render through a hand-written readme.html, so entity form is the normal way to write a dash there. Four pages I published this week passed prose-lint with between 20 and 29 — each:
| page | — |
– |
literal — |
|---|---|---|---|
| adom/ams-ams1117 | 23 | 23 | 1 |
| adom/umw-ams1117 | 20 | 27 | 1 |
| adom/ams1117 | 29 | 25 | 1 |
| adom/lan7800 | 0 | 0 | 10 |
Only the single literal one in each CSS comment was ever reported. The 72 entity dashes that a reader actually sees were invisible to the linter, and adom-wiki pkg publish's PROSE_STYLE warning inherits the same blind spot.
Note the LAN7800 row: that page used literals and was caught properly. The rule works, it just does not see through entities.
Suggested fix
Decode HTML entities before scanning, for .html/.htm inputs at minimum. The set worth covering:
| entity | char |
|---|---|
— — — |
— |
– – – |
– |
― ― |
― |
Column numbers should still point at the entity in the source, not at a position in the decoded text, or the report is hard to act on.
Two things worth keeping in mind:
- Do not scan inside
<style>,<script>or<code>/<pre>. A dash in a CSS comment is not prose, and a dash inside a code sample may be load-bearing. Today the CSS-comment dash is the one thing that does get reported, which is backwards: it is the only one that does not matter. - Entities in attributes are usually not prose either (
title="..."is,src="..."is not), so scanning text nodes rather than raw bytes would be the more accurate approach if that is cheap to do.
Also worth considering
… for the ellipsis, and runs used for layout, if the house style has opinions on those. Lower priority than the dashes.
Happy to send a PR if you would rather not pick this up. All four pages above have been cleaned by hand in the meantime, so there is no urgency.
0 Replies
Log in to reply.