Skip to content

feat: Add spellcheck guards#34

Merged
pawamoy merged 6 commits intopawamoy:mainfrom
empwilli:feat/add_spellcheck_guards
Dec 1, 2025
Merged

feat: Add spellcheck guards#34
pawamoy merged 6 commits intopawamoy:mainfrom
empwilli:feat/add_spellcheck_guards

Conversation

@empwilli
Copy link
Contributor

@empwilli empwilli commented Nov 21, 2025

feat: Add guards to disable checking for sections
In some instances users want to disable spell checking for sections of a
document, instead of enabling/disabling it for the whole document. This
introduces spell checking guards in the form of special HTML comments.
For everything enclosed in a
<!-- mkdocs-spellcheck-disable --> ... <!-- mkdocs-spellcheck-enable -->
block, no spell checking is performed.

Issue #33: #33

In some instances users want to disable spell checking for sections of a
document, instead of enabling/disabling it for the whole document. This
introduces spell checking guards in the form of special HTML comments.
For everything enclosed in a
<!-- mkdocs-spellcheck-disable --> ... <!-- mkdocs-spellcheck-enable -->
block, no spell checking is performed.

Issue pawamoy#33: pawamoy#33
@empwilli empwilli changed the title Feat/add spellcheck guards feat: Add spellcheck guards Nov 21, 2025
@pawamoy
Copy link
Owner

pawamoy commented Nov 21, 2025

Thanks!

More than creating a second parser, I meant to include the logic in the existing _MLStripper class. Just like we have in_code_tag to skip words in code blocks, we could have in_off_region to skip words in specified regions. The in_off_region flag should not be toggled if we're in a code block.

Could you also replace "disable" with "off", and "enable" with "on" everywhere?

@empwilli
Copy link
Contributor Author

More than creating a second parser, I meant to include the logic in the existing _MLStripper class. Just like we have in_code_tag to skip words in code blocks, we could have in_off_region to skip words in specified regions. The in_off_region flag should not be toggled if we're in a code block.

I've considered that but thought that splitting it is probably more in line with a "separation of concerns" philosophy. However, as the parsing logic is intertwined anyhow, this is probably the better approach, aggreed.

Could you also replace "disable" with "off", and "enable" with "on" everywhere?

Can do

Copy link
Owner

@pawamoy pawamoy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks 🙂

@empwilli empwilli requested a review from pawamoy November 27, 2025 08:58
Copy link
Owner

@pawamoy pawamoy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK LGTM, thanks!

@pawamoy pawamoy merged commit 17e4ff3 into pawamoy:main Dec 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants