* Fix texlab GetProjectRoot
* Fix indents in texlab#GetProjectRoot
* Prevent texlab from starting on every tex file
* Update texlab Vader tests
* Fix GetProjectRoot to return parent of .git
Previously, the function returned `../.git/`. We want the function to return the parent directory above that as the project root. This should help pass Vader tests.
The `ale_lsp_root` setting is now deprecated, and `ale_root` should be
used instead. The setting will be used for both setting the root easily
for LSP linters, and for running other linters over whole projects.
Working directories are now set seperately from the commands so they
can later be swapped out when running linters over projects is
supported, and also better support filename mapping for running linters
on other machines in future.
* Fix ansible-lint linter definition.
Use ansible-lint's feature auto-detection instead of temporary file.
For auto-detection to work, ansible project has to be also a git repository.
Don't use yaml rules. These are checked by yamllint.
Refactor pattern to work with ansible-lint >=5.0 version.
Clean-up obsolete test cases.
* Pull Request changes
This fixer enables buildifier's formatting and "lint fix" modes.
Additional options can be provided via `bazel_buildifier_options`.
It also implements some basic logic for guessing the file's type.
buildifier itself usually does this based on the filenames provided on
the command line, but because we're piping our buffer via stdin, we need
to do this manually.
* Allow clangformat to use a local style file.
* Add tests.
* Fix Vint issue.
* Improve explanation of feature in documentation.
* Fix failing test.
The test was checking the wrong directory.
* Simplify verilator linter using ale command format strings
* Verilator Linter: Restructure linter command tests
* Verilator Linter: adds to the handler test the returned filename
* Verilator Linter: add the current file path to the search path
* Verilator Linter: Add the search path to the tests
Co-authored-by: TG <tarik.graba@telecom-paris.fr>
Makefiles using GNU-make features might be called "GNUmakefile" instead
of "Makefile". This commit teaches the `c_parse_makefile` feature to
look for a GNUmakefile file if a Makefile is not present.
* The build status badge is now for GitHub Actions.
* The documentation now mentions GitHub instead.
* Warnings in the YAML file have been fixed or ignored.
* Add vim82 and neovim04 to CI tests.
* Fix test_sign_column_hightlighting test.
In vim82 with verbose=1 the output of highlight command changes breaking
the ale#sign#SetUpDefaultColumnWithoutErrorsHighlight(). This commit
forces verbose=0 when the method starts and restores the previous value
before exiting.
* No return values in vim82 returns a numeric value instead of a empty string.
* Fix test_reek_handler test
The FuzzyJSONDecode() method catches E474 when it fails to parse the
input as JSON but Vim8.2 throws E491 instead. This commit modifies the
function to catch both E474 or E491.
* Fix perl6 handler test.
Perl6 handler catches json parse errors using the E474 error but in
Vim82 it changed to E491. This commit modifies the handler so both
errors are considered.
* Fix list opening tests.
In Vim 8.2 the call `range(1, bufnr('$'))` always returns quickfix
buffers no matter if they are closed or not. Using `ls` does not show
them but the above range will always include them.
This new behavior breaks the ale#list#IsQuickfixOpen() method that in
turn breaks many other things. This commit fixes this by using the
getqflist() and getloclist() methods instead.
* Fix test updates loclist test.
For some reason in Vim 8.2 the sign offset seems to not reset between
tests causing the sign_id to not match in the Assert. When the test is
run individually it passes but when run as part of the whole suite the
sign_id is off by one.
Forcing the offset in the test setup seems to fix the issue.
* Fix omnifunc completion test.
For unknown reasons the SetCompletionResponse tests fail in Neovim 0.2
and 0.4. Unfortunatelly the only solution I found is to disable them
for neovim.
* Fix linter warnings
* Fix smoker test.
Add vim 8.2 to the list of versions that need some retires due to
randomly failing tests.
* Add docker image build job.
Trying some clever trick to build the docker image if not available
locally or in Docker hub. It uses the Dockerfile md5 checksum as tag so
only when changes on that file occur will the image be downloaded or
build.
* Add labels to Docker image
* Remove tests for middle versions 8.1 and 0.3.5
* Use same vader commit as appveyor
* Implement image push to Docker Hub
Co-authored-by: Horacio Sanson <horacio@allm.inc>
In the (unreleased) Nix 2.4 the error-messages have been reformatted[1].
This patch aims to retain proper `.nix`-support in `ale`, for both
stable Nix (2.3 and older) and unstable Nix (2.4 and newer).
[1] https://github.com/NixOS/nix/pull/3590
* master: (133 commits)
Add rnix-lsp for Nix diagnostics and completion
add spectral support for json
add spectral handler
add spectral linter for yaml
doc: Fix linter issues
doc: Add documentation for Deno
feat: Add Deno lsp support
feat: Add Deno fmt fixer
Add document for apkbuild filetype
Add tests for atools handler, basic and dealing with Error and Warning
Test default linters for apkbuild
Document new default linters for apkbuild
Make apkbuild_lint and secfixes_check default for apkbuild filetype
document support for apkbuild-lint and secfixes-check for apkbuild
Add linters for apkbuild-lint and secfixes-check from atools
Add handler for the output of atools
Fix typos
Add command callback tests
Add support for standalone files
Fix linting errors
...
atools is a collection of tools written in ash shell and Lua that
provide linting for Alpine Linux's APKBUILD.
APKBUILDs are build recipes used by Alpine Linux's build system, abuild,
an equivalent would be Arch Linux's PKGBUILD and Gentoo's ebuild.
Seems standardrb fails to properly use the --config option when using
temporary files but works fine when reading from stdin. This commit
changes the fixer so it uses stdin instead of temporary files.
* Fix 354 - Migrate CI from travis to Github Actions
* Use matrix strategy for parallel tests
* Don't build image on each run
* Add push trigger on tags
Co-authored-by: Horacio Sanson <horacio@allm.inc>
* Add nvim floating window hover support
* Add configuration for float to replace preview
* preview#ShowFloating: qualify local variables
* Configure floating preview usecases individually
Also:
* Extract floating preview to its own file.
* Ignore 'stay_here' option. Moving into the floating preview window
seems confusing at best.
* Re-use existing floating preview window if it's still up.
* Flush out floating preview documentation.
* Watch cursor position changes per window
Floating previews open a new window, so when that window is written to,
it moves briefly there at a different position than the original window.
This makes repeated positions detected when positions are tracked at a
s: level. Instead, we change the variable to window scoped, which only
fires a message if the cursor has changed from the last position in
*that window*.
* g:ale_floating_preview cleanup
* floating_preview: add ALEDetail tests
* Fix fecs test missing runtime call
* Add ALEHover floating preview tests
Co-authored-by: Jan-Grimo Sobez <jan-grimo.sobez@phys.chem.ethz.ch>
Prior to #3448, several linters should have been failing the
custom-checks that look for non-snake-cased lint names. They weren't,
but now the bug that hid those is fixed. So to avoid breaking users, we
just exclude those from the check. Linters excluded:
* clojure/clj_kondo.vim
* elixir/elixir_ls.vim
* go/golangci_lint.vim
* swift/swiftformat.vim
This adds a linter for Inko (https://inko-lang.org/). The linter makes
use of Inko's own compiler, and a newly introduced --check flag to only
check for errors; instead of also compiling source code.
* origin/master: (40 commits)
fix: correct suggested filetype for yamlfix
feat: add yamlfix fixer
Use _config for LSP config options
Add support for R languageserver (#3370)
Fix 3103 - add shellcheck shell directive detection. (#3216)
Added the Vundle command in installation instructions (#3400)
Adds support for Tlint - A Tighten Opinionated PHP Linter (#3291)
Add php phpcbf options (#3383)
Use has('gui_running') instead of has('gui')
Close#2727 - Add a hover-only setting for balloons
Fix#3332 - Modify everything for rename/actions
Add a missing blank line in documentation
Add luafmt fixer (#3289)
#3442 Fix code fix clangd issue
Close#1466 - Add GVIM refactor menu support
Look for node packages in .yarn/sdks as well
Update documentation for code actions and rename
cmp forwards, and reverse the code actions
Support for LSP/tsserver Code Actions (#3437)
Move the test for buffer-local variables
...
Hadolint is in the process of adding the severity of a lint rule to the
commandline output: https://github.com/hadolint/hadolint/pull/501
This change utilizes that to show the severity in vim.
NOTE: The custom-linting-rules test fails due to the following (legit)
warnings:
ale_linters/clojure/clj_kondo.vim:29 Use snake_case names for linters
ale_linters/elixir/elixir_ls.vim:15 Use snake_case names for linters
ale_linters/go/golangci_lint.vim:54 Use snake_case names for linters
ale_linters/swift/swiftformat.vim:56 Use snake_case names for linters
The message wasn't getting printed because docker was explicitly only
being asked to connect stdout (ignoring stderr). Unclear yet why the
error code wasn't getting bubbled up.
sed wasn't using -E, so '|' wasn't being handled properly. Seems likely
that's sed-implementation specific, so now it runs through docker's sed
to support portability.
* Fix 3103 - add shellcheck shell directive detection.
Searches for shellcheck shell directive to detect dialects for scripts
that do not have shebang.
* Change order of detection of shellcheck dialect
In a situation where the filetype can be wrong (example: something.sh
which is written in bash dialect) and has no hash-bang (since it is
meant to be sourced) then the override specified within the script will
be ignored.
It probably is the most right thing to do if the script author has added
a specific directive; it should trump everything else.
Co-authored-by: Horacio Sanson <horacio@allm.inc>
Co-authored-by: Dino Korah <dino.korah@redmatter.com>
ALE now just modifies every open buffer for rename and actions, and sets
up a one-time use BufEnter event to reload buffers that are changed so
you don't have to think about what to do with changed buffers.
* Added tsserver and LSP code action support.
* tsserver refactors support added.
* Handling special case when new text is added after new line symbol.
* ale#code_action#ApplyChanges simplified.
* Initial attempt on LSP Code Actions.
* workspace/executeCommand added.
* Some null checks added.
* Add last column to LSP Code Action message.
* Pass diagnostics to LSP code action.
Previously ApplyChanges code was applied from top-to-bottom that required
extra parameters to track progress and there was bug. I have changed code
to bottom-to-top approach as that does not require those extra parameters
and solved the bug.
Tested with typescript-language-server and it is working.
The "ale#handlers#sh#GetShellType()" function currently falls back
to the file type without checking for buffer-local variables first.
This causes the function to return "sh" even when a script is known
by Vim to be a script of a more specific type (e.g., "bash").
The "ale#handlers#shellcheck#GetDialectArgument()" function then
erroneously uses this type even though a more fitting type should be
used instead. Files without a "#!" line will be of type "sh" even
though they may have a ".bash" suffix.
This commit fixes the problem by checking for buffer-local shell
type variables (set by Vim) before falling back to the file type.
* origin/master:
Add tests for maven.vim file
Fix grammatical error in doc
Add maven helper file; use maven wrapper if available instead of global 'mvn' executable
fix lint, fix variable semantics and update tests
bibclean: update matchlist reges for bibclean > v2.11.4
Update rubocop_auto_correct_all tag
A recent(?) update to swipl changed the error format from
Warning: some.pl:2:
Singleton variables: [Y]
to
Warning: some.pl:2:
Warning: Singleton variables: [Y]
The old error handler doesn't report the correct line numbers and
messages on the old format.
I've chosen to add a function that covers the second case and detect it,
rather than rewrite the current function. This way, both versions should
be able to live together.
---
Example file that demonstrates the issue (some.pl above):
```
% vim: ft=prolog
ii(X, Y) :- X.
```
---
Newer versions of pylint will now check your code as you type. Older
versions will still only check the file on disk.
Co-authored-by: Oliver Wiegers <oliver.wiegers@gmail.com>
Add an `ALECompletePost` event along with everything needed to make it
useful for its primary purpose: fixing code after inserting completions.
* `ALEFix` can now be called with a bang (`!`) to suppress errors.
* A new `ALELintStop` command lets you stop linting, and start it later.
A new command, `:ALEImport`, has been added, which lets you import words
at your cursor if a completion provider can provide a completion for
that word which includes some additional text changes.
* ember-template-lint: Lint from stdin
* This feature has recently been implemented in ember-template-lint.
* Refactor ember-template-lint executable
* Fallback on a temporary file for old template-lint
Co-authored-by: w0rp <w0rp@users.noreply.github.com>
Option `per-file-ignores` was introduced in flake8 version 3.7.0.
It allows to ignore specific errors in specific files using glob syntax.
For example `per-file-ignores = src/generated/*.py:F401` will
ignore `F401` error in all python files in `src/generated`.
Thus ale has to run flake8 from project root where .flake8 config
is placed otherwise glob won't match linted file.
`lint_file` can now be computed dynamically with a callback function,
which can return a deferred result, as per `ale#command#Run`. This
allows linters to dynamically switch between checking files on disk,
or checking code on the fly.
Some tests have been fixed on Windows.
Prettier does not use `.prettierignore` unless the current directory is the root where the `.prettierignore` file resides.
* Update Prettier tests
* Look for prettierignore to determine project root
ALE now converts paths from compile_commands.json files into absolute
paths and prefers matching against absolute file and directory names for
determining which flags to use for files. As a result, parsing
compile_commands.json to determine flags should work for a lot more C
and C++ projects.
ALE was incorrectly detecting completion results from servers such as
rust-analyzer as wanting to add import lines when additionalTextEdits
was present, but empty.
Now ALE only filters out completion results if the autoimport setting is
off, and one of the additionalTextEdits starts on some line other than
the current line. If any additionalTextEdits happen to be identical to
the change from completion anyway, ALE will skip them.
Users can easily be confused when they set some options for a C or C++
compiler, and another compiler is run with different options, which
still reports errors. To remedy this, the existing `gcc` and `clang`
linters have been replaced with a `cc` linter that will run either
compiler.
This is a breaking change for ALE v3.0.0.
Certain tests could break if you ran them separately from other tests.
They have been patched.
`run-tests` now has a `--fast` option which runs tests with only the
fastest Vim version ALE tests with, and the custom checks.
* Restore old behavior of ALEFix command for Rubocop
Since RuboCop 0.60 ALEFix command stopped to fix all found offenses. This change restores the
previous behavior by allowing rubocop to fix all detected offenses.
* Fix tests
* Allow to configure auto-correct option for Rubocop
The options for parsing `make -n` and `compile_commands.json` flags
are now enabled by default, so people can start getting better flags
for their files by default.
`compile_commands.json` flags are now preferred over `make -n` results,
to make the options work better by default.
* fix cppcheck for 1.89+, and add column support
In cppcheck 1.89 the output changed to be more like GCC. This commit
forces any version of cppcheck to output in that same format. This also
allows for ALE to pick up the linter's column information
* Add parameters to tests. Vader passes.
* Fix c cppcheck for v1.89
* Added hdl_checker support
* Added hdl_checker tests
HDL Checker searches for files when no config file is found, which could lead to very long searches when the user is not really on a project setting
* Split FindNearestExecutable from FindExecutable
The path searching in ale#node#FindExecutable() will be useful for
eslint. Refactor it into a separate function so it can be used without
regard for the state of the _use_global and _executable variables.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
* eslint: Set project root from local executable
Using the nearest directory with node_modules does not work correctly
for nested projects where the eslint dependencies are in the outer
project. For example:
https://github.com/dense-analysis/ale/issues/3143#issuecomment-652452362
Adopt the behavior of SublimeLinter, which runs from project_root
determined by the presence of the eslint executable in node_modules/.bin
(or eslint in dependencies/devDependencies of package.json, which we can
add later as necessary). See [NodeLinter#find_local_executable].
[NodeLinter#find_local_executable]: https://github.com/SublimeLinter/SublimeLinter/blob/056e6f6/lint/base_linter/node_linter.py#L109
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
* Split eslint#GetCdString from eslint#GetCommand
Move the code for finding the project root and building the cd string
into a separate function so that it can be reused in the eslint fixer.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
* Run ESLint fixer from project root dir
To match the ESLint linter, as changed in 9ee57d43 (which I forgot to
apply to the fixer, whoops).
Fixes: #3094Closes: #3095
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
So that I can find the relevant information in the vint
linting policy summary and policies can be easily configured
https://github.com/Vimjas/vint/wiki/Vint-linting-policy-summary
Before this change an example warning message appears as:
autocmd should execute in an augroup or execute with a group (see :help :autocmd)
After this change the same example appears as:
ProhibitAutocmdWithNoGroup - autocmd should execute in an augroup or execute with a group (see :help :autocmd)
1. The often longish `description` moved away from (supposedly short)
statusline `message` into the `detail` section.
2. dockerfile_lint sends `reference_url` pointing to issue explanations.
Use that.
* Add terraform-lsp integration
https://github.com/juliosueiras/terraform-lsp
* Add tests & docs for terraform-lsp integration
terraform_langserver_options setting added to send custom flags to
terraform-lsp.
Vader tests have been added to test custom executable, custom flags, and
finding the project root. All tests pass.
Initial documentation has been added for the above.
Resolvesdense-analysis/ale#2758, juliosueiras#57
* Fix tag alignment
Co-authored-by: = <Aubrey.S.Lavigne@gmail.com>
Co-authored-by: w0rp <w0rp@users.noreply.github.com>
It was returning 0 when it should be returning an empty string.
The 'AssertEqual' in the ale image is from an old version so it does not
check the types of the arguments.
This is already fixed in 427fe19104Closes#3120
* Swap substitution order for echoed message
This prevents 'code' string in liter_name to be substituted by accident.
Linters including pycodestyle have been affected by this problem.
* Add test for linter whose name contains 'code'
Test for c525db8cb4088d02448c5ddcf4a80ffa028c3181
Since version 4.032 (04/2020) verilator linter messages also contain the
column number, and look like:
%Error: /tmp/test.sv:3:1: syntax error, unexpected endmodule, expecting ';'
To stay compatible with old versions of the tool, the column number is
optional in the researched pattern regular expression.
See commit:
81c659957e
Default navigation for commands that jump to new locations has been
implemented with the `ale_default_navigation` variable, and all commands
that jump to locations now support `-tab`, `-split`, or `-vsplit`
arguments for overriding the default navigation behavior.
Windows may insert carriage return line endings, which ALE does not handle
well. These characters should not be displayed.
Adds a line to remove these characters for all messages.
ALE appends flags from {c,cpp}_{clang,gcc}_options after those found by
parsing compile_commands.json or Makefile output. If -std=* flags are
present in both the ALE flags and parsed flags, the last one present
(i.e., ALE's -std=* flag) will determine the mode the compiler works in.
This can result in errors showing up in vim but not in the actual build
or vice-versa.
For example, say you have foo.cpp:
#include <type_traits>
int main() {
return std::is_same_v<float, int>;
}
If cpp_clang_options contains -std=c++17 and -std=c++14 is parsed from
compile_commands.json, then ALE would end up running something like:
clang++ -S -x c++ -fsyntax-only -std=c++14 -std=c++17 - < foo.cpp
This would result in no errors showing up in Vim, but the actual build
would fail with:
<stdin>:3:14: error: no template named 'is_same_v' in namespace 'std'; did you mean 'is_same'?
return std::is_same_v<float, int>;
~~~~~^~~~~~~~~
is_same
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/type_traits:872:61: note: 'is_same' declared here
template <class _Tp, class _Up> struct _LIBCPP_TEMPLATE_VIS is_same : public false_type {};
^
<stdin>:3:35: error: expected '(' for function-style cast or type construction
return std::is_same_v<float, int>;
~~~~~~~~~~~~~~~~~~~~~~~~~~^
2 errors generated.
as the actual build would not have the -std=c++17 flag added by ALE.
If cpp_clang_options contains -std=c++14 and -std=c++17 is parsed from
compile_commands.json, then the opposite problem would occur. ALE would
end up running something like:
clang++ -S -x c++ -fsyntax-only -std=c++17 -std=c++14 - < foo.cpp
and would show an error on line 3 of foo.cpp:
[clang] No template named 'is_same_v' in namespace 'std'; did you mean 'is_same'? (fix available)
The actual build, on the other hand, would succeed without any
complaints.
Removing -std=* from ALE's flags if it is already present in the parsed
flags ensures that the wrong -std=* flag is not used.
An alternative would have been to switch the order in which parsed flags
and ALE flags were concatenated when producing the command to execute,
but that could prevent a user from intentionally using ALE's flags to
override some other flags, e.g. -W* flags to enable/disable warnings in
a project whose flags are not under the developer's control.
-std=* flags are also present in cuda/nvcc.vim, objc/clang.vim,
objcpp/clang.vim, and vhdl/ghdl.vim, but none of those linters appear to
parse compile_commands.json or `make` output.
The standard linter --fix fails if the file being input is not relative
to the project root (https://github.com/standard/standard/issues/1384).
This MR attempts to fix this by changing the command so the input file
is relative to the project root and the output is to a temporary file.
Preliminary tests with toy javascript projects seem to indicate this
works fine.
* Refactor the "s:LoadArgCount()" function
Previously, this function would always set "v:errmsg" on the first
call with a given function. This is because autoloaded functions
are not defined on the first call.
A number of improvements have been made:
- a useless local function ("l:Function") is removed
- the "execute()" builtin captures the output, instead of ":redir"
- a ":try" block handles the case where a function is not defined
- a useless ":if" is removed since ":redir" always defines the var
- confusing quoting is re-written (remove double "'" chars)
Fixes: #3021
Rather than requiring users to alias ps1 to powershell themselves,
include it in s:default_ale_linter_aliases. Since [vim-ps1] is a
popular (the only?) PowerShell ftplugin and there do not appear to be
any other uses of ft=ps1 on vim.org, this seems like a safe and
reasonable default.
[vim-ps1]: http://www.vim.org/scripts/script.php?script_id=1327
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
This is kind of a peculiar reason for a PR, but I no longer control the email listed. I want to change it to avoid people getting the wrong email for me. Also, I still control the domain, but if at any point I don't, I want to put down in writing that if you get an email from this, it's not from me.
* Add autoimport support for deoplete
* Fix test_deoplete_source.py
* Use callback instead of is_async for deoplete
Shuogo, the author of Deoplete, does not recommend using the `is_async`
option:
> I think is_async is not recommended. It is not so useful and broken.
> You should use callback system instead.
Link: https://github.com/Shougo/deoplete.nvim/issues/1006#issuecomment-526797857
Incidentally, the same thread mentiones an issue started by w0rp:
https://github.com/Shougo/deoplete.nvim/issues/976
The deoplete docs also say is_async is deprecated:
> is_async (Bool)
> If the gather is asynchronous, the source must set
> it to "True". A typical strategy for an asynchronous
> gather_candidates method to use this flag is to
> set is_async flag to True while results are being
> produced in the background (optionally, returning them
> as they become ready). Once background processing
> has completed, is_async flag should be set to False
> indicating that this is the last portion of the
> candidates.
>
> Note: The feature is deprecated and not recommended.
> You should use callback system by
> |deoplete#auto_complete()| instead.
Link: https://github.com/Shougo/deoplete.nvim/blob/master/doc/deoplete.txt
Co-authored-by: w0rp <w0rp@users.noreply.github.com>
ESLint 6 loads all plugins/configs/parsers relative to the project root
which, by default, is the directory in which ESLint is invoked, as
described in [ESLint RFC 2018-simplified-package-loading].
Therefore, ALE should run ESLint from the project root, when possible,
so that dependencies will load. This commit does so.
[ESLint RFC 2018-simplified-package-loading]: https://github.com/eslint/rfcs/blob/master/designs/2018-simplified-package-loading/README.mdFixes: #2787
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
Before this change, prettier_standard would run and ignore any
.prettierrc, now it will respect the configuration of the file being
linted.
This change relies on prettier-standard 16.1.0 for the --stdin-filepath
flag, but is backward compatible: older versions of prettier-standard
will ignore the unknown flag and continue to run with no configuration
file.
If checkstyle is configured with custom options that contain "-c" then
the checkstyle config file option is ignored. This PR modifies the
regular expression when creating the checkstyle command to avoid this.
ESLint errors are contained in an array that can contain different
stuff other than JSON error messages. This patch iterates over the whole
array ignoring any non-json data.
Some files lack a hashbang line but still have an unambiguous filetype.
For example, the file `.zshrc` has the filetype `zsh`.
Augment ale#handlers#sh#GetShellType to fall back to the filetype if
no hashbang line can be found.
* Refactor stylelint fixer test
* Support additional stylelint fixer options
* Support changing working directory for stylelint fixer
* Force css syntax for stylelint fixer
* Added base handling for window/showMessage
* Ignoring severity log
* Code formatting
* Added user configurable severity
* Preferring ale#util#ShowMessage over echo'ing directly
* Using format similar to ale_echo_msg_format for consistency
* Updating docs
* Added LSP log config string; improved tests
* Use warning as fallback for incorrect user config
* Add support for nimlsp.vim
* Add test and docs for nimlsp
* Add nimlsp to supported-tools.md
* Add nimlsp to doc/ale-supported-languages-and-tools.txt
Some messages of the crystal compiler are not tied to a file.
This causes a 'Key not present in Dictionnary' error (E716).
For the record, the json output on ```require "./nonexistent.cr"```
is the following :
```json
[
{ "file":"/tmp/file.cr", "line":1, "column":1, "size":0,
"message":"while requiring \"./nonexistent.cr\"" },
{ "message":"can't find file './nonexistent.cr' relative to '/tmp'" }
]
```
The second message does not have line/column attributes.
* fix tflint handler for 0.11+
* fixup! fix tflint handler for 0.11+
* maintain compatibility with previous tflint output format
* fixup! maintain compatibility with previous tflint output format
* Add comment about tflint's output format accross versions
* Use sign-group only on supported vim versions.
The sign-group feature is only available in nvim 0.4.0 and vim 8.1.614.
* Add priority to ALE signs.
This allows users to set a priority to ALE signs to take precedence over
other plugin signs.
This commit adds support for renaming symbols in tsserver and with LSP tools, and for organising imports with tsserver. Completion results for symbols that can be imported are now suggested if enabled for tsserver completion done via ALE.
jscs.info appears to have nothing to do with the linter, and just contains a blogpost about student debt.
This appears to be the closest to canonical site for the project (although it's now merged with ESLint I suppose some still use it?)
* Trying to keep win view from bouncing
* Adjusting when views are saved and restored
* Also restore view when closing quickfix
* Don't restore view when opening list vertically
* Parse CFLAGS that can be passed using a whitelist
I went through GCC's man page and selected flags that can safely be
passed to GCC and that can be useful to syntax checking. These include:
- -I/-i* include flags
- preprocessor flags such as -D
- -W* warning flags
- -O* optimization flags
- most -f options
- -m arch dependent options
* Fix CFLAGS tests: -Idir is now parsed to -I dir
* Added two tests for flags we want or don't want to pass.
* Also check for / in addition to s:sep
This makes some of the run-test output less misleading.
Also fix a minor shellcheck issue: "\*" and "\\*" are equivalent, but
the second one makes clear that the literal backslash is intentional.
* added omitted global variables which was breaking this test when run standalone
* invert logic for s:GetLinterVariables excluding disabled linters, so that linter global options can appear in output
* additional tests for s:GetLinterVariables for linter global options
This commit add support for ink-language-server, which it does by
largely copying and pasting from the pure-language-server PR that was
merged recently.
The most interesting things to note are:
- ink-language-server is distributed upstream via npm, which is why we
search through node_modules
- With some coaxing, it can be installed globally - which is why we
search for a global binary.
- Ink is a funky language, and users will likely need to add
initialization options.
- I am not incredibly familiar with vimscript; and I may not have done
some of the buffer searching correctly.
On some systems, notably NixOS, there is no `/bin/ls` and thus this test
can fail unnecessarily on those systems. This commit uses
`/usr/bin/env ls` which resolves the issue.
Allows the user to override $GO111MODULE environment variable through
ale options. This gives control over the default behavior of Go module
resolution.
Golang documentation:
https://github.com/golang/go/wiki/Modules#how-to-use-modules
Add `ale#Go#EnvString()` function to make it easy to add similar Go
environment variables in the future.
Use the new `EnvString` function in all available Go tools callbacks
& update tests
Also add test of linter command callback for `gofmt`
The default for `g:ale_lint_on_insert_leave` was recently changed to 1,
so it now needs to be explicitly set to 0 to run linters only when files
are saved.
Deoplete needs `get_complete_position` method and it has a different
signature. It already fetches the input string and attempts to detect
the position with `\k*` regexp patterns.
This option is used to determine if `min_pattern_length` is ignored.
In usual, it does not start completion when the matched input string is
shorter than `min_pattern_length`. But when the string matches
`input_pattern`, it starts completion even when ths string is `''`.
This MR adds a new configuration variable `g:ale_java_javalsp_config`
that allows to configure external dependencies and class paths to the
language server.
The variable accepts a dictionary similar to the one supported by the
[vscode/settings.json](https://github.com/georgewfraser/java-language-server#settings)
file.
Deprecates: #2561
Checkstyle xml configuration is mandatory and not providing one causes
the tool to fail with the following error:
Must specify a config XML file.
Checkstyle itself contains a default configuration as part of its
assests named `/google_checks.xml`. Invoking checkstyle with this config
works even if such file does not exists in the file system:
checkstyle -c /google_checks.xml
This should be the default invocation to allow ALE to use checkstyle
with zero configuration.
Also when a user sets `g:ale_java_checkstyle_config` option, ALE should
use it to invoke checkstyle even such file does not exists in the
filesystem. This is because checkstyle is able to use configuration files
within JAR files defined in the CLASSPATH. The default `/google_checks.xml`
is an example of such configuration available within a JAR resource.
The default binary "launcher" is too generic and can get mixed with
other tools. To use this linter user must explicitly set the absolute
path of the launcher path.
isort is great, but I've come to prefer reorder-python-imports. The tool
has a focus on smaller diffs than isort. reorder-python-imports is also
a little smarter than isort which is nice.
The existing option setting handles setting additional compile flags to
pass to clang-tidy. The new option setting added here allows setting
additional clang-tidy specific flags to be passed as well.
Fixes#2324
The command used to invoke the language server is missing some options
to include additional java modules. Without these modules the server
was not working properly.
The correct command can be found in a `launcher` script on the same
directory the `java` executable for the language server is found.
This commit changes the docs to prefer the launcher script over the java
executable. For backward compatibility it also fixes the command
invocation in case the java executable is configured.
cppcheck is now run without the --project option and from the buffer's
directory instead when the buffer has been modified. Saving the buffer
will get results by linting the project instead.
The checkstyle handler is capable of parsing the new and old output
formats. Unfortunately there are some particular output messages that
matched both the new and old regular expressions:
[WARN] whatever:11:7: WhitespaceAround: ''if'' is not followed by whitespace. [WhitespaceAround]
This caused ALE to report extra errors since the message was being
matched twice, once as a warning and another (incorrect) old formatted
error.
This MR fixes this by stopping any parsing using the old format regexp
is any errors of the new format are correcly parsed. There is no reason
to expect checkstyle to output both styles in the same report.
This linter uses the check functionality built into terraform. ALE
already has a fixer using `terraform fmt` but this doesn't provide error
messages. ALE already has a linter using `tflint` but this requires an
extra application to be installed.
For example this linter will give a warning that ! is an illegal
character in the line below:
variable "example" !{}
This linter runs the buffer through the command below and parses the
output:
terraform fmt -no-color -check=true -
This commit includes a basic implementation, documentation and tests.
The only option is to control which executable is run.
Tested with:
$ terraform -version
Terraform v0.11.13
To find the buffer corresponding to URIs reported by LSP the
HandleLSPDiagnostics() method uses the built-in bufnr() function. From
the documentation we learn that the first parameter of bufnr() is
an expression, not a path.
EclipseLSP will report project wide errors (e.g. gradle errors) that are
not related to any actual source file with an URI that corresponds to the
project root folder, e.g:
file:///home/username/Projects/gradle-simple
This URI will match any open buffer of files within the project root
hiearchy, thus project-wide errors appear as part of every file within
the project, e.g:
file:///home/username/Projects/gradle-simple/src/main/java/Hello.java
To fix this, this MR adds '^' to the beginning and '$' at the end of the
URI path to force an exact match. This is how is recommended in vim
help (see :h bufname).
We were setting the -data parameter to the project root but this caused
the language server to fail initialization and synch of gradle
dependencies. As consequence ALE failed to work fully on gradle
projects.
This fix sets the workspace to the parent folder of the project root.
Normally this corresponds to the correct Eclipse workspace path.
When this is not the case, this fix also allows users to explicitly set
the absolute path to the workspace via configuration variable.
* Search eclipselsp jar and config files within system package path
* Allow setting an alternate eclipselsp configuration directory
* Add test for ale_java_eclipselsp_config_path
The official configuration files for `flake8` are `.flake8`, `tox.ini`,
and `setup.cfg`.
After investigation, it is safe to remove `flake8.cfg` as it appears to
only exist as a typo in other tooling documentation (e.g.,
`python-language-server`).
Even though no linters automatically read `.flake8rc`, it is kept in
case projects may be using it for detecting the projects root directory.
Make it very clear in every single place that the setting for ALE's own
completion implementation is mentioned that you should not enable it if
you want to use ALE as a completion source for other plugins like
Deoplete.
- Set default value to $HOME/eclipse.jdt.ls
- Make JAR search regexp more specific.
- Allow to set the VSCode extensions folder as ale_java_eclipselsp_path.
The recommended format for _vim's internal help files_ is "<tag> <for vim version> <last change>", (see `:help help-writing` but this format is not parsed the same way for plugins. For plugins the recommended format includes a description of the plugin such as "<tag> <description>". See `:help write-local-help` for the different template.
The `settagstack` and `gettagstack` functions don't exist prior to Vim
8.1.0519. And the function definition was unclear whether it intended
to grab the *old* or the *new* file/line/col.
* [doc] Add swift support documentation
* [doc] Add swift bullets in main help file
* [doc] Add to supported languages and tools txt file as well
* Ensure same name styling for help/readme files
* move php-langserver "test for .git dir" test-project to its own directory
* search for composer.json file in php-langserver first then .git dir
* add test for php-langserver composer.json
When using `gotype` without the `-e` option, it will only output the
first 10 errors. When working on a larger package that ofter means taht
those 10 errors are in other files then the one that you are currently
working on which then seems to indicate that there are no errors.
By adding the `-e` flag, all errors will be returned and shown properly
in the file that you are working on.
* Add credo --strict option
If a user sets 'let g:ale_elixir_credo_strict=1' it will run credo with
--strict instead of suggest. The default (0) is to run as suggest.
* Added credo docs
The Rust compiler returns the first column that is _not_ part of the
current span as `column_end`, while Ale expects `end_col` to signify
the last column of the span.
Bandit automatically [uses any .bandit file] within the directories on
which it is invoked. Since ALE invokes bandit on stdin, it does not
load a .bandit file automatically. Add support for automatically
finding a .bandit file and passing it to bandit via the --ini option
along with a variable to disable this behavior if desired.
Note: This is useful for the skips and tests configuration options, but
not exclude which would require invoking bandit using a file name, which
may or may not be a good trade-off.
[uses any .bandit file]: https://github.com/PyCQA/bandit/blob/1.5.1/bandit/cli/main.py#L70-L73
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
Pylint only [checks for pylintrc] (and .pylintrc) files in the packages
aboves its current directory before falling back to user and global
pylintrc. For projects with a src dir, running pylint from the
directory containing the file will not use the project pylintrc.
Adopt the convention used by many other Python linters of running from
the project root, which solves this issue. Add pylintrc and .pylintrc
to FindProjectRoot. Update docs.
[checks for pylintrc]: https://github.com/PyCQA/pylint/blob/pylint-2.2.2/pylint/config.py#L106
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
* The README now points to a valid helptag for linter options.
* The now very, very large part of the table of contents for linter and
fixer options has been moved into a section so the initial table is
smaller.
* Special linter or fixer options now lie beneath the general linter
or fixer options.
Although using %t to lint changes was desirable, many pylama checks use
surrounding paths and file contents (e.g. C0103 module name, E0402
relative import beyond top, etc.) The more such errors I find during
testing, the less %t seems like a good idea. Switch to %s.
Also set `lint_file` to 1 and mark Pylama as a file linter in the docs.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
As discussed in w0rp/ale#1051, there are cases where it would be useful
to be able to specify the dialect explicitly. This commit allows users
to do so using the ale_sh_shellcheck_dialect variable.
Fixes: w0rp/ale#1051
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
The vulture linter already supports ale_python_vulture_options, but it
is not documented or tested. Since vulture only supports configuration
via options, it is an important use case. Add docs and test.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
* Support filtered jump based on loclist item type (E or W for now)
* Use flags to customize the behavior of ALENext and ALEPrevious
* Update <plug> bindings with flags
* Update documentation about ALENext and ALEPrevious
* Use ale#args#Parse in JumpWrap
A new function is added here which will later be modified for public use
in linter and fixer callbacks. All linting and fixing now goes through
this new function, to prove that it works in all cases.
This little error caused that when parsing compile_commands json, the
filename was used to fetch entries in directory dictionary, hence, when
adding new json commands, it never found anything in dir_lookup and
instead rewrote the previous entry. Hence, the dir_lookup always
contained list of only one compile_command per directory instead of all
compile_commands for given directory.
The executable for the Alex linter is currently hard-coded as 'alex',
which is an issue given the fact that it conflicts with the Haskell
lexer generator, whose executable is also called 'alex', has been around
a dozen years before the linter, and is packaged in the official
repositories of the major Linux distributions.
This commit adds options to use a local executable for the alex linter
(which is a node package), and an option to set a custom executable.
As side changes:
* The pattern in the alex handler is made more readable by turnig it
into a very-magic regex.
* Alex handles plain text, markdown, and HTML. Specific flags for HTML
and markdown are provided when instantiating the linters for the
respective filetypes, while before those formats were treated as plain
text.
Similar to other linters/fixers, by default change to the directory of
the file being fixed before invoking `black`, which allows the tool to
read project-specific configuration (pyproject.toml)
Fixes#2218
* Add initial ameba (crystal linter) support
Note that this depends on saved file as `ameba` does not have STDIN
support
* Fix formatting of crystal linter documentation
* Add tests for ameba executable customization
* Extended statusline.vim to provide an efficient way to access the first errors,warnings,stylerrors,stylewarnings,etc from the loclist.
* Added documentation and help for the new API function.
Currently, we detect the linter root based on a variety of techniques.
However, these techniques are not foolproof. For example, clangd works
fine for many things without a compile_commands.json file, and Go
projects may be built outside of the GOPATH to take advantage of Go
1.11's automatic module support.
Add global and buffer-specific variables to allow the user to specify
the root, either as a string or a funcref. Make the funcrefs accept the
buffer number as an argument to make sure that they can function easily
in an asynchronous environment.
We define the global variable in the main plugin, since the LSP linter
code is not loaded unless required, and we want the variable to be able
to be read correctly by :ALEInfo regardless.
All linters should have a name variable set in their dictionary, and
code should be able to rely on that. Fix this test such that its example
linter contains a name entry.
* Mimic Prettier's default parser by setting it to `babylon`
* Add tests to check default Prettier `parser`
* Set Prettier default parser based on version
* Update the comment to explain the reason for an explicit default
* Add textDocument/typeDefinition for LSP
Doc to spec https://microsoft.github.io/language-server-protocol/specification#textDocument_typeDefinition
This works like textDocument/definition but resolves a location of a
type of an expression under the cursor.
I'm not sure what to do with tsserver though.
* Fix passing column to LSP
* test_go_to_definition: wording
* Add tests for textDocument/typeDefinition
* Add docs for textDocument/typeDefinition
From LSP spec:
> A range in a text document expressed as (zero-based) start and end
> positions. A range is comparable to a selection in an editor. Therefore
> the end position is exclusive.
ale#Escape function seems to prepend and append ' to the file name, which
are not present in the pydocstyle output. Having the parsing regexp match
the file name was overkill anyway, since there is an obvious 1:1
correspondence between the buffer number and the (potential) errors
reported by pydocstyle.
When using a compilation database (compile_commands.json) in very large
projects, significant delays would occur when changing files --
particularly those that happened to be far down the db. Rather than
iterating over the whole list every time, we now build up a lookup table
based on the tail of the filename (and tail of the directory for
widening searches) and iterate over the much smaller list of compile
commands for files with the given name.
Test metrics (from compile_database_perf/test.sh) show a 90% performance
improvement -- from 25 seconds to 2.5 seconds per run.
* Add support for https://github.com/saibing/bingo
* Add docs for ale-go-bingo
* Use go.mod when found
* Add test for bingo FindProjectRoot
* Simplify ale_linters#go#bingo#GetCommand
With earlier elm versions, a separate package file is maintained for
tests, which when properly configured enabled the compiler to find what
it needed to compile the tests. Under elm 0.19, test dependencies are
managed in the top-level package file, so `elm make` will fail on the
tests. `elm-test make` is required in this case.
See https://github.com/elm-explorations/test/issues/64
Split by space instead of dash.
This prevents incorrect parsing where space-separated arguments are
merged (in particular, .c or .o files were appended to -I or -D
arguments).
Handle shell escape: quotes and escaped quotes \" and shell
substitutions are recognised. This is done by verifying that no special
character (" ' ` ()) has not a matching character.
Fixes#2049
- added a cd into the direcotry containing the file in the buffer
in order to properly check for a config file
- added command_callback tests for graphql
In some situations, errors reported by `perl -c` can have multiple
listings of "at <file> line <number>". If the l:pattern is changed to
use non-greedy matching it will also match these.
For example:
```
use strict;
use DateTime;
$asdf=1;
```
Results in:
```
Global symbol "$asdf" requires explicit package name (did you forget to declare "my $asdf"?) at /Users/mgrimes/t.pl line 3, <DATA> line 1.
/Users/mgrimes/t.pl had compilation errors.
```
I am not 100% sure why `perl -c` generates errors with the extra "file
line <num>". It only happens in some versions of perl when certain
modules are used.
See: https://github.com/testdouble/standard
StandardRB is to RuboCop what StandardJS is to ESLint. This commit
naively copies the RuboCop linter and fixer to point at the standardrb
executable. Any other adjustments are very minor (the only I can think
of is that standardrb takes a `--fix` option instead of
`--auto-correct`).
This raises a confusing point to me as both developer and a user: since
ale enables all linters by default, won't this run both RuboCop and
StandardRB (the results of which will almost always be in conflict with
one another)? How does ale already solve for this for the similar case
of StandardJS and ESLint?
It's common to add SwiftLint as a CocoaPod dependency, instead of as a global
binary. In this case we should use that version of SwiftLint before looking
for any others. Note that I'm also adding support for SwiftLint in ReactNative
projects here as well, where the Pods directory would be nested inside an ios
directory.
The linter can correctly parse pydocstyle output with any of the following
command-line options enabled: --explain, --source, --debug, and/or
--verbose
The command used to invoke the LSP process was being escaped wrong.
Also added a new option to set a different java executable and fixed the
documentation.
This fixes performance problems in Neovim, where every character results
in spawning a new clipboard-tool process.
Behaviour is not similarly pathological in Vim, but it still results in
an unnecessary amount of register churn.
There is currently a check that tries to prevent c-flags that contain
'-' in them from being unintentionally split and included in the list of
commands. For example, we wouldn't want "-fno-exceptions " to appear as
"-fno" and "-exceptions ". The way this check was done was by making sure
the last character of the split string was a space.
This meant that the very last option to appear in the compile command
was ignored (as it doesn't end with a space). This fix explicitly skips
the ends-with-space check on the last option in the command-line.
This isn't the best fix. Really we should be using the same
argument-processing rules as a shell would rather than just splitting on
'-'. That's a much larger and more complicated change though.
The output format used by older checkstyle versions differs from the one
of new versions. This commit adds a second parsing iteration on the
output lines with a suitable pattern to support both versions in
parallel. Due to the differences in the order of matching groups this is
hard to achieve in a single pass through the output lines.
An appropriate test case is added.
Removed ale_virualtext_prefix from debugging since it's not requried for
the functionality to work.
Sorted debugging info to make the list easier to navigate/diff.
- Add g:ale_virtualtext_cursor boolean to enable/disable it
- Add g:ale_virtualtext_prefix to configure what prefix to use (default:
'> ')
- Requires neovim 0.3.2's unreleased API `nvim_buf_set_virtual_text`
Problem: ocamlformat is configured to format files in-place and thus go
via creating a temporary file for that. Because temporary file resides
in a different directory ocamlformat can't find `.ocamlformat`
configuration files in an original location of source files.
Solution: ocamlformat since version 0.8 can read sources on stdin and
spur result on stdout. We reconfigure ocamlformat to use a simpler
interface.
Previously, elixir-ls would treat each sub-project within an umbrella as
standalone, which isn't desirable from a language server perspective.
Added ale#handlers#elixir#FindMixUmbrellaRoot, which locates the current
project's root and then continues searching upwards for a potential
umbrella project root. This literally looks just two levels up to keep
things simple while keeping in line with Elixir project conventions.
Use this new function to determine elixir-ls's LSP project root.
* Allow configuration of hamllint executable
The hamllint executable was hard-coded, preventing it from being
overridden. Fix the executable to be dynamic to allow custom executable
paths.
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.
Each LSP connection now stores its configuration dictionary. It is
initially empty (`{}`) and is updated each time the LSP connection is
started. When a change is detected, the workspace/didChangeConfiguration
message is sent to the LSP servers with the updated configuration.
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
* 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.
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.
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).
It wasn't immediately obvious that the `g:ale_fixers` cannot be a list,
and would allow the use of `*` to match all filetypes. I was hoping to
add a bit more detail to the README to make this clearer.
* 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`
When dializer isn't a dependency, mix dialyzer recompiles the whole
project because it's not possible to know if this command dialyzer exist
or not until recompilation is done. Then the timestamps of the project
is messed up which results in broken hot-loading. In this case, mix help
dialyzer would return zero which prevents compilation of the whole
project since dialyzer isn't installed, it's help manual doesn't exist.
When dialyzer is a dependency, mix dialyzer would just run the command.
In this case, mix help dialyzer would return 1 which allows mix dialyzer
to run.
* 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
"Pipfile" and "Pipfile.lock" files are also often located in Python module or
package directories and their presence is an okay heuristic for finding project
roots.
Pipenv doesn't do local virtualenvs by default, it uses a special local
directory to store them all.
However, if you run Pipenv with the PIPENV_VENV_IN_PROJECT environment variable
set to 1, it creates the virtual environment in the root of the project, under
the name ".venv". This is why I've added this as a possible virtualenv dir
name.
* 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.
* Set `--parser` option in Prettier's fixer
* Add expected `--parser` option to tests
* Disable Prettier `--parser` detection if file extension exists
* Manually default Prettier `--parser` to "babylon"
* Add `--parser` test for TypeScript
* Add tests for Prettier `--parser`
* Add JSON5 to the suggested fixer for Prettier
* Guard the ballooneval settings
* Mark main objectives to do to get nice Hover
* Make tweaks to make the tooltip work - See " XXX: comments
* Guard balloon_show call
* Use return instead of finish for functions
* ale#hover#show : Add optional arguments to specify arbtirary position
This change is requested to be able to call the function with mouse
position to enable hover information in vim's balloon
* ale#ballon#Disable : Remove feature guards
* ale#balloon : Show 'ALEHover' output on balloon if no diagnostic found
* ale#hover#HandleLSPResponse : remove the check for cursor position
This check prevented the 'ALEHover in balloon' feature, since mouse
position is almost never cursor position.
* ale#balloon#MessageForPos : Change the return of balloonexpr
balloonexpr evaluation now works even without balloon_show for basic
diagnostics, leaving the balloon_show call to ale#hover#Show, which can
then feature guard the call to avoid errors
* ale#hover#Response : Feature guard balloon_show calls
* ale#hover : always display 'Hover' information in messages
Also add a small comment to warn readers the different outputs the
ale#hover#Show will write to
* {LSP,TS}Response : use only variables from the Response
It is clearer that we only rely on l:options to get the relevant data to
build the LSP Response string
* hover#ShowDetails : fix an issue where not having focus broke balloons
The issue was caused by not using a buffer-specific version of getline()
to cap the value of the column sent in the message to LSP. Therefore a
cursor on column 10 in an inactive window could send a message with
column=0, if the active window had a buffer with too few lines
* {LSP,TS}Response : Remove redundant checks for balloon_show call
With the upcoming change in ale_set_balloons default value (see Pull
Request w0rp/ale#1565), this check will be useless
* balloonexpr? : Add a flag to separate hover#Show() calls
The goal of this flag is to make `:ALEHover` calls not pop a balloon
under the cursor, since the user has probably no interest in their
cursor while typing the command
The flag is a default argument which is overridden only in ballonexpr
call of ale#hover#Show, and stays set in the hover_map until the
callback for the LSP handles it.
There are no automated tests for this feature right now, and the nature
of the addition (one optional argument in the API) should make it
transparent to existing tests.
Since the differentiation is now possible, the check for moved cursor
has been put back in ale#hover#HandleLSPResponse
* ale#hover#hover_map : Protect accesses to hover_map
Using get() is safer than trying to access directly with ., as the tests
show.
* Raise timeout to try to get Appveyor happy
* Review : Fix comments
* Review : pass the optional argument 'called_from_balloonexpr' in a Dict
This optional dictionary has documentation just before the function
using it, ale#hover#Show, and allows easier extension in the future.
* 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.
Adding a couple of tests to demonstrate how IsCheckingBuffer behaves
during specific autocommand hooks:
* At ALELintPre, no linters have actually executed yet, hence
IsCheckingBuffer should be returning false.
* ALEJobStarted, fires as early as reasonably possible after a job has
successfully started, and hence hooking into IsCheckingBuffer here
should return true.
This distinction is important when using these two events during things
like statusline refreshes, namely for "linter running" indicators.
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.
This removes the argument if the specified toolchain is empty.
As far as I can tell there is no +nighly (or similar) option [1] leading to
the termination of the server. But since people needed this option and
have yet to complain about it it stays the default for now.
[1] https://github.com/rust-lang-nursery/rls/blob/master/src/main.rs#L87
* 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 multibyte string when linting text with redpen
* fix error when no string is provided, fix test's expect value
* remove ambiguious `==` operator
* Fixed (g)awk linter
* Made it secure, albeit less useful.
* Added gawk handler; the cpplint one was not working?
* Added gawk handler test.
* added warning to gawk handler.
* added gawk command callback test
* added comment about --source
* added back optional commandline option
* 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.
Support for elm-format as a fixer has existed since Sept 2017, but it's not
easy to discover because the fixer was named `format`. This breaks the
convention of the other fixers that use the full name in the registry.
I've gone ahead and fixed this discrepancy, but I left the existing registry
entry in place. We should move people towards using `elm-format` as the fixer
name, but I'd hate to break existing setups.
* If a Perl script compiles, there are only warnings and no errors
* Let the first Perl error or warning win.
Take the following example:
***
sub foo {
my $thing;
***
This might have the following messages when we compile it:
Missing right curly or square bracket at warning.pl line 7, at end of
line
syntax error at warning.pl line 7, at EOF
warning.pl had compilation errors.
With the current behaviour, we just get a "syntax error" message, which
isn't all that helpful. With this patch we get "Missing right curly or
square bracket".
* Fix variable scope and pattern matching syntax
* Use named variable to enhance clarity when matching Perl output
* Add more tests for Perl linter
* Remove unnecessary parens
* Simplify check for pattern match
* 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.
The test already handled arbitrary paths reasonably well, but setting
the directory interfered via leakage with others tests for some reason.
This patch removes the call to `SetDirectory` in the fixture setup and
the subsequent cleanup in the teardown as they are not required.
On macOS, Apple's command line toolchain installs very old `tidy`
command (It was released on 31 Oct 2006). It does not consider new specs
such as HTML5 so we should avoid it.
rustfmt normally acts on a file in place, and applies configuration
from rustfmt.toml files according to the path of the file.
Using a temporary file for rustfmt breaks this functionality, so
removing the '%t' from the rustfmt command.
Switches all vale instances to JSON output and provides an appropriate
handler for that. Without JSON, no end_col is provided and text
highlighting only catches the first character of every result.
In Go you can "vendor" packages by putting them in the `vendor/`
directory for a project. Adding the `-srcdir` argument makes `goimports`
pick up these packages, in addition to what you have in GOPATH.
Without this, `goimports` is not very useful, since most projects vendor
their packages.
This grew out of my work in #1193; to ensure the statusline was being
updated I had to add:
fun! s:redraw(timer)
redrawstatus
endfun
augroup ALEProgress
autocmd!
autocmd BufWritePost * call timer_start(100, function('s:redraw'))
autocmd User ALELint redrawstatus
augroup end
Which kind of works, but is ugly. With this, I can replace the
`BufWritePost` with:
autocmd User ALEStartLint redrawstatus
Which is much better, IMHO.
Actually, this patch actually replaces adding a function, since you can
do:
augroup ALEProgress
autocmd!
autocmd User ALEStartLint hi Statusline ctermfg=darkgrey
autocmd User ALELint hi Statusline ctermfg=NONE
augroup end
or:
let s:ale_running = 0
let l:stl .= '%{s:ale_running ? "[linting]" : ""}'
augroup ALEProgress
autocmd!
autocmd User ALEStartLint let s:ale_running = 1 | redrawstatus
autocmd User ALELint let s:ale_running = 0 | redrawstatus
augroup end
Both seem to work very well in my testing.
No need to `ale#Statusline#IsRunning()` anymore, I think?
* puppet: add test for puppet parser validate
* puppet: handle where parser validate doesn't supply the column
* puppet: add test for when parser validate doesn't supply column
* Fix puppet regex to handle Windows paths
- Re: f224ce8a37
- The issues that prompted the above commit which reverted changes made to `go build` and
`gometalinter` seemed to suggest that the main issue was with gometalinter and that
changes should be put into different commits so they are independent of each other
- This commit reinstates the changes to the `go build` linter which seem to be uncontested
and it also seems absolutely necessary to show errors from all files in the package which
may have caused a build failure.
The previous version relied on a zsh-specific behavior where
`<filename` after a pipe could redirect to the first command. This
is the standard way to do it.
* Added filename keys to gobuild and gometalinter
* Removed skipping files not in current package
* Removed `--include` for gometalinter
* Fixed the tests
GetCommand conditionally adds a filter (implemented as inline Ruby code
in the command line) to transform some of the problematic
Rails-specific eRuby syntax. Specifically, <%= tags are replaced with
<%.
This does not reduce the effectiveness of the linter, because the
transformed code is still evaluated.
This solution was suggested by @rgo at
https://github.com/w0rp/ale/issues/580#issuecomment-337676607.
GetCommand conditionally adds a filter (implemented as inline Ruby code
in the command line) to transform some of the problematic
Rails-specific eRuby syntax. Specifically, <%= tags are replaced with
<%.
This does not reduce the effectiveness of the linter, because the
transformed code is still evaluated.
This solution was suggested by @rgo at
https://github.com/w0rp/ale/issues/580#issuecomment-337676607.
Ale saves a temporary file (%t) which does not share the same path as
the original file, breaking import statements with relative URLs.
This fix sends content to `lessc` over stdin and adds
the current file (%s) as one of the included paths, so statements like
`@import '../utils' will correctly resolve based on the current file path.
There were a couple of issues
- `paste` requires a file argument
- `mktemp` requires a pattern argument
- `sort` doesn't support `-h`, but `-n` is enough for sorting on numbers, and `-s` was introduced to perform a stable sort instead.
The main issues were that BSD `sed` does not support:
- Alternation (`\|`) - solved by splitting to multiple patterns
- Bound shortcuts (`x\+`, `x\?`) - solved by replacing with `xx*` and `x\{0,1\}` respectively
- Lower-casing (`\L`) - solved by piping through `tr` instead (this will lowercase everything and not only the integration names, but I assumed that wasn't too much of an issue, as a portable alternative for the selective downcasing would be much more involved).
Looks like elm-make only respects /dev/null, even on Windows. The person
who wrote this linter maybe did not test it on Windows, and wrote the
code in the way you would expect to be solid by using NUL on Windows.
However it seems elm-make is not actually making use of /dev/null but
rather using it as a form of flag. Ironically this seems to be what is
already described in the comments; I added some clarification.
Implements suggestions and recommendations suggested by the first review
of the "Advance C# linter based on mcs -t:module (#952)" pull request.
- Clarifies and simplifies description of linters and options
- Added links to help file and marked the mcsc linter as to be run only
when file in buffer is saved or loaded.
- Added comments to the mcsc.vim file to clarify code
- removed type checks considered not necessary be reviewer.
- addresses findings by vader
- removed call to getcwd and cd in vim script
- handler expands file names relative to route of source tree into
absolute pathes. Fixes errors not being marked when vim is started
from subdirectory of source tree.
- implements tests for mcs.vim and mcsc.vim linter
The existing c-charp linter used the --syntax check mode of the mono mcs
compiler only. The new mcsc linter tries to compile the files located in
a directory tree located bejond the specified source directory or the
current one if no source is explicitly specified. The resulting module
target is placed in a temporary file managed by ale.
The existing c-charp linter used the --syntax check mode of the mono mcs
compiler only. The new mcsc linter tries to compile the files located in
a directory tree located bejond the specified source directory or the
current one if no source is explicitly specified. The resulting module
target is placed in a temporary file managed by ale.
This fixes slim-lint not honoring a `.rubocop.yml` in the file's or
parent directory. Due to the way slim-lint calls rubocop, it requires
the special `SLIM_LINT_RUBUCOP_CONF` env var to pick up the
`.rubocop.yml` if it is not run on the real file (which is the case
here).
See https://github.com/sds/slim-lint/blob/master/lib/slim_lint/linter/README.md#rubocop
* Add prettier fixer support for typescript
* Add prettier fixer support for css and scss
* Add prettier fixer support for json
* Use getbufvar() to get &filetype
* Detect and use CM files for smlnj
* Split into two checkers
- one for CM projects
- one for single SML files
* Fix some typos
* Fix error caught by writing tests
We want to actually use `glob` to search in paths upwards from us.
(Previously we were just searching in the current directory every time!)
* Fix errors from former test run
* Write tests for GetCmFile and GetExecutableSmlnj
* Typo in 'smlnj/' fixture filenames
This linter works by invoking the `thrift` compiler with the buffer
contents and reporting any parser and code generation issues.
The handler rolls its own output-matching loop because we have the
(unfortunate) requirement of handling error output that spans multiple
lines.
Unit tests cover both the command callback and handler, and there is
initial documentation for all of the option variables.
* Add support for prettier configuration file.
As of version 1.6.0, prettier allows passing a `--config` argument with
a path to a configuration file.
* Add test prettier configuration file.
* Add option to use local prettier configuration.
* Add description for new prettier option.
* Also check if the config is present before using it.
A limited number of clang-tidy checks can be used with C, too. I pretty much
copied and refactored the C++ clang-tidy linter, and added some documentation
about C-compatible checks.
This is the template for reporting ALE bugs. Make sure you try updating ALE
to a more recent version before reporting a bug. Look through existing bug
reports for similar issues before reporting a new one. Don't leave comments
about new bugs in the comment section for old issues.
Make sure to try disabling other plugins and trying to repeat your bug before
reporting it in ALE. Some times problems can arise when two plugins are used
together, but often your issues might be problems with other plugins.
-->
## Information
**VIM version**
<!-- Paste just the first two lines of :version here. -->
Operating System: <!-- Describe your operating system version. -->
## What went wrong
<!-- Describe what went wrong here. Be specific. -->
Something went wrong in specifically this place, and I also searched through both open and closed issues for the same problem before reporting a bug here.
Are you having trouble configuring ALE? Try asking for help on [Stack Exchange](https://vi.stackexchange.com/) or perhaps on [Reddit](https://www.reddit.com/r/vim/) instead. The GitHub issue tracker should be used for reporting bugs or asking for new features.
## Reproducing the bug
<!-- Write a list of steps below. -->
1. I did this.
2. Then this happened.
### :ALEInfo
<!-- Paste the output of :ALEInfo here. Try :ALEInfoToClipboard -->
<!-- Make sure to run :ALEInfo from the buffer where the bug occurred. -->
<!-- Read the output. You might figure out what went wrong yourself. -->
# Asynchronous Lint Engine [![GitHub Build Status](https://github.com/dense-analysis/ale/workflows/CI/badge.svg)](https://github.com/dense-analysis/ale/actions?query=event%3Apush+workflow%3ACI+branch%3Amaster++) [![AppVeyor Build Status](https://ci.appveyor.com/api/projects/status/r0ef1xu8xjmik58d/branch/master?svg=true)](https://ci.appveyor.com/project/dense-analysis/ale) [![Join the chat at https://gitter.im/vim-ale/Lobby](https://badges.gitter.im/vim-ale/Lobby.svg)](https://gitter.im/vim-ale/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
![ALE Logo by Mark Grealish - https://www.bhalash.com/](img/logo.jpg?raw=true)
ALE (Asynchronous Lint Engine) is a plugin for providing linting in NeoVim
![ALE Logo by Mark Grealish - https://www.bhalash.com/](https://user-images.githubusercontent.com/3518142/59195920-2c339500-8b85-11e9-9c22-f6b7f69637b8.jpg)
and Vim 8 while you edit your text files.
![linting example](img/example.gif?raw=true)
ALE (Asynchronous Lint Engine) is a plugin providing linting (syntax checking
and semantic errors) in NeoVim 0.2.0+ and Vim 8 while you edit your text files,
and acts as a Vim [Language Server Protocol](https://langserver.org/) client.
<imgsrc="https://user-images.githubusercontent.com/3518142/59195938-3a81b100-8b85-11e9-8e8d-6a601b1db908.gif"alt="A linting example with the darkspectrum color scheme in GVim."title="A linting example with the darkspectrum color scheme in GVim.">
ALE makes use of NeoVim and Vim 8 job control functions and timers to
ALE makes use of NeoVim and Vim 8 job control functions and timers to
run linters on the contents of text buffers and return errors as
run linters on the contents of text buffers and return errors as
@ -15,9 +17,30 @@ back to a filesystem.
In other words, this plugin allows you to lint while you type.
In other words, this plugin allows you to lint while you type.
In addition to linting support, ALE offers some support for fixing code with
ALE offers support for fixing code with command line tools in a non-blocking
formatting tools, and completion via Language Server Protocol servers, or
manner with the `:ALEFix` feature, supporting tools in many languages, like
servers with similar enough protocols, like `tsserver`.
`prettier`, `eslint`, `autopep8`, and more.
ALE acts as a "language client" to support a variety of Language Server Protocol
features, including:
* Diagnostics (via Language Server Protocol linters)
* Go To Definition (`:ALEGoToDefinition`)
* Completion (Built in completion support, or with Deoplete)
* Finding references (`:ALEFindReferences`)
* Hover information (`:ALEHover`)
* Symbol search (`:ALESymbolSearch`)
If you don't care about Language Server Protocol, ALE won't load any of the code
for working with it unless needed. One of ALE's general missions is that you
won't pay for the features that you don't use.
**Help Wanted:** If you would like to help maintain this plugin by managing the
many issues and pull requests that are submitted, please send the author an
email at [dev@w0rp.com](mailto:dev@w0rp.com?subject=Helping%20with%20ALE).
If you enjoy this plugin, feel free to contribute or check out the author's
other content at [w0rp.com](https://w0rp.com).
## Table of Contents
## Table of Contents
@ -26,116 +49,47 @@ servers with similar enough protocols, like `tsserver`.
You can install this plugin using [Vundle](https://github.com/VundleVim/Vundle.vim)
You can install this plugin using [Vundle](https://github.com/VundleVim/Vundle.vim)
by using the path on GitHub for this repository.
by adding the GitHub path for this repository to your `~/.vimrc`:
```vim
```vim
Plugin 'w0rp/ale'
Plugin 'dense-analysis/ale'
```
```
Then run the command `:PluginInstall` in Vim.
See the Vundle documentation for more information.
See the Vundle documentation for more information.
<aname="installation-with-vim-plug"></a>
### 3.iiii. Installation with Vim-Plug
You can install this plugin using [Vim-Plug](https://github.com/junegunn/vim-plug)
by adding the GitHub path for this repository to your `~/.vimrc`:
```vim
Plug 'dense-analysis/ale'
```
Then run the command `:PlugInstall` in Vim.
See the Vim-Plug documentation for more information.
<aname="contributing"></a>
<aname="contributing"></a>
## 4. Contributing
## 4. Contributing
If you would like to see support for more languages and tools, please
If you would like to see support for more languages and tools, please
[create an issue](https://github.com/w0rp/ale/issues)
[create an issue](https://github.com/dense-analysis/ale/issues)
or [create a pull request](https://github.com/w0rp/ale/pulls).
or [create a pull request](https://github.com/dense-analysis/ale/pulls).
If your tool can read from stdin or you have code to suggest which is good,
If your tool can read from stdin or you have code to suggest which is good,
support can be happily added for it.
support can be happily added for it.
If you are interested in the general direction of the project, check out the
If you are interested in the general direction of the project, check out the
[wiki home page](https://github.com/w0rp/ale/wiki). The wiki includes a
[wiki home page](https://github.com/dense-analysis/ale/wiki). The wiki includes
Roadmap for the future, and more.
a Roadmap for the future, and more.
If you'd liked to discuss the project more directly, check out the `#vim-ale` channel
If you'd liked to discuss the project more directly, check out the `#vim-ale` channel
on Freenode. Web chat is available [here](https://webchat.freenode.net/?channels=vim-ale).
on Freenode. Web chat is available [here](https://webchat.freenode.net/?channels=vim-ale).
@ -306,12 +392,28 @@ on Freenode. Web chat is available [here](https://webchat.freenode.net/?channels
### 5.i. How do I disable particular linters?
### 5.i. How do I disable particular linters?
By default, all available tools for all supported languages will be run.
By default, all available tools for all supported languages will be run. If you
If you want to only select a subset of the tools, simply create a
want to only select a subset of the tools, you can define `b:ale_linters` for a
`g:ale_linters` dictionary in your vimrc file mapping filetypes
single buffer, or `g:ale_linters` globally.
to lists of linters to run.
The recommended way to configure linters is to define a List in an ftplugin
file.
```vim
```vim
" In ~/.vim/ftplugin/javascript.vim, or somewhere similar.
" Enable ESLint only for JavaScript.
let b:ale_linters = ['eslint']
" Equivalent to the above.
let b:ale_linters = {'javascript': ['eslint']}
```
You can also declare which linters you want to run in your vimrc file, before or
after ALE has been loaded.
```vim
" In ~/.vim/vimrc, or somewhere similar.
let g:ale_linters = {
let g:ale_linters = {
\ 'javascript': ['eslint'],
\ 'javascript': ['eslint'],
\}
\}
@ -322,13 +424,68 @@ be run for those languages, just as when the dictionary is not defined.
Running many linters should not typically obstruct editing in Vim,
Running many linters should not typically obstruct editing in Vim,
as they will all be executed in separate processes simultaneously.
as they will all be executed in separate processes simultaneously.
If you don't want ALE to run anything other than what you've explicitly asked
for, you can set `g:ale_linters_explicit` to `1`.
```vim
" Only run linters named in ale_linters settings.
let g:ale_linters_explicit = 1
```
This plugin will look for linters in the [`ale_linters`](ale_linters) directory.
This plugin will look for linters in the [`ale_linters`](ale_linters) directory.
Each directory within corresponds to a particular filetype in Vim, and each file
Each directory within corresponds to a particular filetype in Vim, and each file
in each directory corresponds to the name of a particular linter.
in each directory corresponds to the name of a particular linter.
<aname="faq-get-info"></a>
### 5.ii. How can I see what ALE has configured for the current file?
Run the following to see what is currently configured:
```vim
:ALEInfo
```
<aname="faq-coc-nvim"></a>
### 5.iii. How can I use ALE and coc.nvim together?
[coc.nvim](https://github.com/neoclide/coc.nvim) is a popular Vim plugin written
in TypeScript and dependent on the [npm](https://www.npmjs.com/) ecosystem for
providing full IDE features to Vim. Both ALE and coc.nvim implement
[Language Server Protocol](https://microsoft.github.io/language-server-protocol/)
(LSP) clients for supporting diagnostics (linting with a live server), and other
features like auto-completion, and others listed above.
ALE is primarily focused on integrating with external programs through virtually
any means, provided the plugin remains almost entirely written in Vim script.
coc.nvim is primarily focused on bringing IDE features to Vim. If you want to
run external programs on your files to check for errors, and also use the most
advanced IDE features, you might want to use both plugins at the same time.
The easiest way to get both plugins to work together is to configure coc.nvim to
send diagnostics to ALE, so ALE controls how all problems are presented to you,
and to disable all LSP features in ALE, so ALE doesn't try to provide LSP
features already provided by coc.nvim, such as auto-completion.
1. Open your coc.nvim configuration file with `:CocConfig` and add
`"diagnostic.displayByAle": true` to your settings.
2. Add `let g:ale_disable_lsp = 1` to your vimrc file, before plugins are
loaded.
You can also use `b:ale_disable_lsp` in your ftplugin files to enable or disable
LSP features in ALE for different filetypes. After you configure coc.nvim and
ALE this way, you can further configure how problems appear to you by using all
of the settings mentioned in ALE's help file, including how often diagnostics
are requested. See `:help ale-lint`.
The integration between ALE and coc.nvim works using an API ALE offers for
letting any other plugin integrate with ALE. If you are interested in writing a
similar integration, see `:help ale-lint-other-sources`.
<aname="faq-keep-signs"></a>
<aname="faq-keep-signs"></a>
### 5.ii. How can I keep the sign gutter open?
### 5.iv. How can I keep the sign gutter open?
You can keep the sign gutter open at all times by setting the
You can keep the sign gutter open at all times by setting the
`g:ale_sign_column_always` to 1
`g:ale_sign_column_always` to 1
@ -339,7 +496,7 @@ let g:ale_sign_column_always = 1
<aname="faq-change-signs"></a>
<aname="faq-change-signs"></a>
### 5.iii. How can I change the signs ALE uses?
### 5.v. How can I change the signs ALE uses?
Use these options to specify what text should be used for signs:
Use these options to specify what text should be used for signs:
@ -357,9 +514,35 @@ highlight clear ALEErrorSign
highlight clear ALEWarningSign
highlight clear ALEWarningSign
```
```
<aname="faq-change-highlights"></a>
### 5.vi. How can I change or disable the highlights ALE uses?
ALE's highlights problems with highlight groups which link to `SpellBad`,
`SpellCap`, `error`, and `todo` groups by default. The characters that are
highlighted depend on the linters being used, and the information provided to
ALE.
Highlighting can be disabled completely by setting `g:ale_set_highlights` to
`0`.
```vim
" Set this in your vimrc file to disabling highlighting
let g:ale_set_highlights = 0
```
You can control all of the highlights ALE uses, say if you are using a different
color scheme which produces ugly highlights. For example:
```vim
highlight ALEWarning ctermbg=DarkMagenta
```
See `:help ale-highlights` for more information.
<aname="faq-statusline"></a>
<aname="faq-statusline"></a>
### 5.iv. How can I show errors or warnings in my statusline?
### 5.vii. How can I show errors or warnings in my statusline?
[vim-airline](https://github.com/vim-airline/vim-airline) integrates with ALE
[vim-airline](https://github.com/vim-airline/vim-airline) integrates with ALE
for displaying error information in the status bar. If you want to see the
for displaying error information in the status bar. If you want to see the
@ -372,8 +555,16 @@ let g:airline#extensions#ale#enabled = 1
```
```
If you don't want to use vim-airline, you can implement your own statusline
If you don't want to use vim-airline, you can implement your own statusline
function without adding any other plugins. ALE provides a function for counting
function without adding any other plugins. ALE provides some functions to
the number of problems for this purpose, named `ale#statusline#Count`.
assist in this endeavour, including:
* `ale#statusline#Count`: Which returns the number of problems found by ALE
for a specified buffer.
* `ale#statusline#FirstProblem`: Which returns a dictionary containing the
full loclist details of the first problem of a specified type found by ALE
in a buffer. (e.g. The first style warning in the current buffer.)
This can be useful for displaying more detailed information such as the
line number of the first problem in a file.
Say you want to display all errors as one figure, and all non-errors as another
Say you want to display all errors as one figure, and all non-errors as another
figure. You can do the following:
figure. You can do the following:
@ -395,18 +586,30 @@ endfunction
set statusline=%{LinterStatus()}
set statusline=%{LinterStatus()}
```
```
See `:help ale#statusline#Count()` for more information.
See `:help ale#statusline#Count()` or `:help ale#statusline#FirstProblem()`
for more information.
<aname="faq-lightline"></a>
### 5.viii. How can I show errors or warnings in my lightline?
[lightline](https://github.com/itchyny/lightline.vim) does not have built-in
support for ALE, nevertheless there is a plugin that adds this functionality: [maximbaz/lightline-ale](https://github.com/maximbaz/lightline-ale).
For more information, check out the sources of that plugin, `:help ale#statusline#Count()` and [lightline documentation](https://github.com/itchyny/lightline.vim#advanced-configuration).
<aname="faq-echo-format"></a>
<aname="faq-echo-format"></a>
### 5.v. How can I change the format for echo messages?
### 5.ix. How can I change the format for echo messages?
There are 3 global options that allow customizing the echoed message.
There are 3 global options that allow customizing the echoed message.
- `g:ale_echo_msg_format` where:
- `g:ale_echo_msg_format` where:
* `%s` is the error message itself
* `%s` is the error message itself
* `%...code...%` is an optional error code, and most characters can be
written between the `%` characters.
* `%linter%` is the linter name
* `%linter%` is the linter name
* `%severity` is the severity type
* `%severity%` is the severity type
- `g:ale_echo_msg_error_str` is the string used for error severity.
- `g:ale_echo_msg_error_str` is the string used for error severity.
- `g:ale_echo_msg_warning_str` is the string used for warning severity.
- `g:ale_echo_msg_warning_str` is the string used for warning severity.
@ -420,26 +623,36 @@ let g:ale_echo_msg_format = '[%linter%] %s [%severity%]'
" warning: (3) unable to parse response signature, expected 'response [<HTTP status code>] [(<media type>)]'; line 4, column 3k - line 4, column 22
" warning: (10) message-body asset is expected to be a pre-formatted code block, separate it by a newline and indent every of its line by 12 spaces or 3 tabs; line 30, column 5 - line 30, column 9; line 31, column 9 - line 31, column 14; line 32, column 9 - line 32, column 14
letl:pattern='\(^.*\): (\d\+) \(.\{-\}\); line \(\d\+\), column \(\d\+\) - line \d\+, column \d\+\(.*; line \d\+, column \d\+ - line \(\d\+\), column \(\d\+\)\)\{-\}$'
" ** (CompileError) apps/sim/lib/sim/server.ex:87: undefined function update_in/4
"
" TODO: Warning format
" warning: variable "foobar" does not exist and is being expanded to "foobar()", please use parentheses to remove the ambiguity or change the variable name