Cancelling of linter requests when new changes are made

[yorickpeterse]

Issues

• I have checked existing issues and there are no existing ones with the same request.

Feature description

When a linter is slow, it may take a while for its diagnostics to appear. If you make new changes in the mean time, chances are those diagnostics are no longer relevant. In addition, these changes produce new diagnostics. The result is that once your first set of diagnostics are displayed, new diagnostics may be displayed almost immediately after.

As an example, consider this series of events:

1. debounce = 500
2. You make some changes, then wait half a second
3. The linter needs at least one second to produce its diagnostics
4. You make some new changes in the mean time
5. This time the linter is much faster

The result is that the diagnostics from step 3 are displayed at some point, then are cleared and the diagnostics from step 4 are displayed. As this process involves changing signs, underlines, etc this can be quite jarring.

It would be nice if null-ls could somehow either cancel outstanding requests, or just ignore the diagnostics produced if a new request for diagnostics is made.

This NeoVim PR might be useful for this: neovim/neovim#15949

Help

No

Implementation help

No response

[bpinto]

I'm wondering if this could be related to sequential formatting. Something like

formatA
|> doDiscardIfChanged
|> formatB
|> doDiscardIfChanged
|> doWrite

[jose-elias-alvarez]

This would be a nice improvement, but implementing it properly might be tricky. The way null-ls produces diagnostics is to simply run all registered generators for the current filetype in response to textDocument-related notifications, so I don't think we'd be able to use request cancellation.

The ideal solution would be to track each generator's runs and completely cancel previous runs on each new run, since that would solve this issue and help with performance as well, but from my limited understanding it's not that straightforward to do so (Plenary has an open PR that would make this a lot easier if merged).

Off the top of my head, one simple solution might be to track the changetick when the notification is received and ignore received results if the changetick doesn't match. I'll try that out when I have a chance and see if it actually works.

[jose-elias-alvarez]

Could you try #320? It seems to be working fine for me, but I don't use any super-slow linters so I can't say for sure.