Closed as not planned
Description
Edit: Take a look at the corresponding project for status updates.
Our current system with :next-checkers works fine, but it has a couple of serious drawbacks:
- It's not at all easy to understand.
- It's overly verbose and repetitive. Just take a look at
:next-checkersof our go checkers 😒 - It's very hard to extend correctly.
flycheck-add-next-checkercan break subtly if the order of calls or the order of insertions is wrong.
I think our current system was a nice try, but it's more or less a failure in my opinion. I didn't anticipate Flycheck's success and the amount of languages and syntax checkers we'd support as well as the desire of people to add their own syntax checkers.
We need to come up with a better system that is able to figure out automatically which syntax checkers to run and which to skip, based on a few simple declarations.
What I have in mind is this:
- Add a
:maximum-levelproperty to syntax checker declarations (the exact name to be determined) which gives the maximum error level at which the syntax checker still runs, i.e. with:maximum-level errorthe syntax checker will run if there are warnings in the current buffer but not if there are errors. - Add a
:prioritywhich is a number that denotes when a checker will run. Higher priority syntax checkers run first, and only the first syntax checker of a given priority runs.
I think that simpler, but I'm really open to other suggestions!