Fix junk output in clangd vscode plugin

[jfindley]

Summary

When using the vscode clangd plugin, lots and lots of junk output is printed to the output window, which constantly reopens itself.
Example output:

I[11:13:17.733] <-- textDocument/codeAction(4)
I[11:13:17.733] --> reply:textDocument/codeAction(4) 0 ms
I[11:13:17.937] <-- textDocument/codeAction(5)
I[11:13:17.937] --> reply:textDocument/codeAction(5) 0 ms
I[11:13:18.557] <-- textDocument/hover(6)
I[11:13:18.606] --> reply:textDocument/hover(6) 48 ms

This should prevent that from happening.

[ioeric]

Thanks for the patch James!

Adding folks who are currently using vscode+clangd to get more opinions.

clangd/clients/clangd-vscode/src/extension.ts

59 ↗

(On Diff #175848)

Does this mean that clangd's output will never reach vscode? Is there a way to see the output with this set? I think there are cases where the output would be useful for users (e.g. to check status).

[jfindley]

clangd/clients/clangd-vscode/src/extension.ts

59 ↗

(On Diff #175848)

It still reaches vscode, it just tells vscode not to automatically open the output window any time you do anything. You can still manually open the output window to see clangd info if you want to.

[hokein]

@jfindley I'd like to understand how do these log messages noise you? Does the window prompt up to you automatically (this only happens when there is an error in clangd)? These messages only get print to the clangd-vscode output panel which is used for debugging purposes (normal users won't open this window by their own).

[ilya-biryukov]

+1 to the change, this is annoying for me too.

In D55052#1312753, @hokein wrote:

@jfindley I'd like to understand how do these log messages noise you? Does the window prompt up to you automatically (this only happens when there is an error in clangd)? These messages only get print to the clangd-vscode output panel which is used for debugging purposes (normal users won't open this window by their own).

It's fine to have this open for debugging purposes, the real problem is that it pops up whenever clangd send an error response. We do this a lot now that we support cancellation and the default policy is to show an output window in that case as well.

[ilya-biryukov]

clangd/clients/clangd-vscode/src/extension.ts

58 ↗

(On Diff #175848)

Could we rephrase this? Something like // Do not switch to output window when clangd return an error.

58 ↗

(On Diff #175848)

*returns an error

[hokein]

In D55052#1312760, @ilya-biryukov wrote:

+1 to the change, this is annoying for me too.

In D55052#1312753, @hokein wrote:

@jfindley I'd like to understand how do these log messages noise you? Does the window prompt up to you automatically (this only happens when there is an error in clangd)? These messages only get print to the clangd-vscode output panel which is used for debugging purposes (normal users won't open this window by their own).

It's fine to have this open for debugging purposes, the real problem is that it pops up whenever clangd send an error response. We do this a lot now that we support cancellation and the default policy is to show an output window in that case as well.

For cancellation errors, it might be reasonable, but what if other unrecoverable errors in clangd (e.g. clangd crashes), in these cases, users don't know what happens, and would still expect IDE features (like code completion) to work...

[ioeric]

In D55052#1312766, @hokein wrote:

In D55052#1312760, @ilya-biryukov wrote:

+1 to the change, this is annoying for me too.

In D55052#1312753, @hokein wrote:

@jfindley I'd like to understand how do these log messages noise you? Does the window prompt up to you automatically (this only happens when there is an error in clangd)? These messages only get print to the clangd-vscode output panel which is used for debugging purposes (normal users won't open this window by their own).

It's fine to have this open for debugging purposes, the real problem is that it pops up whenever clangd send an error response. We do this a lot now that we support cancellation and the default policy is to show an output window in that case as well.

For cancellation errors, it might be reasonable, but what if other unrecoverable errors in clangd (e.g. clangd crashes), in these cases, users don't know what happens, and would still expect IDE features (like code completion) to work...

FWIW, I think users shouldn't be forced to look at clangd output when they don't want to. If some feature doesn't work as expected, users can still look at the log. Clangd crash should be rare, and even when there are errors, they're usually not interesting/useful for users to look at. Errors from clangd should not interrupt users' workflow.

[ilya-biryukov]

In D55052#1312766, @hokein wrote:

For cancellation errors, it might be reasonable, but what if other unrecoverable errors in clangd (e.g. clangd crashes), in these cases, users don't know what happens, and would still expect IDE features (like code completion) to work...

Yeah, there are still modes where clangd behaves badly there. Note that the output from that pane is rarely useful anyway as clangd keeps producing errors about accessing non-open files, which would confuse people even more.
Overall we never designed this output to be readable by the users, so it's not really useful anyway. There are ways to communicate with the users in the protocol, we should be using them instead to be more user-friendly

[jfindley]

Changed the comment to be a little more helpful. I used 'output' rather than errors because depending on verbosity level it can be more than just errors printed.

[ioeric]

James, do you have commit access to llvm? If not, I'm happy to land the patch for you.

[jfindley]

In D55052#1313048, @ioeric wrote:

James, do you have commit access to llvm? If not, I'm happy to land the patch for you.

I do not have commit access - if you could land it that would be great, thanks!

[hokein]

Yeah, there are still modes where clangd behaves badly there. Note that the output from that pane is rarely useful anyway as clangd keeps producing errors about accessing non-open files, which would confuse people even more.
Overall we never designed this output to be readable by the users, so it's not really useful anyway. There are ways to communicate with the users in the protocol, we should be using them instead to be more user-friendly

SG.

@jfindley, thanks for the patch. I made a new release v0.0.8 of vscode-clangd extension, please upgrade to it.

clang-tools-extra/trunk/clangd/clients/clangd-vscode/src/extension.ts

const clientOptions: vscodelc.LanguageClientOptions = {
         // and when navigating to the included file, clangd passes its path inside the symlink tree
         // rather than its filesystem path.
         // FIXME: remove this once clangd knows enough about bazel to resolve the
         // symlinks where needed (or if this causes problems for other workflows).
         uriConverters: {
             code2Protocol: (value: vscode.Uri) => value.toString(),
             protocol2Code: (value: string) =>
                 vscode.Uri.file(realpathSync(vscode.Uri.parse(value).fsPath))
-        }
+        },
+        // Do not switch to output window when clangd returns output
+        revealOutputChannelOn: vscodelc.RevealOutputChannelOn.Never
     };
 
   const clangdClient = new vscodelc.LanguageClient('Clang Language Server', serverOptions, clientOptions);
   console.log('Clang Language Server is now active!');
   context.subscriptions.push(clangdClient.start());
   context.subscriptions.push(vscode.commands.registerCommand(
       'clangd-vscode.switchheadersource', async () => {
         const uri =