Brackets Sprint 31 will introduce a new, clean API for linting providers:
Using the new API could potentially improve the UI of this extension -- and allow it to benefit from future linting functionality upgrades automatically.
I would like to see this as well. The built in JSLint support in S31 can't easily be disabled. I can probably figure out a way to do it, but it would be nice to just have JSHint replace it in the new linting support.
@jlafitte In the meantime, you can disable the built-in JSLint by unchecking View > Lint Files on Save (similar to earlier sprints, just different name in the menu). But I agree, using the standard API would be great!
(Btw @cfjedimaster, when your extension registers for the JS language it should automatically disable/replace the built-in JSLint linter... so no worries about collisions there).
@peterflynn right, but then to use the newly updated csslint I'd have to re-enable it.
True, good point. Will definitely be easier once they're all ported over.
Peter, I'm updating my extension and am NOT seeing it take over jslint.
Hmm. It seems to be working now - but only after I modded the JS file. It seems like - maybe - on first open if a JS file is there, JSLint is used. (Not confirmed.)
I can confirm that now. Wouldn't that be a Brackets bug?
Ok, another problem. In my jshint code, I check the project folder for a project specific jshintrc. This is done via an async file call. I cache the reads so I don't have to do it again, but on the first call it fails because my main linting function returned null when the async call happened. Check out this gist:
is there anyway around this for the linting API? I've got another linter (the w3c validator) that requires a HTTP call and would suffer the same problem.