ALE support linter group

[TheHillBright]

For many languages, many linters provide more or less the same functionality via potentially the same methods (e.g. does same check, especially when one linter directly uses another). I refer the set of linters fulfilling this statement as a linter group.

It's a bad user experience when a file is linted by more than one linters in the same linter group using excessive resources and providing redundant error messages.

It's not always possible to simply set enabled linter and ignored linter for all files in the vimrc because not every linter can work on every file of a particular file type - this requires dynamic checks.

Use case1

cpp file type has both "cc" and "clangd" linters that are basically for the same thing for most use cases. clangd might be preferred for its caching etc, but it works only with compilation database generated. So, for files that clangd can work, use it. Use cc otherwise.

Use case2

I think in general, should only want to use one lsp for a buffer. So, for most file types, all lsp can be placed in the same group.

Expected Behavior

add option ale_linter_group as a Dictionary { filetype: [ List (each represents one linter group) of string ] }. ALE will try to use linter in the same order as defined. When one succeeds, the rest are ignored. Essentially, this is a general (arguably) elegant way of defining linter fallback.

Actual Behavior

Firstly, enable all linters in the linter groups. One has to write function to check if a particular linter works. If yes, set ale_linters_ignore to include all other linters in the same linter group. Using ale_pattern_options doesn't generally work as the criteria of whether the file can be supported by a particular linter might not depend on its path alone. This is tedious that should be avoided.

[w0rp]

This is a duplicate of #4222.

I described a good way to handle this in a comment. https://github.com/dense-analysis/ale/issues/4222#issuecomment-1149975534

[TheHillBright]

Indeed this is similar to #4222. The only difference maybe is only that this issue emphasizes on running only one linter in the group while #4222 cares only on the display side. I guess the description in #4222 can be slightly modified to cover this issue, but currently not seem like a complete duplicate.

The solution linked though will not prevent the redundant linter executions which is actually what's bothering me the most - it only hides the run results.

I agree that external sources can be hard to disable once already running. So, this issue aims to prevent redundant external run in the first place if the setting is done before the first ALELint. In the case the setting is changed after the first ALELint, I think we can fallback to hide the results only if that external source is hard to disable once already running (the solution linked).

[TheHillBright]

@w0rp Ping after 2 weeks since I still think this is not a complete duplicate. See my last comment.