Consider not activating the extension until a go file is open or a user explicitly requests (command/setting)

[hyangah]

Currently this extension is enabled automatically if there is a go file in the workspace.
In mono-repo cases, or where users use go as supporting languages (e.g. scripts, etc), this is too invasive.
Variety of notifications, survey prompts, and errors (often, gopls wouldn't be configured sufficiently for a large mono-repo) will be annoying. Activation of test explorer UIs, and repo scanning will cause the whole vscode sluggish or unpleasant.

The only concern is the delay when a Go user opens a Go file. How bad could it be?

cc @golang/tools-team

[lijunsong]

I found this problem annoying for big repos.

I found a commit 50b13f1 where the fix made the problem introduced only when the top 2 most subdirectories contain go files.

That was a solution but a weird one:

1. for a small repo, the gopls loads super fast so it's OK to activate the extension only when a go file is opened.
2. for a huge repo, where the repo usually contains many other languages and projects, It should activate the extension only when a go file is opened.

So for majority of the scenarios, the activationEvents shouldn't contain the workspaceContains instrument.

What do you think?

[findleyr]

I think we should do this. My understanding is that the current behavior is an outlier among VS Code extensions and LSP clients.

One advantage of starting the extension earlier is that it is available to use workspace/symbol requests to jump to the first Go file. But in my experience with other editors (neovim), this is not a big deal: I am used to jumping to an arbitrary Go file to initiate the session, then jumping to symbols.

[gopherbot]

Change https://go.dev/cl/545136 mentions this issue: package.json: remove 'workspaceContains' from activation events