Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Allow language extensions to have consistent symbol matching for document and workspace #34605
There’s an inconsistency in how language extensions are able to match symbols for a single document versus a workspace.
I’ll explain with an example. Assume for the sake of simplicity that all files in a workspace are the same language, and there is only one extension registered for that language.
When a user chooses “Go to Symbol in File”:
When a user chooses “Go to Symbol in Workspace”:
So the main difference is that for a document VS Code is doing the string matching, but for a workspace the extension is doing the string matching. This produces inconsistencies because they are not using the same matching algorithm. The problem is the same regardless of whether the language extension is doing the symbol matching within the extension process or as part of a client/server model.
This difference in behaviour has led to multiple issues in the past (e.g. #20039 – "Go to symbol" looks like only take care of upper cases). Within my vscode-zoneinfo extension, I’m using a knowingly-naïve string matching method for the
I don’t have a definitive solution, but I do have some suggestions.
Option 1: Change
Yeah, the reasons for that is that workspace symbols can be in ten-thousands and sending them all back and forth might be to expensive for a language service. That why we provide the query string, ideally we full access to all models.
For document symbols we expect less symbols and we also have a display of all symbols (in their order, in future in a hierarchy). Then we take on filtering and highlighting.
I think these constraints remain and that we should spec how we expect language servers to interpret/match that query. Many do a "starts-with" or "indexOf" match but would favour a more lax subsequent string matching. So,
Yep, the constraints make sense, especially regarding a workspace (which is why I suggested making
That’s the approach I ended up taking with my extension in lieu of proper fuzzy searching, but a lot of the results don’t get the matched parts highlighted in the picker:
That’s not to say that the matching and/or highlighting is wrong, just inconsistent due to the different processes involved.