Ignore messages (false positives)

[kankaristo]

It would be nice to be able to ignore certain messages, e.g. false positives. Linters are most useful when you can keep the amount of errors and warnings at zero (ignoring false positives that can't be avoided).

For example, linter-less always gives this error in styles.less:

Error: 'ui-variables.less' wasn't found

That is a false positive, since Atom will actually find the file although the Less linter can't. It would be nice to be able to ignore this message (either the exact message, or using a regular expression).

(I found #187, but since that's closed, I thought it would be best to open a new issue.)

[steelbrain]

The last time I checked there are some linters that allow you to ignore certain error type, we can't really do it in the core linter. :)

[kankaristo]

That's a shame. :(

And while a linter might allow ignoring e.g. all import/include messages, this would allow customizing this to fit a user's specific situation (which is unlikely to be added to a linter, even if the user made a pull request).

Edit: Which is also why I think it would be a valuable addition to the core linter, because it would be a user-specific setting, not linter-specific.

[steelbrain]

I know that you really want that feature, I agree that it sucks to see that less error in the panel all the time, so what approach would you suggest us?

[kankaristo]

Could there be a global regex for messages to ignore? If a linter reports an error/warning that matches the regex, it would be removed from the list of messages.

So in the above example with ui-variables.less, the regex could simply be (ui\-variables\.less). Any linter message that matches that, would be removed.

Depending on the regex, this could be a massive performance hit, but as long as it's optional (or if the regex is simple), that wouldn't really become a problem.

This and #633 are really the only features that I wish were in Linter, otherwise it's pretty much perfect. :)

[steelbrain]

Have you seen how PhpStorm or WebStorm suppresses errors?
You put something like

// @noInspection name-of-inspection

and it ignores that inspection for the line above, now of course that wouldn't be the case for linter 'cause we know nothing about the provider's inspections and we just show the messages they give us.
But still we could have something like

// @linter-ignore

and the line below would be ignored, how does that sound to you?

[AsaAyers]

That doesn't sound good to me. We don't know how comments work in whatever file you're working on and we shouldn't maintain mapping of comment types

# @linter-ignore
; @linter-ignore
// @linter-ignore
<!-- @linter-ignore -->
#_( @linter-ignore )
;; @linter-ignore

[kankaristo]

A global regex would still be useful (as a separate feature), because (still keeping with the same example) the ui-variables.less error happens for every single Atom package with a style sheet, not just styles.less. This way you wouldn't need to mark every line with a false positive that can't be avoided (easily or at all).

Linter doesn't need any info about the message, just hide the message if it matches a regex?

[steelbrain]

@AsaAyers @k2b6s9j @lierdakil ^
thoughts?

[AsaAyers]

No, this is outside the scope of the core. This issue should be opened with whatever linter produces the messages. eslint, jshint, and coffeelint all provide a native mechanism to comment and disable linting a section of code. So I'm not saying go open this issue in linter-less, it should be opened in less

[steelbrain]

I don't intend to use it personally, so all fine to me 😃

[kankaristo]

Okay. :(

I still wish there was some generic way to ignore false positives, even though ideally any false positive should be fixed, not ignored. Sometimes real world limitations apply...

Thanks for your time! :)

[lierdakil]

I think I have a vague idea of how to make this work, though. Since linter is attached to editor, it's possible to leverage underlying grammar to detect comments. Not necessarily arguing this should be implemented, but I guess it could be a nice feature. Feature creep might be an issue though, so I say put it in the "long drawer", and revisit this when more pressing issues (like disappointing lack of specs) are fixed.

[AsaAyers]

when more pressing issues (like disappointing lack of specs) are fixed.

I look forward to reviewing your pull requests :)

[keplersj]

I think this is outside of the core linter's responsibilities. The core is
responsible for giving providers an environment to function in and show
issues reliably. The provider I responsible for the issues themselves. If a
provider is providing messages that can be ignored it is up to the provider
not to provide them.

On Sat, Jun 27, 2015, 9:45 AM Steel Brain [email protected] wrote:

Reopened #647 #647.

—
Reply to this email directly or view it on GitHub
#647 (comment).

[AsaAyers]

I'm not sure why this was reopened when it's clearly outside the scope of the core linter.

Yes, you can leverage the grammar, that's just a fancy way of saying what I did above. Linter needs to understand every possible grammar to know which typeof comment to look for.

[steelbrain]

@k2b6s9j I've marked it as a low priority for now, for some time in the future when we find this okay to implement.

[lierdakil]

From a different viewpoint, universal syntax for ignoring messages could be nice for those of us who write in several languages, all with different linters (sometimes several).

Less cognitive overhead that way.

[lierdakil]

@AsaAyers, linter doesnt need to know anything besides that a given snippet is marked as comment by grammar parser.

[lierdakil]

@AsaAyers, that's literally 5 lines of code.

[steelbrain]

@AsaAyers Leaving this opened and keeping it a low priority wasn't gonna harm anyone, was it?
Also We're trying to make atom an IDE, and this feature is something that pushes us forward in that direction, also instead of doing it in every single provider, it would be compact to do it just in the core.

[kankaristo]

@AsaAyers, please reconsider. In a perfect world, this would be implemented independently in each provider, or as a config option in a linter. But a generic way to ignore false positives would be really useful for custom/obscure build systems and project-specific situations, where this would be "out of scope" even for the providers/linters.

[AsaAyers]

The provider isn't even normally the place to implement this. The linter (not us) should implement it. It's such a common thing that I've never used a linter that didn't already have the ability to ignore a section of code.

In fact linter-less seems to have exactly what you're asking for

linter-less is unusual in the sense that it seems to implement it's own linter. Ideally there would be a linter that isn't tied to Atom. Once you could call from the command line or any other tool and linter-less would simply use that.

[kankaristo]

I have that feature turned on. It disables errors about undefined variables, not missing files for @import. Even if linter-less had a feature to ignore all import statements, I think that would be a poor solution to handle a single false positive.

The feature in this issue would also be a good "fallback" for a missing feature in a linter (like with linter-less in this case). I only used that as an example that is common for all Atom users.

[kankaristo]

In my original description, I also mentioned #187, which is essentially the same as this (except I suggested the regex solution). That issue was also closed, but not fixed (as far as I know).

Edit: Actually, @nesmyslny also suggested the regex solution in that issue, I didn't notice that before.

[iam4x]

I agree with others, not on the scope of this package. Should be linter specific, with eslint you can do:

/* eslint-disable */
console.log('this line is not linted');
/* eslint-enable */
var foo = 'bar';