Add support for querying workspace symbols and filtering by kind

[lanza]

It would be nice to be able to filter WorkspaceSymbols by kind instead of just by query string. Most LSPs implement the query as some sort of search over the symbol name. If you are specifically looking for an class type, for example, WorkspaceSymbols provides mostly noise.

interface WorkspaceSymbolParams extends WorkDoneProgressParams, PartialResultParams {
    /**
     * A query string to filter symbols by. Clients may send an empty
     * string here to request all symbols.
     */
    query: string;
        kind: string;
}

[dbaeumer]

I like this. @jrieken have you heard about such a request in the light of the VS Code API?

[jrieken]

No, nothing like this has been requested in VSCode and for us it would be more of a UX challenge of how to entering such a filter

[lanza]

Thinking about this some more, I think a general key, value list of options would be reasonable to pass in general.

interface WorkspaceSymbolParams extends WorkDoneProgressParams, PartialResultParams {
    /**
     * A query string to filter symbols by. Clients may send an empty
     * string here to request all symbols.
     */
    query: string;
        options: json; (sorry I don't know TypeScript)
}

kind, maxCount, folders, rootSymbol are examples that could potentially be desired.

• kind to search for a specific symbol kind (coc.nvim has this)
• maxCount to put a maximum on the number of symbols returned. (ccls uses this)
• folders to define a list of folders to restrict symbol search from (ccls uses this)
• rootSymbol no implementors AFAIK but this could be useful for searching for symbols "owned" by some other symbol via inheritance, member variables, member functions, subtypes, etc.

I'm sure there are more ideas. But a general purpose symbol querying mechanism seems useful for the LSP.

[matklad]

Yes please, this is one of the things I miss most coming from IntelliJ. I've hacked this on for rust-analyzer using # and * magic symbols in the query string to select the type, but that understandably got broken with the latest release of VS Code, which now allows several filters itself.

IntelliJ uses the following filters, which seems reasonable:

• Types / all symbols (most of the times you are looking for a Type, and there are fewer types than symbols)
• Your code / dependencies (most of the time you look for symbol in your code, but peeking into, eg, stdlib is occasionally useful)
• Production code / test code (again, usually you don't want tests, but sometimes you do)

UI-wise, I'd expect a set of checkboxes with alt-mnemonics below the widget for common filters, plus maybe some free-way advanced query syntax, for cases like "I want to find all public functions with name starting with set_ in descendatns of ActiveRecord class".

[jrieken]

fyi @bpasero - we recently talked about this

[heartacker]

Yes please, this is one of the things I miss most coming from IntelliJ. I've hacked this on for rust-analyzer using # and * magic symbols in the query string to select the type, but that understandably got broken with the latest release of VS Code, which now allows several filters itself.

IntelliJ uses the following filters, which seems reasonable:

• Types / all symbols (most of the times you are looking for a Type, and there are fewer types than symbols)
• Your code / dependencies (most of the time you look for symbol in your code, but peeking into, eg, stdlib is occasionally useful)
• Production code / test code (again, usually you don't want tests, but sometimes you do)

UI-wise, I'd expect a set of checkboxes with alt-mnemonics below the widget for common filters, plus maybe some free-way advanced query syntax, for cases like "I want to find all public functions with name starting with set_ in descendatns of ActiveRecord class".

are your talking about something like VS. that's great if adopted by vscode

[KamasamaK]

@lanza This seemed like a good request. Why close this?

[matu3ba]

@KamasamaK

Searching+Filtering for all symbols can take a significant and unexpected amount of time, if the language is not strongly typed. Timeouts for queries would fill the gap, but would be possibly very hard to generalize over implementations, so likely lsp doesnt want to deal with churn of lsp timeouts due to type resolving or generics stuff.

[matklad]

Not really: filtering is typically based on syntactic type (is this syntactically a function, a class, etc). Language typing rules or lack thereof are orthogonal to the discussed feature.