Symbol search for symbol in dependency

[obsgolem]

I frequently find myself wanting to explore the source of a dependency in order to understand how to use it. Go to definition works great for this if I have code that references the thing I want to explore, but sometimes I don't. For this usecase, I want to use go to symbol instead. A viable alternative is to search for the name of the symbol using autocomplete, then use go to definition from there, but this is an extra step.

[flodiebold]

The workspace symbol search supports this, see the manual. In non-VSCode editors, you can just type Foo* to search for Foo in dependencies; sadly VSCode removes the star, so this doesn't work, so currently you have to change the configuration to search in dependencies.

[Veykril]

(Sorry for hijacking but) regarding VSCode I wonder if we can just overwrite the whole symbol search infra, given we can inject middlewares, to get around VSCode stripping symbols for no reason 🤔 That is we sent the corresponding request ourselves instead.

[flodiebold]

Did we ever report/ask the VSCode team about the symbol stripping, by the way?

[Veykril]

I don't think so, also my for no reason was ill-mannered. I do recall them having a reason for this (that is reserving some symbols in there iirc, I saw a comment regarding that at some point).

[aloucks]

The workspace symbol search supports this, see the manual. In non-VSCode editors, you can just type Foo* to search for Foo in dependencies; sadly VSCode removes the star, so this doesn't work, so currently you have to change the configuration to search in dependencies.

I wish I would have seen this years ago! Finding symbols in dependencies, with VSCode, has been sorely missed. Changing rust-analyzer.workspace.symbol.search.scope to workspace_and_dependencies has been a game changer.

One challenge that I've found is that the fuzzy search makes it hard to find items with common names, especially in the standard library. For example, searching for #String gives me a ton of results, none of which are the std String. I suspect it would be in the list, but the number of results is truncated. Is there any way have a "startswith" and "endswith" type of search? E.g. #^String and #String$? I'm assuming the answer is No based on the comments above regarding special characters being stripped out, but I wasn't sure what all characters are stripped or if there was an alternate way to communicate startswith/endswith.

[Veykril]

No, VSCode doesn't let us customize the search at all. There is logic for this kind of stuff in the server but VSCode strips any non alphabetic characters from the query before it hands it to the server. So we can make this work for other editors, but not VSCode.

[ChayimFriedman2]

@Veykril Apparently no! VSCode only strips * and # (the conditions aren't entirely clear to me though, but it seems to not strip at least : in the middle of the query, which is important for me because I want to make it better with this).

[Veykril]

Huh I could swear I checked : specifically back when I was investigating this (as the application for that is obvious ;)

[Veykril]

Ah I was misremembering the exact behavior, we do get the full query, but VSCode does some weird filtering on the results wrt to the query string microsoft/vscode#171320

[ChayimFriedman2]

So after implementing searching for foo::bar I discovered VSCode does filter the results for some unknown reason. This is so annoying that I think I'm going to contribute to VSCode.

[ChayimFriedman2]

Update: I implemented a fix in VSCode, but it has some bad scoring - e.g. when I search for string::string*, first it shows StringTooLongError from pulldown-cmark, and the obvious std::string::String only comes 7th. A proper fix for that will require changes to the LSP, so this is what I'm going to focus on now.

[Veykril]

There is value in landing this either way, at least for other editors that don't do weird scoring like vscode

[ChayimFriedman2]

I have it implemented (without tests though, I tested it manually), but I don't like the idea of shipping something that the majority of our users (including me) cannot use. I prefer to wait to see what happens with my LSP suggestion (why BTW is here).