The vulture linter already supports ale_python_vulture_options, but it
is not documented or tested. Since vulture only supports configuration
via options, it is an important use case. Add docs and test.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
* Add initial ameba (crystal linter) support
Note that this depends on saved file as `ameba` does not have STDIN
support
* Fix formatting of crystal linter documentation
* Add tests for ameba executable customization
* Add support for https://github.com/saibing/bingo
* Add docs for ale-go-bingo
* Use go.mod when found
* Add test for bingo FindProjectRoot
* Simplify ale_linters#go#bingo#GetCommand
With earlier elm versions, a separate package file is maintained for
tests, which when properly configured enabled the compiler to find what
it needed to compile the tests. Under elm 0.19, test dependencies are
managed in the top-level package file, so `elm make` will fail on the
tests. `elm-test make` is required in this case.
See https://github.com/elm-explorations/test/issues/64
- added a cd into the direcotry containing the file in the buffer
in order to properly check for a config file
- added command_callback tests for graphql
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?
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.
Previously, elixir-ls would treat each sub-project within an umbrella as
standalone, which isn't desirable from a language server perspective.
Added ale#handlers#elixir#FindMixUmbrellaRoot, which locates the current
project's root and then continues searching upwards for a potential
umbrella project root. This literally looks just two levels up to keep
things simple while keeping in line with Elixir project conventions.
Use this new function to determine elixir-ls's LSP project root.
* Allow configuration of hamllint executable
The hamllint executable was hard-coded, preventing it from being
overridden. Fix the executable to be dynamic to allow custom executable
paths.
