Toggle should disable linter not just for the open buffer but completely

[RobertWHurst]

When working on other people's code it can be extremely annoying trying to read the code with a ton of linting errors on the screen. As I see it the point of a linter is to warn you of code style violations in your own code. I don't believe that extends to third party code which I also need to make use of in my editor. I think it would be a vast improvement if toggle disabled and enabled the linter globally. Toggling per buffer is a bit clumsy especially since, if I close the file and reopen it, I have to disable the linter again.

• Atom 1.0.2 on top of OS X version 10.10.4

[steelbrain]

If You want to disable linting properly, why not temporarily disable the package?

[AsaAyers]

I disagree. My use case is that I'm often viewing code under node_modules so I need it to only disable for that file.

I can see maybe having a 2nd option, but I don't think single buffer should be removed or replaced. I think there is an issue somewhere about having a config per atom project. I'm mobile, so not looking it up here. On Jul 17, 2015 2:10 PM, "Steel Brain" notifications@github.com wrote:

If You want to disable linting properly, why not temporarily disable the package?

— Reply to this email directly or view it on GitHub https://github.com/atom-community/linter/issues/751#issuecomment-122362031 .

[RobertWHurst]

@steelbrain Why would I want to open the settings pane every single time I look at another file that wasn't written under my or my team's style guide? And what if there are 20 files in a project, are you going to disable the linter on each of them? Are you going to leave them open, or disable the linter every time you view they're source?

@AsaAyers I get your point, but I think if you want to disable the linter on select files, I'm my opinion that behaviour should be path based. Better to exclude a directory then 20 single files.

Lastly the fact that the disabled state of the linter is forgotten as soon as the buffer is closed is very annoying as the state of the linter is never remembered for a given buffer.

[pelted]

I popped in here looking for a way to disable or exclude a linter based on a file path. As mentioned above, the ability to exclude directories such as node_modules, vendor, bower* etc, would be very helpful.

[steelbrain]

Closing as it's out of scope of this package to provide a way to disable itself. If you still want it, register a command in init.coffee that uses atom.packages.{enable, disable}Package. You can then even map it to a key.

[RobertWHurst]

Would a PR be considered if I went to the trouble of working on this?

[steelbrain]

@RobertWHurst will the solution I posted above not work for someone who wants to achieve this?

[RobertWHurst]

It does work, but it's also not very user friendly. Note that this was considered in scope for the authors behind sublime linter.

[steelbrain]

@RobertWHurst does autocomplete package has an option to disable autocomplete completely?

[RobertWHurst]

@steelbrain I don't think it would be a bad idea if they did, however autocomplete doesn't cover 3rd-party code in linting errors; It's not as obstructive.

[steelbrain]

@RobertWHurst We are working on introducing an option to allow users to ignore certain file types or extensions or names. Until then You can just use that init script. You can even use the project manager atom package, it enables/disables packages per project.

[RobertWHurst]

Yes, I saw the ticket for that. Funny though, I thought @pelted was was +1 my suggestion of path based ignoring, but you've credited him with that idea.

All good, I'll be glad to see it.

[steelbrain]

@RobertWHurst sorry I didn't see that you suggested it first :sweat_smile:

[RobertWHurst]

@steelbrain No problem at all. Thanks for all the hard work :) Despite my complaining I actually think the package is quite solid.