Uxpected behaviour with exceptions

[f-hollow]

Check for existing issues

• Completed

#799 might be related to my issue.

Environment

OS: Linux (Ubuntu 22.04)
Install method: directly downloaded and installed the binary
Vale version: 3.4.2

Describe the bug / provide steps to reproduce it

Up until today, my Vale version was 2.29.2. My Vale configs worked as expected.

Today I installed Vale 3.4.2 and noticed unexpected behavior with exceptions. Please find this small demo repo that illustrates the issues.

I boiled my issues down to two cases. They are included in the demo repo and explained below.

.vale/styles/Google/Headings.yml

The file .vale/styles/Google/Headings.yml included in the demo repo looks as follows:

# Google.Headings -- customized
extends: capitalization
message: "Use heading-style capitalization."
level: warning
scope: heading
match: $title
exceptions:
  - ale

My README file checked with Vale:

## Vale

Some text.

Let's say I want to use heading-style capitalization in my heading titles, but the word ale should be lowercase as an exception. With this rule and Vale 3.4.2, the title ## Vale will be flagged as having inappropriate capitalization. However, Vale has a heading-style capitalization and should not be flagged!

As long as I can see, if a string of characters given under exceptions is part of a heading title (ale is part of Vale), this heading will be flagged as having inappropriate capitalization. I can replace ale with a and the behavior will be the same. However, if I change the exception to ales, suddenly Vale is not flagged anymore:

Exception	Heading	Result
ale	Vale	flagged
a	Vale	flagged
ales	Vale	not flagged

.vale/styles/Google/AmSpellingPatterns.yml

The file .vale/styles/Google/AmSpellingPatterns.yml included in the demo repo looks as follows:

# Google.Spelling -- customized
extends: existence
message: "In '%s', use American spelling with 'z' instead of 's'."
ignorecase: true
level: warning
tokens:
  - '(?:\w+)[clmns]is(e|ed|es|ing)'
  - '(?:\w+)lys(e|ed|es|ing)'
exceptions:
  - concise
  - precise

My README file checked with Vale:

## Vale

Concise, Precise, and realize.

I have ignorecase: true and the exceptions concise and precise in place. However, Vale 3.4.2 still flags the words Concise and Precise as non-compliant with the rule and asks to change s for z. As long as I use the lowercase concise and precise, the words are not flagged.

[jdkato]

Each exception entry is treated as a regular expression, so you need to be specific about how they should apply:

• In the first case, you need to add word boundaries: \bale\b.
• In the second case, you need to either list all acceptable forms or provide a pattern such as [Cc]oncise. Keys such as ignorecase and nonword apply to the rule's compiled pattern, not exceptions (which are applied literally).

[f-hollow]

To me it looked like unexpected behavior because I believe I didn't have such issues with Vale 2.29.2. In any case, now I know how to fix it.

@jdkato Thank you so much!

[f-hollow]

@jdkato I experimented with headings a bit more and noticed that using match: $sentence instead of match: $title resolves the ale problem and no \bale\b is needed. That is why rules like RedHat.Headings that use match: $sentence do not need to enclose every exception string in \b.

Why the exceptions are treated differently while using match: $sentence and match: $title?

---

For completeness, using [Cc]oncise in the second case returns the following error:

E201 Invalid value [.../.vale/styles/Google/AmSpellingPatterns.yml:9:1]:

   9* exceptions:
  10    - [Cc]oncise
  11    - [Pp]recise

did not find expected '-' indicator

Execution stopped with code 1.

Enclosing the string in \b (\b[Cc]oncise\b) solved the problem.

[jdkato]

You don't need to enclose every exception in \b; just those that are matching substrings you don't want. Something like "Bugzilla" (from RedHat.Headings) is much less likely to appear as a substring than "ale" or "a" (your examples).

The error you saw when using [Cc]oncise is a YAML syntax error. You need to quote the token when using special characters:

exceptions:
  - '[Cc]oncise'