Expose setting to enable LSP communication trace

[rchl]

Most LSP extensions expose a setting to configure the verbosity of the LSP output in the extension output panel. This extension doesn't seem to support that. There is clangd.trace option but that is not what I'm looking for (it's a lower level communication).

Most third party of built-in extensions expose a setting like "ruff.trace.server": "verbose", "json.trace.server": "verbose",` etc.

[HighCommander4]

As discussed at https://clangd.llvm.org/troubleshooting.html#gathering-logs, this can be done by adding --log=verbose to "clangd.arguments".

[rchl]

Thanks, it works.

That said, the vscode language client libraries support a setting like clangd.trace.server out of the box. The only thing that makes it problematic in this case is that clang already exposes a clangd.trace setting for different purpose which causes a conflict.

So I suppose you wouldn't want to rename the existing setting to make the standard one work? If not then feel free to close this issue.

[HighCommander4]

the vscode language client libraries support a setting like clangd.trace.server out of the box.

Do you know how this works at the protocol level?

[rchl]

I'm not sure I understand the question but since the whole protocol communication goes through the language client, it's able to post this data to the output panel.

The log would look something like this (it's from a different server):

[Trace - 22:06:19] Sending request 'textDocument/codeAction - (31)'.
Params: {
    "textDocument": {
        "uri": "file:///usr/local/workspace/lsp/lsp-log-parser/components/app-bar.vue"
    },
    "range": {
        "start": {
            "line": 145,
            "character": 35
        },
        "end": {
            "line": 145,
            "character": 35
        }
    },
    "context": {
        "diagnostics": [],
        "triggerKind": 2
    }
}


[Trace - 22:06:19] Received response 'textDocument/codeAction - (31)' in 4ms.
Result: []

It's arguably more readable that one-liners from clangd.

Here is the change that would be needed - rchl@9464e4e
The language server ID is assigned explicitly since otherwise it's inferred from name which doesn't play nice with settings.
Of course this change tramples the original clangd.trace setting so if supporting this new option is desired then there would need to be some breaking change done to solve this issue.

EDIT: Also... enabling clangd.trace.server results in language client sending a $/setTrace notification to the server:

[Trace - 21:48:56] Sending notification '$/setTrace'.
Params: {
    "value": "verbose"
}

so the server can toggle some logic based on that (like the logging associated with the current clangd.trace setting, for example).

[HighCommander4]

Ok, I see, this logging is implemented entirely in the client.

It's arguably more readable that one-liners from clangd.

Note that clangd will also pretty-print the protocol traffic if --pretty is added to "clangd.arguments".

Also, the server logs include additional information beyond the protocol traffic, so this client-side logging couldn't replace them altogether. (But we could still provide the client-side logging as well, for discoverability purposes.)

Here is the change that would be needed - rchl@9464e4e

Thanks, this is helpful.

Of course this change tramples the original clangd.trace setting so if supporting this new option is desired then there would need to be some breaking change done to solve this issue.

@hokein, any thoughts on whether it's OK to rename the existing clangd.trace setting? Technically it would be a breaking change for users who use the existing setting, but the breakage would be easy to resolve by switching to the new name.