diagnosticProviders

We currently have two ways diagnostics are generated, there might be more in the future:

• elm make

• elm analyse

• Testing

• Bugfixes

• Possibility to give the path to both if they’re not installed global

Elm analyse works fine on windows for me. Elm make tries to open the generated elm.js every time it runs. Pretty weird, hopefully just something that happens when you run the dev version.

Linux says it doesn’t global installations, I do have them. So it might be my linux or a problem in general. No idea about macOS.

[antew]

For the quick fix vs fix it is to allow nicer interoperability with the language server. Normally when you call elm-analyse to run a fix it will read the file from disk, fix it, write it back to disk, and format it with elm-format. The quick fix piece is there to allow it to work when the file hasn’t been written to disk yet, and to send back the new file content rather than writing it to disk.

It isn’t quite ready yet but I’ll have some time to work on it this week and have it upstream-able after that.

On the language server side I need to move up the elmAnalyseDiagnostics so that the same instance can be used for diagnostics as well as code actions (for speed and to prevent syncing issues), I started on it over in this one (https://github.com/elm-tooling/elm-language-server/compare/master...antew:feature/code-actions#diff-87377fe5c568eb8fd1cdf5c6f241e6ecR66), but the code is a bit jumbled now.

I expect I’ll have PRs in to both projects by the end of this coming weekend.

[antew]

I’ve got a prototype of this going

The biggest limitation right now is that it replaces the whole file to fix it, I’m going to do some work in elm-analyse to allow just the new text for the error range.

In the server version it formats the file after elm-analyse finishes, do you think we should do the same here?