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.
* FIX: use mix from the project root directory
* Move find root project function to autoloaded handlers
* add tests for #ale#handlers#elixr#FindMixProjectRoot
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.
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.
* Add better support for Haskell stack compiler tools
This commit adds support for `stack` as the executable of a tool. This
follows a pattern that has been implemented for `bundler`'s tool chain.
* Move hlint command to linter file
* Add vader test for stack exec handling
* Update ghc-mod to support stack execution
`ghc-mod` was previously broken into 2 linters.
1. ghc_mod
2. stack_ghc_mod
This additional linter is not necessary with proper support for
executable variables and `stack exec` handling.
* Support stack exec in hfmt
* Support stack in hdevtools
* Don't add newlines when not a control statement for Python
* Add test for accidental newline fix
* Add docstring detection to avoid adding unnecessarily newlines
* Add tests for docstring detection
In a lint context, it's useful to assume that included files sit next to
the current file by default. Users can still further customize this
configuration variable to add more include paths.
