[Feature] ServerInfo request

[kirillbobyrev]

For monitoring and troubleshooting the Language Server, it is extremely useful to have server information printer in the editor. Most Vim clients either don't provide any way of printing out LSP server address, log file, etc or use their own format (e.g. here's my request for a Vim client). It might be useful for both users and LSP developers to provide a unified request (workspace/serverInfo?) and server information format. There are few things we could ask from every server:

• Server PID (so that I could attach my debugger to the process)
• Log files: both stdout and sterr files
• URL
• Memory consumption
• Additional (optional) server information string which can be specific to each server (e.g. which one is used, what the version is, etc)

Having this information would provide better user experience for bug submissions and better developer experience. Alternatively, we could allow servers to return a string in free format letting each server decide what they would like to expose to the client.

This is an example of server information printer in Vim's YouCompleteMe:

[mickaelistria]

I don't think a debug request makes sense in the lifecycle of the Language Server usage, and I disagree this would have value for end-users. Moreover, debugging can happen even before LS manages to start the connection (cannot connect to client or server, erroneous startup...), so in those cases (which are IMO the most frequent reasons to debug a LS), the operation wouldn't even be accessible. What about just dumping debug output to a log file as usual?

[kirillbobyrev]

Thanks for the feedback!

Moreover, debugging can happen even before LS manages to start the connection (cannot connect to client or server, erroneous startup...), so in those cases (which are IMO the most frequent reasons to debug a LS), the operation wouldn't even be accessible.

Sorry, the wording might not have been great: we probably mean different things by "debugging" then. My use-case actually splits into monitoring the LS behavior (e.g. how much memory it consumes) and reproducing the problems (e.g. attaching to the LS process, inspecting the internal state, etc). I think users would benefit from both and I don't think that dumping debug output to the log file is sufficient for that purpose.

I'll rephrase in the original request.

[LaurentTreguier]

The root of the project shouldn't be necessary in the request, as roots are decided by the client.
Requesting the URL or the where the output of stdout goes would depend on how the server is launched; if a server uses standard process IO for communication with the client then there will be no URL to show and stdout will be used to send messages to the client.

Other than this, having a request for server info could be useful indeed.
Maybe something like the version of the server could also prove useful for reproducing problems more easily ?

[kirillbobyrev]

@LaurentTreguier yes, I agree. Also, for some languages (e.g. C++) it's really hard to guess where the root is (and what it actually is). I'll update the initial comment.

Yes, server version could go into the additional field which can specific for each server.

[dbaeumer]

Just to be sure I interpret this correctly. This would be a notification send from the client to the server to turn on some tracing / logging. The server would then use the notification available to write to the console of the client.

[kirillbobyrev]

My initial proposal was the server info pretty-printing request: client sends request to show information about the server which is currently used to see where it stores logs, traces which version it has and other additional server information. Turning on logging/tracing can be done via passing flags to the server, that's probably something different.

[robertoaloi]

Related to this: version 3.15 of the protocol introduces ServerInfo as part of the InitializationResult. Maybe we could clarify how clients should use that information. It could also make sense to introduce a request from the client to the server to request "serverinfo". In that case the format should be relaxed a bit (since right now only contains name and version). Maybe also return a property list?