fixes #1105 : check for LSP progress, report working/linted file #1144
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Slotos
reviewed
Nov 17, 2023
| vim.lsp.handlers["$/progress"] = function(_, result) | ||
| self.lsp_started = true | ||
| if result.value.kind == "end" then | ||
| self.lsp_working = false |
There was a problem hiding this comment.
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.
|
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: ***@***.***>
|
|
In my case it was enough to initiate an edit on a new go buffer in a directory with no 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. |
|
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: ***@***.***>
|
|
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: ***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 thediagnosticscomponent. 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, thevim.diagnosticAPI lets any process diagnose what they please. My intention is to askvim-language-serverandbash-language-serverto declare a minimal work progress, since this behaviour seems quite standard.I tested my PR against
luacheckand it succeeded. I also tried to respect the project's customs (like indentation). Any comment greatly appreciated !