ignore warnings

[Janther]

As I proposed on https://github.com/yujinakayama/atom-lint/issues/48 users should have more control on the warnings we see. That approach was too complicated since it was too difficult to maintain.

But now (at least on the rubocop linter) I see you are retrieving the error name, for example Metrics/LineLength.

I propose the feature to ignore some warnings based on this name. It doesn't have to be hardcoded it can be added on the fly by the user.

You can step this a little more and have lists of errors and have different colours to display them.

1. Critical(red) - Can't be understood, must fix
2. Ugly(orange) - This can be better coded, should fix (default)
3. Ignored (isn't rendered :) better performance) - I don't mind this styling error.

This way the user can make its own priorities on style and the lists could be managed on the preference panel or on a config file.

[yujinakayama]

Didn't my comment make sense to you?

I don't quite understand the need for filtering linter warnings in atom-lint. You can ignore Metrics/LineLength in RuboCop by putting the following content in /path/to/your/project/.rubocop.yml or ~/.rubocop.yml:

Metrics/LineLength
  Enabled: false

• https://github.com/bbatsov/rubocop#configuration

[Janther]

Thanks for the tip on rubocop.

Yes, the comment made sense according to the approach of that. But what i propose now is to categorize the error according to the name the linter provides (when available at least). The logic of displaying or not a warning lies in the user not the code. Of course this would be usable only when the linter provides the error-name.

To answer your question:

• Atom is slow, and It feels slower when many linter warnings are rendered and would love not to render errors that I don't offer any new information (in this example the length of a line since Atom is nice enough to draw that line for me).
• One other thing is having the linter ignore the rule and another is having the package not display it. (maybe it can be showed somewhere else, in a summary or something like that)
• There are lots of linter specific atom-packages, I like this better since it offers a single place, interface, etc... to deal with all the linters, and therefore I feel that this is the place to offer features that could enrich all the linters and atom.

Maybe I'm overcomplicating things. Thanks for reading.

[lightyrs]

I couldn't agree more @Janther — this is becoming excruciating to disable individual warnings for each linter.