See: https://github.com/testdouble/standard
StandardRB is to RuboCop what StandardJS is to ESLint. This commit
naively copies the RuboCop linter and fixer to point at the standardrb
executable. Any other adjustments are very minor (the only I can think
of is that standardrb takes a `--fix` option instead of
`--auto-correct`).
This raises a confusing point to me as both developer and a user: since
ale enables all linters by default, won't this run both RuboCop and
StandardRB (the results of which will almost always be in conflict with
one another)? How does ale already solve for this for the similar case
of StandardJS and ESLint?
It's common to add SwiftLint as a CocoaPod dependency, instead of as a global
binary. In this case we should use that version of SwiftLint before looking
for any others. Note that I'm also adding support for SwiftLint in ReactNative
projects here as well, where the Pods directory would be nested inside an ios
directory.
The linter can correctly parse pydocstyle output with any of the following
command-line options enabled: --explain, --source, --debug, and/or
--verbose
The command used to invoke the LSP process was being escaped wrong.
Also added a new option to set a different java executable and fixed the
documentation.
This fixes performance problems in Neovim, where every character results
in spawning a new clipboard-tool process.
Behaviour is not similarly pathological in Vim, but it still results in
an unnecessary amount of register churn.
There is currently a check that tries to prevent c-flags that contain
'-' in them from being unintentionally split and included in the list of
commands. For example, we wouldn't want "-fno-exceptions " to appear as
"-fno" and "-exceptions ". The way this check was done was by making sure
the last character of the split string was a space.
This meant that the very last option to appear in the compile command
was ignored (as it doesn't end with a space). This fix explicitly skips
the ends-with-space check on the last option in the command-line.
This isn't the best fix. Really we should be using the same
argument-processing rules as a shell would rather than just splitting on
'-'. That's a much larger and more complicated change though.
