Help with live errors when using language server

[GrimTheReaper]

Building up on #2707
I would reopen it and add more there, but it is locked.

I ended up disabling the language server and I never ran into the issue again, although as of late gocode is taking up more resources than it should so I either can turn it off and not have a functional IDE, or try the language server.

This time around, I noticed that yeah, it's the language server (gopls) making the live errors come back, and I noticed that I cannot turn them off with the go.liveErrors config. The next solution would be to turn go.LanguageServerExperimentalFeatures.diagnostics to false, but that disables all error checking.

I noticed that I can pass flags with go.languageServerFlags, but gopls doesn't seem to have any for live errors?

The heck am I supposed to do to turn them off with the language server, without disabling my error checking on save?

[stamblerre]

The language server is fairly separate from the rest of the Go extension, which is why it does not respect the extension's configurations (the go.liveErrors config).

Right now, the language server only sends live errors, so if you disable diagnostics you will not get any error checking. I can see an argument for only enabling diagnostics on save, though I think that configuration need not live in the language server. The vscode-go extension could probably hide diagnostics if they don't match saved versions of the file. If I get some time, I will look into adding this behavior, but in the meantime, the only options with the language server are live errors or no errors.

[GrimTheReaper]

Yeah, I'm well aware and it's rather annoying especially since there is no delay to the errors. If I could delay it 500 ms, it would be nice because right now its every single character.

Also, it's not "liveerrors", since technically everything, every character added or removed (except those in strings) is an error.

[ramya-rao-a]

@GrimTheReaper Until a desired compromise is reached you can disable the diagnostics from the language server and rely on the diagnostics coming directly from the extension.

You already know how to disable diagnostics from language server.
To ensure you are getting diagnostics from the extension , ensure you have one or more of the below settings set to package

• go.buildOnSave
• go.vetOnSave
• go.lintOnSave

[GrimTheReaper]

Okay. I'll do that. Feel free to leave this open until a compromise/decision is reached.

[ramya-rao-a]

@stamblerre Do you want to log an issue for gopls around the above?

[stamblerre]

I can see an argument for only enabling diagnostics on save, though I think that configuration need not live in the language server. The vscode-go extension could probably hide diagnostics if they don't match saved versions of the file.

I think I would prefer to follow my suggestion above (#2907 (comment)). I think this is doable on the client side, so the configuration does not need to be handled in gopls.

[wvh]

Isn't there quite some overhead sending errors on every keystroke when one is just entering code?

[stamblerre]

gopls will be doing the parsing and type-checking work no matter what, so the only overhead will be actually sending the publish diagnostics notification. I'm not sure that that is significant enough to justify adding a setting in gopls.

[GrimTheReaper]

Is there anyway to ignore the error returned or delay when the notification comes up on the VSCode-Go's side?

[stamblerre]

I put together a PR based on #2907 (comment) (#2971). Let me know if this works for you.

[stamblerre]

I just filed an upstream issue for this, so I'm going to close this issue in favor of golang/vscode-go#50.