Related #38819 (comment)

Change https://golang.org/cl/263524 mentions this issue: internal/lsp: remove per-workspace configuration

This has been discussed at length on Slack (starting at https://gophers.slack.com/archives/CRWSN9NCD/p1603374985082900), but let's move the discussion to this issue to make it a little more permanent.

@myitcv said:

The last time I checked there wasn't a way for me to say "this file I'm opening should be considered to be open within workspace folder B, which is where I have set GOOS=js GOARCH=wasm"
Where workspace folders A and B intersect (in terms of directory trees), this is relevant because it's otherwise ambiguous when doing something with a file in that intersection
So whilst the configuration request from server to client is unambiguous, and call from client to server can be ambiguous

I agree that this is an ambiguity of the LSP, but I'm not sure how this is resolved by the gopls-<name> configuration. If you've opened both A and B (say A is foo/bar and B is foo/bar/baz) then gopls would request workspace/configuration for both foo/bar and foo/bar/baz. There is definitely an issue of intent if foo/bar depends on foo/bar/baz with different build tags, and the user jumps to the definition of something in foo/bar/baz--but I don't think the gopls-<name> configuration would address that in any way.

I agree that this is an ambiguity of the LSP, but I'm not sure how this is resolved by the gopls-<name> configuration

I don't think @ianthehat (or indeed anyone) claimed it was resolved by this approach, rather that this configuration mechanism (plus the "closest match" logic) was the best approximation given the options available to us via LSP.

Ok, then I guess it's still not clear to me that this configuration setting is offering anything more than existing per workspace folder configuration requests.

I guess it saves the user the hassle of manually changing the configuration when they switch between build tags, but that feels like something that could be pushed into the level of the client.

I guess it saves the user the hassle of manually changing the configuration when they switch between build tags, but that feels like something that could be pushed into the level of the client.

From memory, the idea behind this setup was that it allowed the user to concurrently edit files within a subtree of a module using a different build configuration (GOOS, GOARCH and build tags). The canonical example being the WASM subtree.

Doesn't pushing this to the client mean the user would have to flip backwards and forwards as they flip to/from the subtree, thereby negating the "concurrently" bit?

It's possible I'm not fully understanding the motivation behind making this change.

By concurrently, do you mean in different sessions or in the same session?
If it's the same session, then it sounds like that's already not possible given the ambiguity of having overlapping workspace folders in the same session.

By concurrently, do you mean in different sessions or in the same session?

Same session.

If it's the same session, then it sounds like that's already not possible given the ambiguity of having overlapping workspace folders in the same session.

But that's where I believe @ianthehat established logic to choose the view that best corresponded to the file in question. Because a view on a subdirectory tree of a module is more specific, and hence if a file is contained within that tree then that view is used.

True. But still, it's possible to configure overlapping directories differently without a gopls-<name> setting.

I would be very surprised if it were possible to work on the same workspace folder with different configurations in one session, and I think that's the case that this gopls-<name> configuration was meant to support.

@myitcv: Based on this discussion, I'm still inclined to remove the configuration, as I'm still not clear on what concrete use case it supports. If you are opposed to the configuration being removed, can you please provide an example of a project in which it would be useful with an explanation of how to use it? Thanks!

I'll defer to @ianthehat and @bhcleek on that question, because theirs was the original use case behind this (as was the original support in vim-go). As I mentioned elsewhere, we do not (yet) support multiple workspaces folders in govim. However, we would be interested in doing so if we can work out the right UI/UX.

As far as I am concerned the entire thing was a GopherCon hack so we could explore and experiment, if the conclusion is that this is the wrong path to take then it should go away (even if it has been a very very long time since we started the experiment). I have certainly never used it, but then I was not the target user either.

TL;DR: one workspace configuration per workspace is fine for vim-go.

Vim-go does not need two workspaces configurations per workspace, but it does need to be able to configure multiple workspaces.

IIRC correctly, gopls would create a workspaceConfiguration on initialization named gopls and then each workspace was given a name that was prefixed with gopls- when this feature was first created. My understanding at the time was that the workspace created on initialization was getting two workspaceConfigurations, and vim-go handles that fine, but it configures them both the same. I don't recall that subsequent workspaces were getting two configurations each. 🤷

Thanks for following up. I think it makes sense to remove the gopls-<name> configuration then, since it's not actually being used by any clients.

Change https://golang.org/cl/269597 mentions this issue: internal/lsp: remove gopls-<name> configuration