Conversation
SecondSkoll
commented
Apr 24, 2026
SecondSkoll
commented
- Adds date format rule
- Better string capture for release name rule context
- Update docs link
- Additional protections for inline code strings
- Adds dictionary terms
- Refines prompt rule to ensure captured element extends to next word to prevent bug with specified location
- Adds surrounding characters to inline comment rule - to ensure symbols are not flagged erroneously
dwilding
left a comment
dwilding
left a comment
There was a problem hiding this comment.
Thanks! A few questions and minor suggestions
| Anbox Cloud | ||
| Ansible | ||
| APIs | ||
| APIs? |
There was a problem hiding this comment.
Curious, is this a regex ? or a regular ??
There was a problem hiding this comment.
Regex, means that it accepts API and APIs
| (?<!<)(?<=Canonical )Observability Stack: Observability Stack | ||
| (?<!<)Snapcraft(?!>|\.io): Snapcraft | ||
| (?<!<)snapd(?!>): snapd # Vale seems to allow normal capitalisation, may need specific existence rule for Snapd | ||
| (?<!<)Ubuntu Core: Ubuntu Core |
There was a problem hiding this comment.
What's the logic for which names need (?!>) after? Should this and the observability stack entries have it too?
There was a problem hiding this comment.
So this allows for ref links and such, which don't support spaces - which I think means I didn't need to apply it to the start of Observability Stack - or some of the others.
| Lets try websites: | ||
| snapcraft.io is the Snapcraft website. | ||
| api.snapcraft.io is the Snapcraft API site. | ||
| https://api.snapcraft.io is using a protocol. |
There was a problem hiding this comment.
Would it be possible to add a couple of usages with angle brackets, to check that they're not flagged? To exercise the rules and also as representative of real docs (I'm curious how the angle brackets appear in practice).
There was a problem hiding this comment.
Yes, a good idea. This is the trouble with using a test file and then forgetting to translate some things to the formal test cases.
| The value is 999 items. | ||
| expect: | ||
| triggers: [] | ||
| severity: suggestion |
There was a problem hiding this comment.
How about adding one more testcase:
| severity: suggestion | |
| - id: valid-large-number-in-code | |
| filetypes: [md] | |
| content: | | |
| The machine ID is `123345`. | |
| expect: | |
| triggers: [] |
There was a problem hiding this comment.
For negative cases we can just add to the content of existing negative cases - and will do :)
| level: warning | ||
| tokens: | ||
| - '^[ \t]*[$%]' | ||
| - '^[ \t]*[$%] \w+' |
There was a problem hiding this comment.
This won't catch things like:
$ ./run-me.sh
$ . .venv/bin/activate
Maybe that's OK in practice. If we want to cover these cases, how about:
| - '^[ \t]*[$%] \w+' | |
| - '^[ \t]*[$%] [-\w./]+' |
There was a problem hiding this comment.
A good point, I think it could just be:
| - '^[ \t]*[$%] \w+' | |
| - '^[ \t]*[$%] .+' |
There was a problem hiding this comment.
| - '^[ \t]*[$%] \w+' | |
| - '^[ \t]*[$%] [^\s]+' |
Works better it seems.
2 participants
