client: option to suppress language client start error message popup #1011
Comments
|
Actually, it is on purpose that these errors are not suppressed since they indicate a deeper underlying problem (e.g. the server crashed or didn't start at all). In that latest you can customize the message that is shown in these cases. See Can you explain why this is a normal behavior for your language server? |
Some of our advanced users launch our language server in what we call proxy mode.
Can we customize the followup action? We want more than the "Go to output" option - bug report generation. When the user chooses the option, the extension collects necessary data (anonymized server crash trace, system info) and pre-fills a github issue. Finally, I tested this proxy mode setup after removing all our custom
|
|
I see your point. What we could do is the following: add an optional See code: andWould you like to give this a try and see whether it would improve the situation for you. We would also need to do something for the |
…tom error handler From vscode-languageclient v8.0.x (LSP 3.17), the language client reports the start errors specially and surfaces them as user visible popups regardless revealOutputChannelOn setting. Thus, our error popups are no longer necessary. Remove this. When an error occurs during initialization, the connection to the server shuts down which triggers the close handler. Previously, we suggested gopls issue report from both initializationFailedHandler and errorHandler.closed handler. That now results in two gopls issue report suggestions. Instead, stash the initialization failure error, and handle the suggestion prompt from one place. Note - in case of initializtion error, there is no point of retrying 5 times. We also explicitly set the error & connection close handlers messages to empty when requesting for continue/restart action, which will suppresses the default error message popups. While we are here, we improve the go status bar's language server state report by updating it when the language server connection close is obeserved. Updates microsoft/vscode-languageserver-node#1011 Fixes #2300 Change-Id: I8b20cf11ebb61ab474950440fc46ff23f7b0b826 Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/414457 Reviewed-by: Jamal Carvalho <jamal@golang.org> TryBot-Result: kokoro <noreply+kokoro@google.com> Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
…s from custom error handler From vscode-languageclient v8.0.x (LSP 3.17), the language client reports the start errors specially and surfaces them as user visible popups regardless revealOutputChannelOn setting. Thus, our error popups are no longer necessary. Remove this. When an error occurs during initialization, the connection to the server shuts down which triggers the close handler. Previously, we suggested gopls issue report from both initializationFailedHandler and errorHandler.closed handler. That now results in two gopls issue report suggestions. Instead, stash the initialization failure error, and handle the suggestion prompt from one place. Note - in case of initializtion error, there is no point of retrying 5 times. We also explicitly set the error & connection close handlers messages to empty when requesting for continue/restart action, which will suppresses the default error message popups. While we are here, we improve the go status bar's language server state report by updating it when the language server connection close is obeserved. Updates microsoft/vscode-languageserver-node#1011 Fixes #2300 Change-Id: I8b20cf11ebb61ab474950440fc46ff23f7b0b826 Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/414457 Reviewed-by: Jamal Carvalho <jamal@golang.org> TryBot-Result: kokoro <noreply+kokoro@google.com> Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> (cherry picked from commit 99369b6) Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/414460 Reviewed-by: Suzy Mueller <suzmue@golang.org>
|
Thanks @dbaeumer Meanwhile I found explicitly specifying an empty message ( However, I still couldn't avoid some of the forced popups in certain cases. See this code that handles closed connection (e.g. connection closed by server): vscode-languageserver-node/client/src/common/client.ts Lines 1460 to 1470 in 60d4ecb If the client is also in the I think this problem will be present even with your |
dbaeumer
added
feature request
help wanted
The vscode-languageclient library introduced breaking API changes in the 8.X version that require changes to our extension to use: - Remove use of onReady() to wait for start of the LS and use start() instead - All features that implement StaticFeature need to use the updated interface In addition to the above were interface changes to ErrorHandler. In applying these changes, it introduced duplicate error messages when loading the extension with incorrect settings. In effect, turning 1 or 2 messages into 3 or 4, depending on what was misconfigured. These cannot be customized: microsoft/vscode-languageserver-node#1011 This commit solves this by removing use of the ExtensionErrorHandler class and instead using inline methods for both initializationFailedHandler and errorHandler to detect failed extension errors. It avoids the duplicate methods by not using the ErrorAction message property and instead keeping track of whether or not an InitializeError was detected.
The vscode-languageclient library introduced breaking API changes in the 8.X version that require changes to our extension to use: - Remove use of onReady() to wait for start of the LS and use start() instead - All features that implement StaticFeature need to use the updated interface In addition to the above were interface changes to ErrorHandler. In applying these changes, it introduced duplicate error messages when loading the extension with incorrect settings. In effect, turning 1 or 2 messages into 3 or 4, depending on what was misconfigured. These cannot be customized: microsoft/vscode-languageserver-node#1011 This commit solves this by removing use of the ExtensionErrorHandler class and instead using inline methods for both initializationFailedHandler and errorHandler to detect failed extension errors. It avoids the duplicate methods by not using the ErrorAction message property and instead keeping track of whether or not an InitializeError was detected.
The vscode-languageclient library introduced breaking API changes in the 8.X version that require changes to our extension to use: - Remove use of onReady() to wait for start of the LS and use start() instead - All features that implement StaticFeature need to use the updated interface In addition to the above were interface changes to ErrorHandler. In applying these changes, it introduced duplicate error messages when loading the extension with incorrect settings. In effect, turning 1 or 2 messages into 3 or 4, depending on what was misconfigured. These cannot be customized: microsoft/vscode-languageserver-node#1011 This commit solves this by removing use of the ExtensionErrorHandler class and instead using inline methods for both initializationFailedHandler and errorHandler to detect failed extension errors. It avoids the duplicate methods by not using the ErrorAction message property and instead keeping track of whether or not an InitializeError was detected.
dbaeumer
added
feature-request
|
An |
Recently we upgraded our language client to support LSP 3.17, and noticed certain error conditions in language client start up result in multiple popups even though we set
RevealOutputChannelOn.Never.My guess is this is a change from #824
Our extension has custom
initializationFailedHandleranderrorHandlerthat retry or show a customized error notification already, so it would be nice if we can suppress them.The text was updated successfully, but these errors were encountered: