fixes #1105 : check for LSP progress, report working/linted file

[lafleurdeboum]

This small PR adds a handler to vim.lsp.handlers, checking if a language server reported that it was working on the current file and is not done yet. If it's the case, a "Working" icon is appended to the diagnostics component. Then when the language server reports that it's done working, if no error, warning, hint or info is declared, the "Working" icon is replaced by an "OK" icon.

This behaviour is useful when working on heavyweight linters, like rust-analyzer, that can take a minute to lint a project. The user gets the bare useful information with very little overhead. Unfortunately, several language servers don't report their progress (thinking about vim-language-server and bash-language-server. In this case, I found no way to make sure that a linting is currently running. Indeed, the vim.diagnostic API lets any process diagnose what they please. My intention is to ask vim-language-server and bash-language-server to declare a minimal work progress, since this behaviour seems quite standard.

I tested my PR against luacheck and it succeeded. I also tried to respect the project's customs (like indentation). Any comment greatly appreciated !

[Slotos]

gopls will emit a "begin" event when encountering an issue loading workspace, with no followup "end". In order to recover from bad actors, LSP progress handlers need to implement a debounced clear routine.

[lafleurdeboum]

Hi @Slotos, thanks for caring ! I don't use to use Go, could you show me how to reproduce the bug, or perhaps point me to a small repo that would reproduce it, so that I can implement this debounce ? I often use luals, vimls, bashls and rust-analyzer, and I never faced that issue (I suppose the issue would imply having both the "working" and either of "ok" or "warning" icons).

…

On 18 November 2023 06:55:25 GMT+08:00, Dmytro Soltys ***@***.***> wrote: @Slotos commented on this pull request. > @@ -48,12 +50,25 @@ function M:init(options) '### diagnostics.sources\n\nno sources for diagnostics configured.\nPlease specify which diagnostics source you want lualine to use with `sources` option.\n' ) end + + -- Check if a language server reports working progress. + self.lsp_started = false + self.lsp_working = false + vim.lsp.handlers["$/progress"] = function(_, result) + self.lsp_started = true + if result.value.kind == "end" then + self.lsp_working = false `gopls` will emit a "begin" event when encountering an issue loading workspace, with no followup "end". In order to recover from bad actors, LSP progress handlers need to implement a debounced clear routine. -- Reply to this email directly or view it on GitHub: #1144 (review) You are receiving this because you authored the thread. Message ID: ***@***.***>

[Slotos]

In my case it was enough to initiate an edit on a new go buffer in a directory with no go.mod in its hierarchy with gopls set up. So something like:

:=require('lspconfig').gopls.setup{}
:new test.go

I was implementing a primitive progress reporter, and saw gopls message getting stuck in a routine very similar to the one I commented on. When logging progress messages, I saw “begin”, “end”, and “begin” messages arrive in that order.

[lafleurdeboum]

Thanks ! I was able to reproduce this issue, and solved it by reacting to "report" signals from `$/progress` instead of "begin". It does solve the issue with `gopls` sending a lone " begin" signal before failing. It's indeed cleaner like that.

…

On 18 November 2023 18:36:15 GMT+08:00, Dmytro Soltys ***@***.***> wrote: In my case it was enough to initiate an edit on a new go buffer in a directory with no `go.mod` in its hierarchy with gopls set up. So something like: ``` :=require('lspconfig').gopls.setup{} :new test.go ``` I was implementing a primitive progress reporter, and saw gopls message getting stuck in a routine very similar to the one I commented on. When logging progress messages, I saw “begin”, “end”, and “begin” messages arrive in that order. -- Reply to this email directly or view it on GitHub: #1144 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[lafleurdeboum]

Side note : we won't get the "ok" icon if no language server reported working on the current buffer. As a matter of fact, not collecting any error message doesn't imply that the file was linted, either by a language server or by any other linting process. Is anyone aware of any means to know that the buffer _was_ indeed linted ?

…

On 18 November 2023 18:36:15 GMT+08:00, Dmytro Soltys ***@***.***> wrote: In my case it was enough to initiate an edit on a new go buffer in a directory with no `go.mod` in its hierarchy with gopls set up. So something like: ``` :=require('lspconfig').gopls.setup{} :new test.go ``` I was implementing a primitive progress reporter, and saw gopls message getting stuck in a routine very similar to the one I commented on. When logging progress messages, I saw “begin”, “end”, and “begin” messages arrive in that order. -- Reply to this email directly or view it on GitHub: #1144 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>