* Update section 5.viii in the README with ALEJobStarted and re-format
the example.
* Add an extra line after documentation update to ensure consistency
with the rest of the doc.
Adding a couple of tests to demonstrate how IsCheckingBuffer behaves
during specific autocommand hooks:
* At ALELintPre, no linters have actually executed yet, hence
IsCheckingBuffer should be returning false.
* ALEJobStarted, fires as early as reasonably possible after a job has
successfully started, and hence hooking into IsCheckingBuffer here
should return true.
This distinction is important when using these two events during things
like statusline refreshes, namely for "linter running" indicators.
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.
Chris Marchesi