disable rule in markdown footnote?

[adamwolf]

Check for existing issues

• Completed

Environment

macos 15.0.1
homebrew
vale version 3.9.1

Describe the bug / provide steps to reproduce it

I don't know how to disable a style rule in a Markdown footnote.

An example:

Hello world[^tag]
<!-- vale Google.Contractions = NO -->

[^x]: They are footnotes.

<!-- vale Google.Contractions = YES -->

vale content/example.md

at 16:44:43 ❯ vale content/example.md

 content/example.md
 4:9  suggestion  Use 'they're' instead of 'They  Google.Contractions 
                  are'.                                               

✔ 0 errors, 0 warnings and 1 suggestion in 1 file.

Note that if I make the footnote not match, like this:

Hello world[^tag]
<!-- vale Google.Contractions = NO -->

[^foobar]: They are footnotes.

<!-- vale Google.Contractions = YES -->

or remove it altogether:

Hello world[^tag]
<!-- vale Google.Contractions = NO -->

They are footnotes.

<!-- vale Google.Contractions = YES -->

the styles are disabled as expected.

❯ vale content/example.md
✔ 0 errors, 0 warnings and 0 suggestions in 1 file.

I haven't yet dug into the source to see what's going on, and before I did that, I figured this might be something that's obvious to others. (and maybe I'm just missing something)

Thanks folks!

[jdkato]

I can't reproduce any of your examples, so I assume you probably have more to the files than you've provided. In any case,

• Footnotes will only be linted if they're referenced. So, for example, if the footnote is defined with [^x] but referenced with [^tag] it should not trigger an alert.
• Both comments and TokenIgnores can be used to disabled this.

Option 1

Hello world[^tag]

Here is another one[^foo].

<!-- vale Google.Contractions = NO -->

[^tag]: They are footnotes.
[^foo]: They are right.

Option 2

StylesPath = styles

[*.md]
BasedOnStyles = Vale

TokenIgnores = (\[\^\w+\]:\s.+)

[adamwolf]

Thanks for the response. It still seems to be an issue here.

I thought I tried those actual examples, but just in case, let me pull a real example into a little file and try it.

❯ vale --version
vale version 3.9.3

❯ cat content/vale-example.md
Hello world


<!-- vale Google.LyHyphens = NO -->

Materials in physically based rendering have a base color and some surface parameters, but the rendered color of the surface may be quite different from the base color. Just like in the real world, the color of the light that bounces off a material isn't just the color of the material. It's influenced by the surface details and what the light was like before it interacted with the material. There are interactive lighting and color examples in the [Lighting & Skybox](https://modelviewer.dev/examples/lightingandenv/) model-viewer examples section.  model-viewer's "neutral" lighting environment was engineered to color materials closely to the material's base colors. For more, read "[Achieving Color-Accurate Presentation with glTF](https://modelviewer.dev/examples/color.html)" and "[Tone Mapping Considerations for Physically-Based Rendering](https://modelviewer.dev/examples/tone-mapping)".

<!-- vale Google.LyHyphens = YES -->

❯ vale content/vale-example.md
✔ 0 errors, 0 warnings and 0 suggestions in 1 file.

OK, so far so good. Let's make that a footnote, and try again.

❯ cat content/vale-example-2.md
Hello world[^color]


<!-- vale Google.LyHyphens = NO -->

[^color]: Materials in physically based rendering have a base color and some surface parameters, but the rendered color of the surface may be quite different from the base color. Just like in the real world, the color of the light that bounces off a material isn't just the color of the material. It's influenced by the surface details and what the light was like before it interacted with the material. There are interactive lighting and color examples in the [Lighting & Skybox](https://modelviewer.dev/examples/lightingandenv/) model-viewer examples section.  model-viewer's "neutral" lighting environment was engineered to color materials closely to the material's base colors. For more, read "[Achieving Color-Accurate Presentation with glTF](https://modelviewer.dev/examples/color.html)" and "[Tone Mapping Considerations for Physically-Based Rendering](https://modelviewer.dev/examples/tone-mapping)".

<!-- vale Google.LyHyphens = YES -->

❯ vale content/vale-example-2.md

 content/vale-example-2.md
 6:833  error  'Physically-Based' doesn't      Google.LyHyphens 
               need a hyphen.                                   

✖ 1 error, 0 warnings and 0 suggestions in 1 file.

[jdkato]

This is actually very similar to #340: the comments are getting rendered before the footnote, so you're disabling and then re-enabling the rule.

If you remove the trailing comment, it should work:

Hello world[^color]


<!-- vale Google.LyHyphens = NO -->

[^color]: Materials in physically based rendering have a base color and some surface parameters, but the rendered color of the surface may be quite different from the base color. Just like in the real world, the color of the light that bounces off a material isn't just the color of the material. It's influenced by the surface details and what the light was like before it interacted with the material. There are interactive lighting and color examples in the [Lighting & Skybox](https://modelviewer.dev/examples/lightingandenv/) model-viewer examples section.  model-viewer's "neutral" lighting environment was engineered to color materials closely to the material's base colors. For more, read "[Achieving Color-Accurate Presentation with glTF](https://modelviewer.dev/examples/color.html)" and "[Tone Mapping Considerations for Physically-Based Rendering](https://modelviewer.dev/examples/tone-mapping)".

[adamwolf]

Ah, that's true. If I disable them at the end of the file, I don't get warnings.

Is there a way I could I put the rule disable/reenable in the footnote? It doesn't seem to work here.

[^color]:  <!-- vale Google.LyHyphens = NO -->Materials in physically based rendering have a base color and some surface parameters, but the rendered color of the surface may be quite different from the base color. Just like in the real world, the color of the light that bounces off a material isn't just the color of the material. It's influenced by the surface details and what the light was like before it interacted with the material. There are interactive lighting and color examples in the [Lighting & Skybox](https://modelviewer.dev/examples/lightingandenv/) model-viewer examples section.  model-viewer's "neutral" lighting environment was engineered to color materials closely to the material's base colors. For more, read "[Achieving Color-Accurate Presentation with glTF](https://modelviewer.dev/examples/color.html)" and "[Tone Mapping Considerations for Physically-Based Rendering](https://modelviewer.dev/examples/tone-mapping)".<!-- vale Google.LyHyphens = YES -->