Open DavyLandman opened 1 month ago
Thanks for the PR. Should we use the result from data2String
which is captured here: https://github.com/microsoft/vscode-languageserver-node/blob/main/client/src/common/client.ts#L1004
That covers more cases than simply an Error with an message.
Thanks for the PR. Should we use the result from
data2String
which is captured here: https://github.com/microsoft/vscode-languageserver-node/blob/main/client/src/common/client.ts#L1004That covers more cases than simply an Error with an message.
I was thinking about that as well, but that might show a bit more than needed (as it also prints the jsonRPC/lsp error code)?
But if you prefer, I rewrite it to that.
Having reviewed the function again, yes I agree, it's better to reuse that function. The PR has been updated.
hi @dbaeumer is there something I can do to help get this merged? It would be a pitty if it misses an upcoming release window, as this helps us better report to users when something crashed, what is the issue, without having them dig through the output window.
I've noticed that if a LSP server reports an error via
ResponseError::message
field, it's a bit of a hit or miss if this is reported to the end user in a popup.For example rename reports the error in the dialog while errors in many others parts end up in the generic handler
I've changed this such that both the message from the library is kept, while also reporting the message from the LSP server.