Implement inline ignores

[kaste]

Fixes #1212

Following @rob-miller's suggestion implement inline ignore hints.

E.g.

crate  // codespell:ignore crate
abandonned abondon abilty  # codespell:ignore abondon,abilty
abandonned abondon abilty  # codespell:ignore  # to ignore all

[peternewman]

Some of the tests are failing here due to files in ./.pytest_cache so you'll need to add that in our private GitHub workflow.

A few comments too.

Personally I'm still not entirely convinced given the same issue as other ignores, there really needs to be a way to escape it.

[peternewman]

Won't this also match, and hence ignore the typos in this:
You could also use the line based ignor ( codespell:ignore ) to ignor the whole line.

Which I'd call a false positive!

[kaste]

Questionable what the example sentence you give here should mean. False positives are always a problem but then it looks like you constructed the example to produce the false positive. In other words your sentence is probably not something a user would type. (In fact, you probably can only write down codespell:ignore in technical documentation about codespell itself.)

For prose, "inline-disabling" is probably not what you want anyway because there are no comments in prose. A user would read the technical ignore statement in any case. (There is also no syntax highlighting in the editor which would gray out our ignore statements.)

Usually, such ignore statements are the last thing on a line except you have other comments on the same line, so maybe we can change the behavior and only let ... | codespell:ignore | ... match t.i. on the left an right we find the same character, thus the ( ... ) you gave would not match. I'll push an update here.

Actually a simple ... (codespell:ignore) ... would be very nice syntax for prose and I wonder if a simpler r"[^\w\s]\s?codespell:ignore\b(\s+(?P<words>[\w,]*))?" would just work or "be enough" in practice.

[kaste]

For the record:

