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.
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.
* 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
* 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
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?
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.
- 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`
This adds generic configuration dictionary support to the elixir-ls
linter. This is useful for disabling its built-in Dialyzer support, for
example, which can improve startup time.
The configuration dictionary is a little verbose. I considered reducing
the user configuration to only the nested settings dictionary (and
having the linter implementation wrap it in the top-level `elixirLS`
dictionary), but leaving it fully configurable simplifies the code and
removes any assumptions about current or future ElixirLS behavior.
This is the callback-based variant of the existing `lsp_config` linter
option. It serves the same purpose but can be used when more complicated
processing is needed.
`lsp_config` and `lsp_config_callback` are mutually exclusive options;
if both an given, a linter preprocessing error will be raised.
The runtime logic has been wrapped in `ale#lsp_linter#GetConfig` for
convenience, similar to `ale#lsp_linter#GetOptions`.
This also adds documentation and an `AssertLSPConfig` test function for
completeness.
* add prolog/swipl linter
* use load_files/2 instead of read_term/2
Because it also checks some semantic warnings / errors
not only syntactic warnings / errors.
e.g.:
* singleton warning
* discontiguous warning
* ...
cf. http://www.swi-prolog.org/pldoc/doc_for?object=style_check/1
* support error messages with no line number
:- module(module_name, [pred/0]).
causes
ERROR: Exported procedure module_name:pred/0 is not defined
* add test for prolog/swipl handler
* cosmetic fixes
* detect timeout using SIGALRM
* rename g:prolog_swipl_goals to g:prolog_swipl_load
* write doc for prolog/swipl linter
* update toc and README
* fix ignore patterns
ElixirLS (https://github.com/JakeBecker/elixir-ls) is an LSP server for
Elixir. It's distributed as a release package that can be downloaded
from https://github.com/JakeBecker/elixir-ls/releases or built locally.
The easiest way to start it is via Unix- and Win32-specific helper
scripts, so that's the basis of this command integration. Alternatively,
we could implement the contents of those platform-specific scripts in
the linter's command callback in a language-neutral way, but there isn't
any benefit to doing that aside from eliminating the platform check, and
that could prove to be too tight of a coupling going forward.
* Add better support for Haskell stack compiler tools
This commit adds support for `stack` as the executable of a tool. This
follows a pattern that has been implemented for `bundler`'s tool chain.
* Move hlint command to linter file
* Add vader test for stack exec handling
* Update ghc-mod to support stack execution
`ghc-mod` was previously broken into 2 linters.
1. ghc_mod
2. stack_ghc_mod
This additional linter is not necessary with proper support for
executable variables and `stack exec` handling.
* Support stack exec in hfmt
* Support stack in hdevtools
In a lint context, it's useful to assume that included files sit next to
the current file by default. Users can still further customize this
configuration variable to add more include paths.
When set to true, and the buffer is currently inside a pipenv,
GetExecutable will return "pipenv", which will trigger the existing
functionality to append the correct pipenv arguments to run each linter.
Defaults to false.
I was going to implement ale#python#PipenvPresent by invoking
`pipenv --venv` or `pipenv --where`, but it seemed to be abominably
slow, even to the point where the test suite wasn't even finishing
("Tried to run tests 3 times"). The diff is:
diff --git a/autoload/ale/python.vim b/autoload/ale/python.vim
index 7baae079..8c100d41 100644
--- a/autoload/ale/python.vim
+++ b/autoload/ale/python.vim
@@ -106,5 +106,9 @@ endfunction
" Detects whether a pipenv environment is present.
function! ale#python#PipenvPresent(buffer) abort
- return findfile('Pipfile.lock', expand('#' . a:buffer . ':p:h') . ';') isnot# ''
+ let l:cd_string = ale#path#BufferCdString(a:buffer)
+ let l:output = systemlist(l:cd_string . 'pipenv --where')[0]
+ " `pipenv --where` returns the path to the dir containing the Pipfile
+ " if in a pipenv, or some error text otherwise.
+ return strpart(l:output, 0, 18) !=# "No Pipfile present"
endfunction
Using vim's `findfile` is much faster, behaves correctly in the majority
of situations, and also works reliably when the `pipenv` command doesn't
exist.
It can be necessary to pass options to the puppet parser validation. The
most glaring example of this is when using Puppet 3, with the
`parser = future` option enabled. This update allows adding
`--parser=future` to the options passed to Puppet.
* Add stylish-haskell as a fixer
`stylish-haskell` is a common formatting tool for the haskell toolchain.
It is not as advanced as `brittany` or `hindent`, but it is commonly
used for formatting of imports and data declarations. This adds it as a
fixer in ALE.
* Adding support for haskell-ide-engine
* Work with the current directory if no stack.yaml file is found
* Added Cabal file detection, updated documentation and added tests
* Updated help
fixes#1738
- Replace previous `hh_client` usage with LSP client
- Add `HHAST` linter
- Split Hack from PHP: Hack is increasingly diverging from PHP:
- Hack tools do not understand PHP
- Most PHP tools do not handle Hack code well (including vim's syntax
highightling files)
- http://github.com/hhvm/vim-hack now sets filetype to `hack`
