FTR, gopls also restricts to the top 100 results, which per this reading of the spec is also not conformant.

Note that there are a lot of symbols in a workspace. For Kubernetes, gopls has around 30mb of symbols in a minimal representation; when expanded with qualified paths and the full symbol struct, it could easily be 100mb+ of data. Furthermore, restricting to the top 100 results allows some not insignificant optimizations for all queries: gopls can avoid allocating results if the score is too low to make the top results list.

I just landed a sequence of optimizations (not yet released), that reduces query latency in Kubernetes from 2-3s down to around 50-100ms, and from my experimentation having very low latency significantly improves the user experience. I'd hate to sacrifice that in the name of conformance.

Why do you want too see all symbols?

@findleyr

Why do you want too see all symbols?

I was just experimenting with a frontend interface for LSP and gopls was one of the few servers that supported the workspace/symbol request which lead me to find this. Given the massive search space of available symbols I guess it makes sense to not return anything with an empty query.

I just raised the issue because it didn't seem like there was one yet. If you feel the lack of compliance here is OK please feel free to close it. Thank you.

Thanks.

You're right that gopls is not conformant to the spec, unless we use a very generous reading that the client 'may request' but the server may choose how to satisfy that request.

But IMO the outcome of conforming to the spec here would be at best a footgun, and at worst a degraded experience for most users. This has come up before, but I'm not aware of any concrete reason to ask for all symbols.

The one reason I've heard is that in some UIs it's strange to open workspace symbols and get empty results. Maybe we should consider returning the top 100 symbols for an empty query.

Anyway, closing for now. If anyone wants to revisit this we can reopen.