Full restart of null-ls

[otavioschwanck]

Issues

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

Feature description

While using some diagnostic (like rubocop), it can throw and error and stop working.

null-ls doesn't have any way to restart after it occurs. When it happen, the diagnostic on the screen also get bugged (i have to manually remove withvim.diagnostic.reset().

After the first time that the error happens, instead of trying to restart (could have a retry every X seconds with max attempts or something), the null-ls just stop working and i have to restart neovim to make work again.

Already tried null_ls.toggle({}) and doesn't work. After first error, it is gone completely.

Would be awesome to have a NullLsRestart that make null restart like a new instance of neovim was open.

Example of an random error:

Help

Yes, but I don't know how to start. I would need guidance

Implementation help

No response

[jose-elias-alvarez]

I'm not opposed to adding a function to reset error state and allow linters to restart, but my priority in this case would be to make sure that specific error is handled so the source doesn't shut down completely. The reason unhandled errors cause the source to stop working is precisely because they're unhandled and so may lead to weird behavior, but if this happens regularly then we should look into handling it.

[otavioschwanck]

I'm not opposed to adding a function to reset error state and allow linters to restart, but my priority in this case would be to make sure that specific error is handled so the source doesn't shut down completely. The reason unhandled errors cause the source to stop working is precisely because they're unhandled and so may lead to weird behavior, but if this happens regularly then we should look into handling it.

Most of time is one character strange that a type or a little typo that makes the lint stop working, but the next character i type fixes. But this one character make the null-ls stop working completely (just because of the error on rubocop)

[SetsuikiHyoryu]

I have a similar issue where Volar and Prettierd both format Vue files when using Volar in lsp-config, and the formatting is determined by the last client that runs. When I restart lsp-config, null-ls does not restart, causing the restarted Volar client to be positioned after Prettierd. This results in the formatting being ultimately handled by Volar. I really need a way to restart null-ls to manually determine the loading order of the clients.

[jose-elias-alvarez]

I have a similar issue where Volar and Prettierd both format Vue files when using Volar in lsp-config, and the formatting is determined by the last client that runs. When I restart lsp-config, null-ls does not restart, causing the restarted Volar client to be positioned after Prettierd. This results in the formatting being ultimately handled by Volar. I really need a way to restart null-ls to manually determine the loading order of the clients.

This is a separate issue - null-ls isn't managed by nvim-lspconfig, so the :LspRestart command will not affect it. Implementing a full-on client restart command isn't as easy as it seems (see #896) but even if we did, we'd still need to clear internal state in order to handle the OP's issue.