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.
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.
`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.
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.
- 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`
* 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.
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.
Felix Maurer
w0rp
Luan Santos
Felipe Sere
Chris Marchesi
Rafael Lerm
Martin Tournoij