You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today the method symbol on workspace search is only done for workspace sources. But with adding a prefix into the search token we could try to target both source and binary symbols as well.
For example searching foo will provide foo methods from the workspace sources. But if you search like +foo you would search both on source and binary. Since vscode fuzzy search use the symbol name, we need to append + for all symbol names from jdt.ls. The same strategy is used by Spring Tools for different kind of workspace symbol searches.
A more better way is to have this as part of LSP, But i'm not sure if this fits there since LSP tries to make the protocol more generic to fit larger group of languages.
WDYT about the idea ?
The text was updated successfully, but these errors were encountered:
Adding some kind of prefix might be a good way to reduce the number of results in some cases. With that said, the first step would be to just search the binary+source symbols together. When I introduced searching source methods, it was my goal to do it but the performance is not great. The symbol search in VS Code basically waits until all symbols are returned, but the LSP itself has the ability to return results incrementally.
Today the method symbol on workspace search is only done for workspace sources. But with adding a prefix into the search token we could try to target both source and binary symbols as well.
For example searching
foo
will provide foo methods from the workspace sources. But if you search like+foo
you would search both on source and binary. Since vscode fuzzy search use the symbol name, we need to append+
for all symbol names from jdt.ls. The same strategy is used by Spring Tools for different kind of workspace symbol searches.A more better way is to have this as part of LSP, But i'm not sure if this fits there since LSP tries to make the protocol more generic to fit larger group of languages.
WDYT about the idea ?
The text was updated successfully, but these errors were encountered: