namespell: Ignore text inside code blocks

[PLangowski]

No description provided.

[PLangowski]

The changes have been tested on meta-dts

[m-iwanicki]

1. Add `inline code`, script still fails in e.g. Zarhus docs
2. Make it configurable (via e.g. --ignore-codeblocks) e.g. (not tested)

parser.add_argument(
        "-i",
        "--ignore-codeblocks",
        action="store_true",
        default=False,
        help="Ignore codeblocks",
    )

[m-iwanicki]

I think you need some test files to make sure namespell works as intended and there are no regressions.

Not sure if you can disable rule on next line as it's usually done in other checkers e.g.

(...)
# namespell:disable
disable only this line
(...)

This file should probably show no errors:
no_errors.md

Currently:

• names in single backticks (markdown code) e.g. `zarhus` is treated as error: line 1, 3

• not sure if comments should be ignored or not (maybe configurable?). But currently I see that they are unless they are inline comments, e.g. this <!-- zarhus --> isn't ignored: line 3

• line 19: treats ``` not at the beginning as closing tag e.g.:

  ```
  ignore this zarhus ```
  this zarhus should also be ignored but isn't
  ```
  

  Not only that but it then treats the first zarhus as error not only second

[PLangowski]

@m-iwanicki code blocks shouldn't contain triple backticks, that's why i didn't add support for this. If you delete them form line 19, then namespell only shows errors with inline code.

[m-iwanicki]

@PLangowski Are you sure?

```

Or

```
````

Or

-```

Each block is formatted and displayed correctly by GitHub or other markdown parsers. Your code will silently fail in this case and it'd be very hard to know it isn't working correctly.
I'm saying all this because I'd want this hook to be more widely used but in current state it faces opposition to wider adoption.

[PLangowski]

For now I was able to implement ignoring inline code/comments 48dffcb

[PLangowski]

@m-iwanicki The cases you've presented are quite difficult to implement, and aren't that widely used. I agree that they're valid, but maybe we could track them in another issue and try to implement them in the future?

[m-iwanicki]

@PLangowski I guess that's ok.

[PLangowski]

Can we merge this then?

[m-iwanicki]

Looks ok, but fix pre-commit failures before merging

[PLangowski]

@m-iwanicki done