Open tkw1536 opened 2 months ago
I don't think the extension can do anything about it, it's CSpell doing this interpretation. And I assume CSpell does a simple word extraction and has no notion of the language syntax.
For instance, this issue is not limited to multi-line strings, it will fail with single-line ones as well:
SOMETHING="spellchecker:words uiop "
# uiop
Note the extra space before the closing "
otherwise that character will prevent the word from being added to the dictionary. Alternatively, more than one word could be in the string and all be the last would be added to the dictionary:
SOMETHING="spellchecker:words uiop hjkl"
# uiop is in the dictionary
# hjkl is not because of attached "
As a work around, you could use some hexadecimal encoding so that cspell wouldn't recognize the configuration, but convert to a valid one once saved to a file (note the \x65
):
SOMETHING="""
# spellcheck\x65r:words asdjkfasdhjgfasdjhgfhjasgfjasgfjhsg
"""
That said, I don't understand why you think it's a problem in the first place. Without that behavior, spellchecking the python code will complain that your multi-line string has a spelling error:
which is probably not what you want.
And if you want spellchecking to be completely ignored in multi-line strings instead, you could use a pattern such as /("{3}|'{3})\n[\S\s]*?\n\1/gmx
in the C Spell: Ignore Reg Exp List
setting
Magic
spellchecker:...
comments in multi-line string literals incorrectly have an effect on the checking process.As an example, consider the following python file.
I'm using plugin version
3.0.1
on vscodium1.88.1
. I've used a python file in this example, but have reproduced the same problem with other languages that support multi-line literals, such asgo
andjavascript
.