Code blocks exclude

[Isengo1989]

It would be nice if there was an option to exclude code block.

Often these contain Classnames etc. that are not used and therefor marked as "wrong"

Example would be:

ExampleAppWithCookies

in this code:

::: code-group

\`\`\`xml [manifest.xml]
<?xml version="1.0" encoding="UTF-8"?>
<manifest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/shopware/shopware/trunk/src/Core/Framework/App/Manifest/Schema/manifest-2.0.xsd">
    <meta>
        <name>ExampleAppWithCookies</name>
        <version>1.0.0</version>
        <!-- other meta data goes here -->
    </meta>
    <cookies>
        <cookie>
            <cookie>my-cookie</cookie>
            <snippet-name>example-app-with-cookies.my-cookie.name</snippet-name>
            <snippet-description>example-app-with-cookies.my-cookie.description</snippet-description>
            <value>a static value for the cookie</value>
            <expiration>1</expiration>
        </cookie>
    </cookies>
</manifest>
\`\`\`

:::

[facelessuser]

Your formatting in the opening post is hard to follow. What file type is this found in? Can you correct the opening post as well?

If nesting code blocks use fences of different length

````
```
example
```
````

[jonasbn]

Hi @Isengo1989

Is you repository public available, if so can you provide a reference.

What you are requesting is supported, but you have not provided any information on your configuration.

Please advice

[Isengo1989]

Hi @Isengo1989

Is you repository public available, if so can you provide a reference.

What you are requesting is supported, but you have not provided any information on your configuration.

Please advice

Thx for your feedback, yes. Here is a link to a failing action:

https://github.com/shopware/docs/actions/runs/14329460882/job/40161928004?pr=1742

php [PLUGIN_ROOT/src/Migration/Migration1616677952AddDocumentType.php]

I suppose it is related to the [ ] that come afterwards. It's a feature by vitepress

https://vitepress.dev/guide/markdown#code-groups

[Isengo1989]

Your formatting in the opening post is hard to follow. What file type is this found in? Can you correct the opening post as well?

If nesting code blocks use fences of different length

example

```

I tried to escape them and added a failing pipeline. Sorry I missed the message, got to many notifications recently 🔢

[jonasbn]

Hi @Isengo1989

I made a clone of our repository and replicated the failing run on the PR you provided as an example.

The problem seem to be this construct:

```php [PLUGIN_ROOT/src/Migration/Migration1616974646AddDocumentNumberRange.php]

I believe the annotation here is the problem:

[PLUGIN_ROOT/src/Migration/Migration1616974646AddDocumentNumberRange.php]

And I do not believe this to be:

• standard Markdown
• GFM
• or CommonMark

@facelessuser is this something you recognize or now how to handle?

@Isengo1989 can you provide information on the origin of this annotation form, I am not familiar with it.

[facelessuser]

Yes, as far as I'm aware this is not standard

```php [PLUGIN_ROOT/src/Migration/Migration1616974646AddDocumentNumberRange.php]

I know that the GitHub parser will ignore stuff after the language that it doesn't recognize. I've been asked to do this in some of my Python Markdown extensions, but this is not something I've yet spent time on. I guess ignoring such things would be desirable to allow it to more broadly work with Markdown variant syntax.

[Isengo1989]

Hi @Isengo1989

I made a clone of our repository and replicated the failing run on the PR you provided as an example.

The problem seem to be this construct:

I believe the annotation here is the problem:

`[PLUGIN_ROOT/src/Migration/Migration1616974646AddDocumentNumberRange.php]`

And I do not believe this to be:

* standard Markdown
* GFM
* or CommonMark

[@facelessuser](https://github.com/facelessuser) is this something you recognize or now how to handle?

[@Isengo1989](https://github.com/Isengo1989) can you provide information on the origin of this annotation form, I am not familiar with it.

Yes, I mentioned the link above:

https://vitepress.dev/guide/markdown#code-groups

It's a Vite & Vue Powered Static Site Generator.

It would be great to ignore any content past the code block opening "```" and the language - as it is not relevant for the ignore fence.

My Python knowledge is limited to non-existent, not sure where to do that (*AI generated) and if even feasible for this scope.

from pymdownx.superfences import fence_code_format

def custom_fence_handler(source, language, options, md, **kwargs):
    # Remove metadata like `[PLUGIN_ROOT/...` from the language string
    if language and "[" in language:
        language = language.split("[")[0].strip()
    return fence_code_format(source, language, options, md, **kwargs)

custom_fences = [
    {
        'name': 'custom',
        'class': 'custom',
        'format': custom_fence_handler
    }
]

# Example Markdown configuration
markdown_extensions = [
    'pymdownx.superfences',
]

extension_configs = {
    'pymdownx.superfences': {
        'custom_fences': custom_fences
    }
}

The last option is preprocessing the markdown files and replacing the metadata with sed before running the spellcheck action.

[facelessuser]

You could use a context filter. I use this in a number of non-markdown files to filter out code blocks.

  - pyspelling.filters.context:
      context_visible_first: true
      escapes: '\\[\\`]'
      delimiters:
      # Ignore multiline content between fences (fences can have 3 or more back ticks)
      # ```
      # content
      # ```
      - open: '(?s)^(?P<open> *`{3,})$'
        close: '^(?P=open)$'
```

The above example doesn't allow anything after ` ``` `, but I imagine you can modify it to allow for additional content after the opening capture group with maybe `(?s)^(?P<open> *`{3,}).*?$`. You can experiment and find what works best. You can also modify how it handles leading white space if that is needed.

[facelessuser]

FYI, as far as Markdown parsing goes, I am working on an option to turn off strict code header handling in my Python Markdown extension. The idea is if strict code headers was disabled, it would allow erroneous content to be ignored. This assumes usage of the pymdownx.superfences extension. Hopefully it will be in the next release of those extensions.

[facelessuser]

A draft PR is up here: facelessuser/pymdown-extensions#2649

[Isengo1989]

You could use a context filter. I use this in a number of non-markdown files to filter out code blocks.

• pyspelling.filters.context:
  context_visible_first: true
  escapes: '\[\`]'
  delimiters:

  Ignore multiline content between fences (fences can have 3 or more back ticks)

  ```

  content

  ```

  • open: '(?s)^(?P *`{3,})$'
    close: '^(?P=open)$'

The above example doesn't allow anything after ` ``` `, but I imagine you can modify it to allow for additional content after the opening capture group with maybe `(?s)^(?P<open> *`{3,}).*?$`. You can experiment and find what works best. You can also modify how it handles leading white space if that is needed.

Thx, I will try this one out 👍

For the rest of the content, I might wait for the relaxed_headers option, looking good :)

[facelessuser]

I've tagged a new release with the relaxed_header option.