diff --git a/codespell_lib/_codespell.py b/codespell_lib/_codespell.py
index 6ffd629c..26b27a0e 100644
--- a/codespell_lib/_codespell.py
+++ b/codespell_lib/_codespell.py
@@ -33,7 +33,7 @@ word_regex_def = u"[\\w\\-'’`]+"
 uri_regex_def = (u"(\\b(?:https?|[ts]?ftp|file|git|smb)://[^\\s]+(?=$|\\s)|"
                  u"\\b[\\w.%+-]+@[\\w.-]+\\b)")
 inline_ignore_regex = re.compile(
-    r"([^\w\s]) codespell:ignore(\s(?P<words>[\w,]*))?(\s+\1|$)")
+    r"[^\w\s]\s?codespell:ignore\b(\s+(?P<words>[\w,]*))?")
 encodings = ('utf-8', 'iso-8859-1')
 USAGE = """
 \t%prog [OPTIONS] [file1 file2 ... fileN]
diff --git a/codespell_lib/tests/test_basic.py b/codespell_lib/tests/test_basic.py
index a67115c6..1ec93024 100644
--- a/codespell_lib/tests/test_basic.py
+++ b/codespell_lib/tests/test_basic.py
@@ -247,12 +247,11 @@ def test_ignore_word_list(tmpdir, capsys):
     ('abandonned abondon abilty  # codespell:ignore\r\n', 0),
     ('abandonned abondon abilty  # codespell:ignore  # noqa: E501\n', 0),
     ('abandonned abondon abilty  # codespell:ignore # noqa: E501\n', 0),
+    ('abandonned abondon abilty  # codespell:ignore# noqa: E501\n', 0),
+    ('abandonned abondon abilty  # codespell:ignore, noqa: E501\n', 0),
+    ('abandonned abondon abilty  #codespell:ignore\n', 0),
     # ignore these for safety
-    ('abandonned abondon abilty  # codespell:ignore# noqa: E501\n', 3),
-    ('abandonned abondon abilty  # codespell:ignore, noqa: E501\n', 3),
-    ('abandonned abondon abilty  # codespell:ignore/noqa: E501\n', 3),
     ('abandonned abondon abilty  # codespell:ignorenoqa: E501\n', 3),
-    ('abandonned abondon abilty  #codespell:ignore\n', 3),
     ('abandonned abondon abilty  codespell:ignore\n', 3),
     ('abandonned abondon abilty codespell:ignore\n', 3),
     # showcase different comment markers
@@ -260,8 +259,11 @@ def test_ignore_word_list(tmpdir, capsys):
     ('abandonned abondon abilty " codespell:ignore\n', 0),
     ('abandonned abondon abilty ;; codespell:ignore\n', 0),
     ('abandonned abondon abilty /* codespell:ignore */\n', 0),
-    # avoid false positive
-    ('You could also use line based igore ( codespell:ignore ) to igore ', 2),
+    # prose examples
+    ('You could also use line based igore ( codespell:ignore ) to igore ', 0),
+    ('You could also use line based igore (codespell:ignore) to igore ', 0),
+    ('You could also use line based igore (codespell:ignore igore) to igore ', 0),
+    ('You could also use line based igore (codespell:ignore igare) to igore ', 2),
 ])

isn't that bad either as roughly \bcodespell:ignore\b is already a very special and rare token.

there really needs to be a way to escape it.

Can we escape in prose writing?

[kaste]

I just pushed a more relaxed version as - after a week - I found this more and more nice for prose. I push this so then I don't have a dirty workdir on my computer, and we can easily see which tests pass now, and with git we don't loose the previous version anyway.

Since the verbatim codespell:ignore is already seldom to find in the wild a lax version can be just good enough.

I get the feeling that you don't want to decide on this one; and honestly I just took the most liked issue to give it a try and I did not loose a deep thought as it's not my idea I implemented but ... I think I like it and it is a good simple implementation idea. It is naive but likable.

[yarikoptic]

is there a way to add more than one ❤️ to the description of this PR? ;-)

[victor-kostyuk]

What's holding up this PR? Without inline ignores, codespell is much less useful.

[kaste]

The problem is having false positives with this approach as I understand the maintainer(s). I don't know if we could avoid them. I do think they are not very likely and then not very harmful.

[victor-kostyuk]

@kaste : could you accept @akx 's suggested changes?

@peternewman : any issues you consider serious enough to block this PR?

[DimitriPapadopoulos]

Need to rebase to resolve conflicts too.

[kaste]

I do not implement cspells ignore functionality, https://cspell.org/configuration/document-settings/#ignore I also replied over there #1212 (comment) that I do not. This is only ignore-word-on-this-line. cspell doesn't have this functionality. They have ignore-for-this-file.

Having multiple prefixes, spellings does not mitigate false positives either, on contraire.

[victor-kostyuk]

I do not implement cspells ignore functionality, cspell.org/configuration/document-settings/#ignore I also replied over there #1212 (comment) that I do not. This is only ignore-word-on-this-line. cspell doesn't have this functionality. They have ignore-for-this-file.

Having multiple prefixes, spellings does not mitigate false positives either, on contraire.

cspell has ignore line: // cspell:disable-line. Adding it is unlikely to produce false positives, for the same reason that this is unlikely to produce false positives. Also, @akx second comment was not about cspell.

[kaste]

He? I don't implement the :disable-line directive but the :ignore one. cspell:ignore has a different meaning than the codespell:ignore I tried here.

[neiljp]

I was just about to open an issue until finally finding #1212, and then this PR!
Thanks for looking at this @kaste 👍

This is a great exploratory PR; perhaps slimming it down could help find consensus for merging?

• Would looking up an appropriate comment character based on the file type help with some of the false-positive concerns, since the regex could then be more specific? Initially one could only enable this option if users provide a mapping from extensions to characters
• I suspect many would be initially satisfied with such comments on end of line only
• While excluding specific words on a line would be great, simply marking a line to be ignored is a great feature on its own; the word-specific feature could be added later

I think there's plenty of scope for extending this later:

• the words on a line feature currently here
• customizing the tool prefix used, eg. to allow codespell: , and/or cspell:
• supporting auto file type detection (optionally, to avoid a required magic dependency?)
• the line-below features in cspell? (comment on different line to 'code')
• perhaps a similar 'block below' (paragraph, function, curly-brace block?)
• turning the checker on/off on lines in a file, like isort offers
• excluding a file this way, as a source-equivalent version of the existing option
• excluding words in a file this way
• possibly support aliases for documents marked up for other tools? (not the tool prefix, but also actions)

[DimitriPapadopoulos]

I could approve when it passes tests.

Perhaps change extra_words_to_ignore to words_to_ignore_in_line? That's only a suggestion, you don't have to apply it if you don't agree.

A few more comments:

• Perhaps ignore is a bad keyword choice, because it is already taken in cspell and its meaning is different. This will be a problem if we want to share other in document settings with cspell later on. Could be ignore-words instead, but I reckon that might be verbose and wouldn't work well without word arguments – but then disable-line without word arguments could ba a good start and would be compatible with cspell.
• Documentation would be required to merge this.

[DimitriPapadopoulos]

• Would looking up an appropriate comment character based on the file type help with some of the false-positive concerns, since the regex could then be more specific? Initially one could only enable this option if users provide a mapping from extensions to characters

We currently don't have a “file type”, adding one would probably have the inverse effect of slimming down.

• I suspect many would be initially satisfied with such comments on end of line only

In most cases, but what if you want to add a # noqa too?

• While excluding specific words on a line would be great, simply marking a line to be ignored is a great feature on its own; the word-specific feature could be added later

Yes, in this case ignore might be changed to disable-line for consistency with cspell.

Inactive

Ooops, wanted to add comments first.

[kaste]

At least I'm green 😄

finally.

[DimitriPapadopoulos]

@peternewman I think we should merge this. This pull request has been stuck for more than a year. Whenever changes have been asked, @kaste has been prompt to take them into account and apply changes or provide answers, but the issue subsequently remained stuck on "change requested" for months. I think the pull request is good enough as it is: converging on finalising a pull request in finite time is more important than getting it perfect. I suggest we use codespell:ignore for now, as codespell:ignore: words aligns perfectly with the way linters work. Also, I am not convinced that file scope as opposed to line scope is a good choice for cspell:ignore, it should arguably have been cspell:file-ignore for file scope and cspell:ignore for line scope. Any way, we can work with CSpell on common directives later on.

[kaste]

Ridiculous... the ghosting starts again.

[12rambau]

I think that's the first time I see something so sad on GitHub, @kaste proposed a solution to a community problem, sticked to it for more than a year, answered ALL your requests and now because of a single maintainer stubborness, he closed it.
Just want to mentioned that this PR has 15 hearts on the first message. I consider it to be huge for a PR in general and for a codespell tool in particular.
@kaste please don't delete your branch I'll continue using it, it works exactly as it should be.

[DimitriPapadopoulos]

I'll have a look eventually.

Stale for too long.

[DimitriPapadopoulos]

@kaste Thank you for your contribution and your patience.

Some documentation would be welcome, but I don't dare asking for more.

[kaste]

Haha, it's out. 🚢 ⛵