- 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.
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.
* 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
* FIX: use mix from the project root directory
* Move find root project function to autoloaded handlers
* add tests for #ale#handlers#elixr#FindMixProjectRoot
* 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
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.
* 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.
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`
"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.
