By default our linters expect 4 spaces of indentation. This is good when for enforcing a single style for the code base but it's awful when a user opens any file that doesn't have the "right" configuration. Instead of producing a large number of messages, we should consider the following alternatives:
Producing a single message at the top of the file where the "fixable" portion is simply inserting a linter pragma for the file's indentation depth. One way to find the file's indentation is to run the linting several times with several standard lengths and see what produces the least number of warnings.
Automatically disabling all such errors even without pragma and simply creating a single info message at the top of the file.
This logic should probably be followed for all rules as whenever there is "too much" warnings our results are both less useful (users start ignoring them) and the intent of the user (or configuration) is less clear. Too much warnings could be say more than say 20 in "new files" (e.g. last commit since the last rule change) and more than maybe 5 in "old files" (e.g. last commit before the last rule change)
A perfect fit for this kind of logic is to embed it into an after engine (see #25)
By default our linters expect 4 spaces of indentation. This is good when for enforcing a single style for the code base but it's awful when a user opens any file that doesn't have the "right" configuration. Instead of producing a large number of messages, we should consider the following alternatives:
This logic should probably be followed for all rules as whenever there is "too much" warnings our results are both less useful (users start ignoring them) and the intent of the user (or configuration) is less clear. Too much warnings could be say more than say 20 in "new files" (e.g. last commit since the last rule change) and more than maybe 5 in "old files" (e.g. last commit before the last rule change)
A perfect fit for this kind of logic is to embed it into an
afterengine (see #25)