Open elyscape opened 6 years ago
ALE will continue checking buffers while you aren't looking at them, and the results can be ready before you switch back to them again. This also works for fixing buffers, too. ALE will apply some changes that require the buffers to be visible when they become visible again.
There's a function for cleaning up everything for a buffer, including killing all of the jobs, but it's not part of ALE's public API. What I think I can do for you is carefully make that function part of the public API, and support it in some way, so you can write an autocmd
command to clean up buffers on BufWinLeave
.
ALE will continue checking buffers while you aren't looking at them, and the results can be ready before you switch back to them again.
Right, but my point is that, if g:ale_lint_on_enter
is 1
, the results will be discarded immediately upon entering the buffer again.
Ah, I see what you mean. I hadn't thought of that before.
If
g:ale_lint_on_enter
is set to1
, the default, ALE will run the applicable linters on a buffer when theBufWinEnter
andBufRead
events fire. Quickly switching between buffers for files that have slow, heavy linters attached (e.g. gometalinter) will result in those linters being spun up concurrently for each buffer. Meanwhile, one implication ofg:ale_lint_on_enter
being set to1
is that, when switching to a buffer, the loclist will be cleared and repopulated. This means that the output of linters on non-active buffers is never actually used.The upshot of all this is that it should be safe to kill any running linters on
BufWinLeave
ifg:ale_lint_on_enter
is1
. This would have the benefit of reducing CPU load and battery use in this scenario.