As discussed in w0rp/ale#1051, there are cases where it would be useful
to be able to specify the dialect explicitly. This commit allows users
to do so using the ale_sh_shellcheck_dialect variable.
Fixes: w0rp/ale#1051
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
The executable for the Alex linter is currently hard-coded as 'alex',
which is an issue given the fact that it conflicts with the Haskell
lexer generator, whose executable is also called 'alex', has been around
a dozen years before the linter, and is packaged in the official
repositories of the major Linux distributions.
This commit adds options to use a local executable for the alex linter
(which is a node package), and an option to set a custom executable.
As side changes:
* The pattern in the alex handler is made more readable by turnig it
into a very-magic regex.
* Alex handles plain text, markdown, and HTML. Specific flags for HTML
and markdown are provided when instantiating the linters for the
respective filetypes, while before those formats were treated as plain
text.
* 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
ale#Escape function seems to prepend and append ' to the file name, which
are not present in the pydocstyle output. Having the parsing regexp match
the file name was overkill anyway, since there is an obvious 1:1
correspondence between the buffer number and the (potential) errors
reported by pydocstyle.
* 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
In some situations, errors reported by `perl -c` can have multiple
listings of "at <file> line <number>". If the l:pattern is changed to
use non-greedy matching it will also match these.
For example:
```
use strict;
use DateTime;
$asdf=1;
```
Results in:
```
Global symbol "$asdf" requires explicit package name (did you forget to declare "my $asdf"?) at /Users/mgrimes/t.pl line 3, <DATA> line 1.
/Users/mgrimes/t.pl had compilation errors.
```
I am not 100% sure why `perl -c` generates errors with the extra "file
line <num>". It only happens in some versions of perl when certain
modules are used.
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.
