Proposal: Allow servers to customize the matching behavior of workspace symbols

[ChayimFriedman2]

A server may want to have a its own grammar for a workspace symbols request. For example, rust-analyzer supports * and # modifiers (meaning search in dependencies and search non-types, respectively), and I want to extend it to support fully-qualified searches, aka. foo::bar::Baz that will search Baz in bar module in foo.

Such search does not currently work in VSCode (but does in other clients), because VSCode self-filters the responses if they don't fully contain the query. That is solvable; I implemented a fix for that in VSCode. The problem is that even with this fix, VSCode (and probably other clients too) score and highlight results based on the query, which leads to non-ideal result, like searching for string::string brings the obvious full-match std::string::String (displayed to VSCode as String) be shown way after StringTooLongError, because the latter also match, in addition to the full String, "tng" from the second string, so it has a higher score. Plus the tng are highlighted, which looks very strange.

I propose we allow servers to redefine the query, that is, send the client the part they should match against. In particular, extend the protocol with the following properties:

interface WorkspaceSymbolClientCapabilities {
    /**
     * Support for a response of type `WorkspaceSymbols`.
     */
    objectResponse: boolean;

    // ...
}

/**
 * The response of a Workspace Symbols Request.
 */
interface WorkspaceSymbols {
    /**
     * The query to match and score against. Usually this is part of or the full `WorkspaceSymbolParams.query`.
     */
    query: string;

    /**
     * The list of symbols.
     */
    symbols: SymbolInformation[] | WorkspaceSymbol[];
}

And define the type of a response to a Workspace Symbols Request to be WorkspaceSymbols | SymbolInformation[] | WorkspaceSymbol[] | null.

[HighCommander4]

Such search does not currently work in VSCode (but does in other clients), because VSCode self-filters the responses if they don't fully contain the query. That is solvable; I implemented a fix for that in VSCode.

Apologies if this is slightly tangential, but could you say more about how you fixed this in VSCode?

[ChayimFriedman2]

@HighCommander4 VSCode currently only allows skipped characters in the matched words, although the basic algorithm (Needleman–Wunsch) allows them in the pattern too. I changed it to allow skipped characters in the pattern as well.

[HighCommander4]

@HighCommander4 VSCode currently only allows skipped characters in the matched words, although the basic algorithm (Needleman–Wunsch) allows them in the pattern too. I changed it to allow skipped characters in the pattern as well.

Did you fix this in upstream vscode (contribute a patch)?

[ChayimFriedman2]

@HighCommander4, no, only locally - because I realized that something wider is needed, i.e. this proposal.