Open w0rp opened 1 year ago
Another detail I'm considering, which doesn't have to be a part of the first version: allow linters to be defined as solely project-wide linters.
I think it will also be good to use the word "sticky" in documentation to describe problems from project wide linters. Problems for them will stick around until you re-run them. We will probably need to finally add a command that just clears problems for a linter, project-wide or not. There's possibly a command from Syntastic we can name our command after, if it makes sense.
I've thought about how to handle whole project linting for years, and I think I finally have a good idea of how to handle it.
project_command
key to be set for linters to define a command to explicitly use for running linters over an entire project.project_root
to be defined for non-LSP linters for setting thecwd
to use for a project command. We can make this optional for tools that don't require a specific work directory, and define that any configured root will be used as thecwd
of a project command, such as throughale_root
.project_command
andcallback
to be defined for language server linters, so they can separately launch an executable to find all errors. See Pyright for example.callback
may be called for either file-specific or project-wide errors if a linter is configured to permit project wide linting.The implementation details are complicated, but we can implement this. It will be complex, but worth doing.
My recommendation for implementing how to get ALE to display project-wide problems across different buffers is to implement project wide collection of problems in its own file and define it to use the "other sources" API as if it were a separate plugin. That will prevent the engine code from being complicated by project-wide linting, and will make the addition of project wide linting nearly zero added cost for users who don't use it.
We can make project wide linting populate quickfix while sending the problems per-buffer to ALE's usual rendering of problems.