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.
* 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
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 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
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.
It can be necessary to pass options to the puppet parser validation. The
most glaring example of this is when using Puppet 3, with the
`parser = future` option enabled. This update allows adding
`--parser=future` to the options passed to Puppet.
* 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.
* 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
fixes#1738
- Replace previous `hh_client` usage with LSP client
- Add `HHAST` linter
- Split Hack from PHP: Hack is increasingly diverging from PHP:
- Hack tools do not understand PHP
- Most PHP tools do not handle Hack code well (including vim's syntax
highightling files)
- http://github.com/hhvm/vim-hack now sets filetype to `hack`
* Add kotlin languageserver linter definition
* Added kotlin languageserver references in docs, fix missing !! on other linters
* Added Vader tests for root path detection in Kotlin Language Server
* Rust Cargo linter: Improve workspace support
When using Cargo workspaces [1], there is a 'Cargo.toml' directory in a
top level directory, listing all the crates in the project. If we are
currently editing one of the crates, 'cargo build' should execute in
that directory for that crate's separate `Cargo.toml`, otherwise Cargo
may spend more time possibly rebuilding the entire workspace, and maybe
failing on one of the other crates, instead of succeeding on the current.
[1] https://doc.rust-lang.org/book/second-edition/ch14-03-cargo-workspaces.html
Like many other linters, use variables for the executable and options
used by the linter.
By default, the linter now report every warnings as errors with
`--warning-errors`.
Also add include directory and set working directory to file directory.
* Update section 5.viii in the README with ALEJobStarted and re-format
the example.
* Add an extra line after documentation update to ensure consistency
with the rest of the doc.
The ALELintPre and ALELintPost autocommand events are currently being
used by lightline-ale to refresh the status line and check the linter
status for a current buffer. One of the plugin's checks looks to see if
linters are currently running, via ale#engine#IsCheckingBuffer(). This
currently only works partially in certain situations. In my particular
case, working with Go files, this only seems to function properly when a
file is initially opened. Saving a file does not correctly update the
status.
This seems to be due to the fact that ALELintPre actually runs before
any jobs are carried out, making it plausible that hooking into
ALELintPre for the purpose of checking to see if there are any currently
running linters for a buffer is unreliable as it would be prone to
pretty obvious race conditions.
This adds a new User autocommand, ALEJobStarted, that gets fired at the
start of every new job that is successfully run. This allows a better
point to hook into checking the linter status of a buffer using
ale#engine#IsCheckingBuffer() by ensuring that at least one job has
started by the time IsCheckingBuffer is run.
For now, it only detects undefined steps. The nearest `features` dir
above the buffer file is loaded, so step definitions should be found
correctly.
Tested only with Cucumber for Ruby, but it should work for any cucumber
that follows a substantially similar directory structure.
* Add first qmlfmt support
* Add GetCommand() function
- pass --error/-e option
* Add handle unittest
- fix pattern regex
- store col as integer
* Update docs
* Add command callback unit test
* Add fsc as a Scala linter
* Pull reused code into `autoload/ale/` directory
* Include fsc into the README
* Add unit test for testing the scala handler
* Add unit test for scala's fsc linter
* Rename scala unit tests for clarity
* Fix typo in README
* Fix typos in doc/ale.txt
* Fix author headline
* Put methods for fsc commands back into fsc.vim
* Move command_callback tests to correct location
* Rewrite handler test so it actually tests handler
* Clarify description of test in test_scala_handler
* Handle flawfinder severity level
* Reverted code allowing Flawfinder to piggyback off of gcc's format handler
* Gave Flawfinder its own format handler and made requested changes.
* Add configuration option to open lists vertically
* Add tests, clean up vertical list config
* Vertical list option cleanup
* Use is# for tests
* Order properties in documentation alphabetically
* Flawfinder support added for C and C++
A minor modification to gcc handler was made to support flawfinder's
single-line output format that does not have a space following the
colon denoting the warning level. gcc handler still passes its
Vader tests after this modification.
* Documentation fixes
* Revert documentation regression
* Added Flawfinder to table of contents
* Removed trailing whitespace
* Follow ALE conventions better
Added additional documentation and Vader tests
* Add Elixir linter for dialyxir
* Update doc/ale.txt with dialyxir
* Keep elixir tools alphabetically ordered in README
* Add a missing entry for dialyxir to the main documentation file.
Erubi is yet another parser for eRuby. This is the default parser in
Rails as of version 5.1. It supports some additional syntax with similar
behavior to Rails' extensions to the language, though incompatible.
Rails currently still recommends their own syntax, so GetCommand still
has to do the translation introduced in
https://github.com/w0rp/ale/pull/1114 .
Erubi does not supply an executable—It is intended to be invoked only
from within a Ruby program. In this case, a one-liner on the command
line.
* When working on rust/cargo projects of varying sizes, it may be useful
to either build all possible features (i.e. lint all possible
conditionally compiled code), or even turn off other features for a
quicker edit-lint cycle (e.g. for large projects with large build times)
* Added a g:ale_rust_cargo_default_feature_behavior flag for instructing
cargo to not build any features at all (via `--no-default-features`),
building default features (via no extra flags), or building all possible
features (via `--all-features`)
* Also added a g:ale_rust_cargo_include_features flag for including
arbitrary features to be checked by cargo. When coupled with
g:ale_rust_cargo_default_feature_behavior this allows for full
customization of what features are checked and which ones are ignored
Typically proto files depend on and make use of proto definitions in
other files. When invoking protoc user can supply paths to inspect for
dependencies.
This patch makes it possible to configure flags passed to protoc. This
makes it e.g., possible to change include paths of the linter's protoc
invocation.
