Request ID validation

[julien]

When using zls, an error is thrown here. The reason is because zls is not sending a string that contains digits as can be seen here as an example.

The specification says that the request's ID can be a number or a string, but, as fat as I can see it doesn't say that this ID must contain digits (but it would make sense).

I came up with this "workaround":

diff --git a/autoload/lsp/lspserver.vim b/autoload/lsp/lspserver.vim
index 7304b00..1d4b0ed 100644
--- a/autoload/lsp/lspserver.vim
+++ b/autoload/lsp/lspserver.vim
@@ -326,11 +326,9 @@ enddef

 # send a response message to the server
 def SendResponse(lspserver: dict<any>, request: dict<any>, result: any, error: dict<any>)
-  if (request.id->type() == v:t_string
-       && (request.id->trim() =~ '[^[:digit:]]\+'
-           || request.id->trim()->empty()))
+  if (request.id->type() == v:t_string && request.id->trim()->empty())
     || (request.id->type() != v:t_string && request.id->type() != v:t_number)
-    util.ErrMsg('request.id of response to LSP server is not a correct number')
+    util.ErrMsg('request.id of response to LSP server must be a number or a string')
     return
   endif
   var resp: dict<any> = lspserver.createResponse(

What are your thoughts?

[yegappan]

Does this change work for you? The Vim channel feature supports using only integers as request identifiers and doesn't currently support a string as an identifier. But this only applies to the ch_sendexpr() and ch_evalexpr() functions. It may not apply in this case though. If this works for you, can you create a PR with this change?

[julien]

Does this change work for you?

Yes it does. I've tested with zls, rust-analyzer and gopls and didn't experience any issue.

The Vim channel feature supports using only integers as request identifiers and doesn't currently support a string as an identifier. But this only applies to the ch_sendexpr() and ch_evalexpr() functions.

Thanks for explaining, now I understand why we are checking for digits in the request's ID.

I've submitted the patch in #572.