Have linters opt in to lint on change

[dmnd]

Lint on change is a neat feature, but it makes it necessary for us to copy files to a temporary location before linting. This means fancier linters like pylint or flow can't import relative files (see #213 and AtomLinter/linter-pylint#23).

It also causes some UI issues where lint messages are distracting because they constantly get added and removed from the document (see #136).

We could ask linters to opt in to lint on change. Then linters like pylint can decide not to support it if they want.

A further option could be to change the default setting for "lint on change" to disabled.

[hd-deman]

👍 sounds good to me

[park9140]

@dmnd, @hd-deman, I am considering supporting this as part of my v2 api effort. Any thoughts on specific needs.

[dmnd]

@park9140

Lint on change should be off, and linters should be given the real file path instead of a copy. That makes linter more compatible with fancier linters and also makes it easier to avoid janky UI.

I could imagine v2 implementing the above, but not even supporting lint on change at all (at least for the first version). That will make things simpler given all the churn happening with the API.

If lint on change is popular enough, we could add it again afterwards, but I think allowing it to regress when we change the default is fine and we could end up with a simpler to maintain system.

What do you think?

[park9140]

@dmnd, what would you think about v2 api offering a bi-directional relationship.
First round, a user is able to push lint information about a file it knows about. Also remove information that has previously been submitted. This would support linters that depend on build systems well, any errors created in a build execution could be pushed to the linter api, and when a new build is started they could clear previous errors that had been provided. This would allow us to include handling for navigating all errors within the project.

The current linter architecture is more of a request based architecture. We say, hey llinter, do you have any errors for this file, and it replies. In autocomplete-plus we do this by subscribing to the autocomplete services provided by the packages.

I think there is a benefit to having both styles. For this request I'd say any linter that wanted to operate as a build style linter would require in the lint error management service we would provide and just push errors to us.

[dmnd]

The push based stuff sounds awesome!

But I don't think it's necessarily coupled to updating the current linter to use the services API and opting in to (or deprecating) lint on change. Is there a good reason to implement all that in one go?

[dmnd]

By the way, I don't have a lot of time so spend on linter at the moment, so if you think talking things through with me is or will slow you down, feel free to forge ahead 😄