Linting stdin rather than reading the file again

[timdp]

While filing and trying to fix #33, I noticed that linter-js-standard calls standard with the path to the source file, while it already has that file's contents in a variable. This patch just passes those contents via stdin, just like linter-jshint does. (That being said, it currently doesn't fix the original bug at all.)

After this refactoring, I saw no need for caching args anymore, so I removed the related code. I have to say I don't really understand what the cache is supposed to do though. What's it caching exactly? Is it just trying to avoid array allocations? If so, I can't imagine that outweighing the overhead of creating a new process every time you lint.

[ricardofbarros]

Thank you for the PR. I originally wanted to pass the fileContent to stdin but then I gave up on that idea and I don't remember why :confused:

And thanks for the typo fix bindedLinter to boundLinter :smile:.

I'm going to look on your PR, but the args cache will stay unchanged, because..

I'm cachingit because I don't want to recursively check for package.json, parse it and get the args on each lint, it would take more time to process each lint,

[timdp]

I'm not sure I understand what you're saying about the args, but if it's necessary to keep that feature around, by all means. My main goal was to get stdin into the mix.

[ricardofbarros]

When the honorStyleSettings is ticked, it will try to search the nearest package.json to get the project style settings (custom parser, global vars,..).

Something like this:

...
"standard": {
   "parser": "babel-eslint"
}
...

Now this parser needs to be translated to the following cli arg --parser babel-eslint. That is why I'm caching the args when you open a TextEditor (file), so while you are editing with your file it doesn't need to do all that on each file save (assuming you have AtomLinter configured to lint on file save)

[timdp]

That makes a lot of sense. :-)