* add prolog/swipl linter
* use load_files/2 instead of read_term/2
Because it also checks some semantic warnings / errors
not only syntactic warnings / errors.
e.g.:
* singleton warning
* discontiguous warning
* ...
cf. http://www.swi-prolog.org/pldoc/doc_for?object=style_check/1
* support error messages with no line number
:- module(module_name, [pred/0]).
causes
ERROR: Exported procedure module_name:pred/0 is not defined
* add test for prolog/swipl handler
* cosmetic fixes
* detect timeout using SIGALRM
* rename g:prolog_swipl_goals to g:prolog_swipl_load
* write doc for prolog/swipl linter
* update toc and README
* fix ignore patterns
* 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
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.
When set to true, and the buffer is currently inside a pipenv,
GetExecutable will return "pipenv", which will trigger the existing
functionality to append the correct pipenv arguments to run each linter.
Defaults to false.
I was going to implement ale#python#PipenvPresent by invoking
`pipenv --venv` or `pipenv --where`, but it seemed to be abominably
slow, even to the point where the test suite wasn't even finishing
("Tried to run tests 3 times"). The diff is:
diff --git a/autoload/ale/python.vim b/autoload/ale/python.vim
index 7baae079..8c100d41 100644
--- a/autoload/ale/python.vim
+++ b/autoload/ale/python.vim
@@ -106,5 +106,9 @@ endfunction
" Detects whether a pipenv environment is present.
function! ale#python#PipenvPresent(buffer) abort
- return findfile('Pipfile.lock', expand('#' . a:buffer . ':p:h') . ';') isnot# ''
+ let l:cd_string = ale#path#BufferCdString(a:buffer)
+ let l:output = systemlist(l:cd_string . 'pipenv --where')[0]
+ " `pipenv --where` returns the path to the dir containing the Pipfile
+ " if in a pipenv, or some error text otherwise.
+ return strpart(l:output, 0, 18) !=# "No Pipfile present"
endfunction
Using vim's `findfile` is much faster, behaves correctly in the majority
of situations, and also works reliably when the `pipenv` command doesn't
exist.
Solargraph allows to set configuration options by creating a
.solargraph.yml file at the root of the project using it. Therfore this
file is a good canditate for finding ruby projects root paths.
Initial discussion:
https://github.com/w0rp/ale/issues/1874#issuecomment-418316168
* The project style linter now runs while you type.
* Now the scripts for checking the project require blank lines.
* Many style issues have been found and fixed.
* Add stylish-haskell as a fixer
`stylish-haskell` is a common formatting tool for the haskell toolchain.
It is not as advanced as `brittany` or `hindent`, but it is commonly
used for formatting of imports and data declarations. This adds it as a
fixer in ALE.
I see no reason to do this? It is just setting the environment to what
it already is?
It was originally added in #297, but that entire PR is not a great idea
in the first place; that PR (together with #270) tried to make the Go do
non-standard and non-supported stuff like compiling packages outside of
GOPATH.
That's not something that works well (I tried), so was eventually
removed in #465, but these "go env" calls remained, for no reason in
particular, as far as I can think of.
This will improve on #1834; you will now no longer get a confusing error
(but still won't get a meaningful error; need to think how to do that).
* Adding support for haskell-ide-engine
* Work with the current directory if no stack.yaml file is found
* Added Cabal file detection, updated documentation and added tests
* Updated help
