* 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
- 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 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
* 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.
