Closed lanza closed 3 years ago
I like this. @jrieken have you heard about such a request in the light of the VS Code API?
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
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.
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:
Type
, and there are fewer types than symbols)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".
fyi @bpasero - we recently talked about this
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
@lanza This seemed like a good request. Why close this?
@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.
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.
It would be nice to be able to filter
WorkspaceSymbols
by kind instead of just by query string. Most LSPs implement thequery
as some sort of search over the symbol name. If you are specifically looking for an class type, for example,WorkspaceSymbols
provides mostly noise.