src/goLanguageServer.ts: remove fallbacks for features that cannot be opted-out of#3156
src/goLanguageServer.ts: remove fallbacks for features that cannot be opted-out of#3156ramya-rao-a merged 2 commits intomicrosoft:masterfrom stamblerre:clean-up
Conversation
Change-Id: I9f1eb872855ab6adf898efeb75d0b0138ab55709
Change-Id: I4ef333002ec2a1f9c09ef38243bf49b42979b40a
| // gopls is the only language server that provides live diagnostics on type, | ||
| // so use gotype if it's not enabled. | ||
| if (!(toolName === 'gopls' && config.features['diagnostics'])) { | ||
| vscode.workspace.onDidChangeTextDocument(parseLiveFile, null, ctx.subscriptions); |
There was a problem hiding this comment.
Wont we need this if user has opted out of diagnostics?
There was a problem hiding this comment.
I would prefer to avoid these types of fallbacks, as it can make debugging gopls issues difficult. I don't see a reason that someone would opt-out of gopls diagnostics on-type, but still want diagnostics on type from a different tool.
There was a problem hiding this comment.
I don't see a reason that someone would opt-out of gopls diagnostics on-type, but still want diagnostics on type from a different tool.
Previously, it has been mainly due to the issues with the diagnostics feature from gopls. If we are saying that all of those issues are resolved, then my next question would be as to what are the cases where one doesnt want diagnostics on type
There was a problem hiding this comment.
I think there is some set of people that prefer to have their diagnostics only show up on save, not on-type. I think at this point, if someone is having issues with gopls diagnostics, we should work with them to resolve the issue, or they can disable gopls, but we can't let people replace the diagnostics - it's too confusing for debugging purposes.
2 participants
We should only have fallbacks for the features that we support opting out of.
Also, remove a few unused imports.
/cc @hyangah