| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Add vim-plug installation instructions
|
|
|
|
Reek: --force-exclusion flag
|
|
* Rust checker: allow secondary spans to be ignored
* test/handler/test_rust_handler.vader: Add tests for g:ale_rust_ignore_secondary_spans
|
|
|
|
|
|
Add Perl6 support via 'perl6 -c'
|
|
fix: change google_java_format_* to java_google_java_format_*
|
|
* Only run stack if a stack.yaml config is found
It is necessary to check for a stack.yaml file to distinguish between
cabal-only projects or stack projects (which are also cabal projects
since stack is built on top of cabal).
* Test that stack is called if stack.yaml exists
|
|
Update Psalm to use LSP
|
|
Fix #2011 MS Windows, lint error when current drive and target file drive is different.
|
|
add terraform fmt fixer for terraform and hcl filetypes
|
|
global variables according to doc/ale-java.txt
|
|
|
|
|
|
See #1718
|
|
|
|
|
|
|
|
|
|
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/goto )
|
|
* adding LSP configuration via workspace/didChangeConfiguration
|
|
|
|
* Add support for `cargo clippy`
* Add tests for cargo-clippy support
* Add an example to doc for how to configure ale_rust_cargo_use_clippy
|
|
|
|
|
|
Expose ruby-solargraph's initialization options
|
|
* Allow custom executable for ansible linters
* Add ansible-lint tests
* ansible-lint: simplify linter command
* Rename linter "ansible" to "ansible_lint"
* Add ansible-lint options to documentation
* Add alias ansible-lint for ansible_lint
|
|
|
|
* New linter: dls
|
|
|
|
|
|
* Allow the jq filters to receive custom filters.
* Update documentation.
|
|
|
|
Add elixir-ls language server support
|
|
ElixirLS (https://github.com/JakeBecker/elixir-ls) is an LSP server for
Elixir. It's distributed as a release package that can be downloaded
from https://github.com/JakeBecker/elixir-ls/releases or built locally.
The easiest way to start it is via Unix- and Win32-specific helper
scripts, so that's the basis of this command integration. Alternatively,
we could implement the contents of those platform-specific scripts in
the linter's command callback in a language-neutral way, but there isn't
any benefit to doing that aside from eliminating the platform check, and
that could prove to be too tight of a coupling going forward.
|
|
|
|
* Add more Credo message types
* Add tests
|
|
* FIX: use mix from the project root directory
* Move find root project function to autoloaded handlers
* add tests for #ale#handlers#elixr#FindMixProjectRoot
|
|
|
|
|
|
Fix PMD not working with classes without package
|
|
PMD is currently not working properly for Java classes that use [unnamed
packages](https://docs.oracle.com/javase/specs/jls/se11/html/jls-7.html#jls-7.4.2).
Consider the following Java class that does not contain a `package`
declaration:
```java
public class App {
String getGreeting() {
return "Hello world.";
}
static void main(String... args) {
System.out.println(new App().getGreeting());
}
}
```
Running PMD in the command line agaist the Java class above produces an
output with empty string `""` in the `"Package"` column:
```sh
$ pmd -R category/java/bestpractices.xml -f csv -d './src/main/java/App.java'
Oct 02, 2018 9:10:39 PM net.sourceforge.pmd.PMD processFiles
WARNING: This analysis could be faster, please consider using Incremental Analysis: https://pmd.github.io/pmd-6.7.0/pmd_userdocs_incremental_analysis.html
"Problem","Package","File","Priority","Line","Description","Rule set","Rule"
"1","","/Users/diego/Projects/github.com/dlresende/kata-fizz-buzz/src/main/java/App.java","2","7","System.out.println is used","Best Practices","SystemPrintln"
```
But the pmd.vim handler's current pattern refuses everything coming
from a Java class that does not have a package name (2nd column):
```vim
let l:pattern = '"\(\d\+\)",".\+","\(.\+\)","\(\d\+\)","\(\d\+\)","\(.\+\)","\(.\+\)","\(.\+\)"$'
```
The solution I am proposing is to also accept empty strings as package names.
|
|
|
|
|
|
Remove test vars that cover bug
|
|
|
|
|
|
These test vars were covering up a bug in the hlint linter
implementation. Without these vars we can see the behavior that is
exhibited in `vim` proper.
|
