Inline Document Settings

[ricardo-dematos]

Does check-spelling/check-spelling supports Inline Document Settings ?

I'm trying with

func_name = "interp1d"  # cspell: disable-line

but it still reports has an unrecognized word.

[jsoref]

I've added this entry which should do what you want:
https://github.com/check-spelling/spell-check-this/blob/fd1b1e0c05bfd7b9fff7d9cd062a13a39d13b683/.github/actions/spelling/candidate.patterns#L6-L8

Note that it'd also do it for # cspell: disable-line-breaks which is perhaps not correct (maybe it needs a \s*$?)

You can copy that entry into candidate.patterns and then check-spelling should suggest the same item for patterns.txt, or you could copy it straight into patterns.txt.

[ricardo-dematos]

Suggestions for excludes.txt :

# exclude python requirements files
(?:^|/)requirements(?:-dev|-doc|-test|)\.txt$

# exclude python project configurations (TOML)
(?:^|/)pyproject.toml

# exclude coverage configuration file
\.coveragerc$

# exclude pylint configuration file
\.pylintrc$

# exclude git blame ignore revisions file
\.git-blame-ignore-revs$

[ricardo-dematos]

On candidate.patterns :

# marker to ignore all code on line
^.*/\* #no-spell-check-line \*/.*$
# marker for ignoring a comment to the end of the line
// #no-spell-check.*$

Please also consider # no-spell-check(-line) as acceptable.

[jsoref]

Draft changes for each:

• exclude git blame ignore revisions file
• exclude python lint configuration file
• exclude coverage configuration file
• exclude python project configurations
• exclude python requirements files
• Add additional way to ignore spelling for a line

Notes:

• I don't include comments in the excludes file because the tool sorts the file automatically.
• I can't write TOML in the commit message because the repository is configured to check spelling and an allow list would involve putting TOML into everyone's defaults, which feels like a bit much.

[jsoref]

Note: For both check-spelling and spell-check-this, I'll rewrite any commits along prerelease until they're included in main.

So, I might, e.g. capitalize Exclude. Or harmonize the other bits...

[ricardo-dematos]

Side note... all Inline Document Settings work in Visual Studio Code with extension Code Spell Checker.

[jsoref]

Hmm, they're case-insensitive -- I was worried about that. Doing that right w/ what I have is a bit complicated (or at the very least a bit ugly, as cspell would become [Cc][Ss][Pp][Ee][Ll]{2}.

There is a way to define case insensitive things in perl, but about half the time it has resulted in the regex engine getting really mad at me when it runs into fancy unicode content. v0.0.21 has a mode where it would more or less reject files that have unicode content, but some folks like using unicode, so they wouldn't use that flag.

---

For some of the other things, it's a lot harder...

At the moment, check-spelling is entirely line oriented. It retains roughly 0 state between lines, and its pattern format is similarly designed with that assumption. Just thinking about a way to enabling users to define their own state machines gives me a headache.

OTOH, defining a simple state machine for pausing scanning and resuming is something I imagine I'll implement relatively soon (w/in a few releases). That'd be enough to support /* spell-checker: enable */ / /* cSpell:disable */.

Consider:

teh qwick /* cSpell:disable */ brown brown /* spell-checker: enable */ foxx /* spell-checker: disable */
jumpss over over /* spell-checker: enable */ thhe /* cSpell: enable */ leighzy
dog

• Do I split each section first by enable/disable chunks? Offhand, I think the answer is yes
• Do I treat each enabled section as if it were at the start of the line? Or do I treat them as if they have my standard replacement character masking their context? -- Offhand, I think I'd go w/ the latter.

For reference, check-spelling currently does ~1-5 passes per line (patterns, forbidden patterns, check-spelling,, candidates, check-candidates-for-progress). Adding an extra pass (probably before patterns) wouldn't be the end of the world, but...

---

I've been thinking about plugging check-spelling into vscode for a while, and yeah, I'm aware that it has a cspell compatible thing atm.

[ricardo-dematos]

From reading the opened issues, I'm aware of the difficulty to ignore multi-lines.

Maybe this is a push to pick Feature: Block-Ignore for a next release. 😁

---

I've been thinking about plugging check-spelling into vscode for a while, and yeah, I'm aware that it has a cspell compatible thing atm.

My last comment was solely because of that future feature, since it could be a source of knowledge for you. 😉

[Piedone]

Do I understand correctly that with # no-spell-check we're talking about instructing check-spelling inline in the code, not to spell check a line? (As opposed to adding exclusions in config files.) This would be really handy, since otherwise we have to add even one-off exceptions to the common config files. I see this is also part of the example.

What's not clear to me is, can such exclusions affect the next line? I.e. "don't spell check the immediately next line". This would be necessary, because e.g. in Markdown, it's awkward to put a comment at the end of a line, as is in code files where the line is long already.

Related: #9

[jsoref]

Yes. Note that it's just a pattern that you add to your local patterns.txt (and then use in your code).

[Piedone]

I see, thank you. What about excluding the next line due to the reasons I mention?

[jsoref]

That would require me to make the system stateful (#9). It's a lot more complicated -- amongst the many problems is how do I define a syntax which is backwards compatible -- the current patterns.txt rule format wouldn't really support that. I'm tempted to use a new file name and then I'd have to define a syntax. (In addition to actually writing the code to implement the stateful side for parsing files based on that data.)

I appreciate it's desired. And I think I'll try to implement it for the coming release.

[Piedone]

Thanks for your quick replies!