| Age | Commit message (Collapse) | Author |
|---|
|
* 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
|
|
Fix passing file to languagetool
|
|
* 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
|
|
|
|
|
|
javac: Don't assume src/main/java always exists
|
|
* Add lsp_config for rls
* Add working config example and test
|
|
Some projects I have only have src/test/java (no /src/main/java), which
seemed to break some incorrect assumptions the linter had.
|
|
python/bandit: Use .bandit configuration file
|
|
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>
|
|
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>
|
|
* add project_root_callback for tsserver
* add tests for tsserver project root
* Update test/command_callback/test_javascript_tsserver_command_callback.vader
|
|
Add settings for the Alex linter
|
|
Document and test ale_python_vulture_options
|
|
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>
|
|
* Add pylama for python
* Consolidate python traceback handling
|
|
|
|
|
|
|
|
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.
|
|
* 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
|
|
Pass --compiler flag to elm-test when linting 0.19 tests
|
|
|
|
* sugarss support + bonus naming Sass correctly
* cleanup + alphabetic ordering
|
|
Add g:haskell_stack_ghc_options like …_cabal_ghc_…
|
|
* Added VHDL file support with ghdl compiler
* Update ghdl.vim
* Create vcom.vim
* Create xvhdl.vim
* Update xvlog.vim
* Added documentation for VHDL & Verilog linters
* Added tests to VHDL & Verilog linters
|
|
|
|
Adds new option `g:haskell_stack_ghc_options` which passes options to
`stack ghc`. This is implemented similiarly to
`g:haskell_cabal_ghc_options`.
|
|
Resolves #1443.
Heavily inspired by the analogous support added for elixir-ls.
|
|
This makes elm make linter work when elm is not installed globally.
|
|
|
|
* Support textlint for reStructuredText
* Add linter test for textlint rst
|
|
|
|
* Add textlint for asciidoc
* Add textlint --fix
|
|
* 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
|
|
most projects will have an elm.json file (>= 0.19) or elm-package.json (< 0.19)
|
|
- 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
|
|
hsanson/368-chktex-latex-report-errors-from-wrong-file
Fix 368 - Lacheck reports errors from input{} files.
|
|
|
|
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?
|
|
Add bibclean fixer support
|
|
The linter can correctly parse pydocstyle output with any of the following
command-line options enabled: --explain, --source, --debug, and/or
--verbose
|
|
Previous implementation required one to have sass-lint globally. This
allows you to have it locally, override the executable and add options.
|
|
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 reverts commit 1c89495d771ec6518599bea83dd11a7c1d66ba73, reversing
changes made to 4b4b09593b2b090282981d69a9647a3c91d1f8b9.
|
|
Closes #1910
|
