Check for existing issues
Environment
- OS: Linux
- Install method: Direct download
- Vale version: 3.18.0 (first caught in 3.11.2)
Describe the bug / provide steps to reproduce it
I'm getting what appears to be a false positive from an AsciiDoc table's block title affecting an ordered list marker downstream. The table and its title are both required to reproduce the issue.
Here's a minimal test case rule to help illustrate what's happening... or at least what I think is happening.
extends: existence
message: "Matched period-space-capital."
level: warning
nonword: true
tokens:
- '\. [A-Z]'
Let's try it on this contrived AsciiDoc file:
.Valid Items
[cols="1,1",options="header"]
|===
| Name | Value
| `item-a` | 100
|===
1. Perform the task.
a. Run the first command.
+
----
output
----
b. Start the next task.
+
----
output
----
c. Verify the result.
What I'd expect to happen:
I'd expect there to be no match, because "c." is an ordered list marker and should not be visible in the markup after AsciiDoc processing.
What I think is happening:
The rule is matching on the . V in substep c. Verify, except the . seems to come from the block title, and the V from the substep... I think??
This is a subtle thing. The capital letter after the block title's dot must match the capital letter after one of the ordered list markers downstream, and then we get our false positive. Check it out:
.Valid + c. Verify (both V): hit (as-written)
.Valid + c. Check (V vs C): no hit (change substep c)
.Xalid + c. Verify (X vs V): no hit (change the table title)
.Ralid + a. Run (both R): hit (now substep a)
.Salid + b. Start (both S): hit (now substep b)
wdyt?
Check for existing issues
Environment
Describe the bug / provide steps to reproduce it
I'm getting what appears to be a false positive from an AsciiDoc table's block title affecting an ordered list marker downstream. The table and its title are both required to reproduce the issue.
Here's a minimal test case rule to help illustrate what's happening... or at least what I think is happening.
Let's try it on this contrived AsciiDoc file:
What I'd expect to happen:
I'd expect there to be no match, because "c." is an ordered list marker and should not be visible in the markup after AsciiDoc processing.
What I think is happening:
The rule is matching on the
. Vin substepc. Verify, except the.seems to come from the block title, and theVfrom the substep... I think??This is a subtle thing. The capital letter after the block title's dot must match the capital letter after one of the ordered list markers downstream, and then we get our false positive. Check it out:
.Valid+c. Verify(both V): hit (as-written).Valid+c. Check(V vs C): no hit (change substep c).Xalid+c. Verify(X vs V): no hit (change the table title).Ralid+a. Run(both R): hit (now substep a).Salid+b. Start(both S): hit (now substep b)wdyt?