| Age | Commit message (Collapse) | Author |
|---|
|
|
|
PHP linter: make the path to the executable configurable
|
|
Fixes #1388
|
|
This adds generic configuration dictionary support to the elixir-ls
linter. This is useful for disabling its built-in Dialyzer support, for
example, which can improve startup time.
The configuration dictionary is a little verbose. I considered reducing
the user configuration to only the nested settings dictionary (and
having the linter implementation wrap it in the top-level `elixirLS`
dictionary), but leaving it fully configurable simplifies the code and
removes any assumptions about current or future ElixirLS behavior.
|
|
|
|
This is the callback-based variant of the existing `lsp_config` linter
option. It serves the same purpose but can be used when more complicated
processing is needed.
`lsp_config` and `lsp_config_callback` are mutually exclusive options;
if both an given, a linter preprocessing error will be raised.
The runtime logic has been wrapped in `ale#lsp_linter#GetConfig` for
convenience, similar to `ale#lsp_linter#GetOptions`.
This also adds documentation and an `AssertLSPConfig` test function for
completeness.
|
|
Pass the filename of the current file into jshint
|
|
|
|
|
|
|
|
* Add the dockerfile_lint linter for Dockerfiles
|
|
|
|
Add Perl6 support via 'perl6 -c'
|
|
* 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
|
|
|
|
|
|
* 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
|
|
|
|
|
|
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
|
|
|
|
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
|
|
Add ccls support for C/C++/ObjC
|
|
Support options when using Stylelint with SCSS
|
|
|
|
|
|
|
|
Allow extra options to be passed to haskell:hlint
|
|
Add python_[linter]_auto_pipenv options for python linters (fixes #1656)
|
|
* Add fixer for Go modules
|
|
Closes #1931
|
|
|
|
|
|
thrift: default thrift_thrift_includes to ['.']
|
|
|
|
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.
|
|
|
|
Update all Ruby linters to work consistently with bundler
|
|
|
|
|
|
|
|
|
