Enhance Rust symbol search

[AlexHYF]

This is more of a rust-analyzer problem but I think we can introduce an adaptation as it is pretty simple to do.

In rust-analyzer, the default workspace symbol has a behavior that some of the results are filtered out by default unless you put a # after it. Here is the reference (The docs is a bit confusing, but the take away is that if you want to find all symbols you have to append a #, because function includes type). And the trait information is filtered out by default which is quite annoying.

While it is okay for me to just add a # when I am performing GoToSymbol like GoToSymbol Foo#, for the interactive interface I will have to turn off g:ycm_refilter_workspace_symbols as I think the default sorting algorithm does not add new items but only filters out old ones (correct me if I am wrong). Even with these workaround, typing a # in the end is just too tedious. Therefore I am wondering if it is acceptable to introduce a flag for rust completer, which add a # to the end of the query when switched on. I can take care of the PR if it is ok.

Something like this (My current approach)

  def GoToSymbol( self, request_data, args):
    if len( args ) >= 1: # We can check the flag here if we want
      args[0] = args[0] + '#'
    return super().GoToSymbol( request_data, args )

Thank you for creating such a wonderful tool.

[puremourning]

The doc says:

Foo searches for Foo type in the current workspace
foo# searches for foo function in the current workspace

FFS why would do they do this?

The best part is that this harebrained scheme doesn't even work in vscode:

Note that filtering does not currently work in VSCode due to the editor never sending the special symbols to the language server

LSP is a joke.

I think you should raise this with the server vendor and say that foo should return all symbols in the workspace the match foo and if they want to subsequently filter that by symbol type, make a proposal to the LSP to add symbol type filtering to the workspace/symbols request. I'm sure there's a use case for that.

[puremourning]

I will have to turn off g:ycm_refilter_workspace_symbols

yeah, because your "query" is "Foo#" and YCM matches that against all the returned results, which of course doesn't match.

[bstaletic]

@puremourning But the docs then proceed to say

That is, # switches from "types" to all symbols, * switches from the current workspace to dependencies.

Is the capital letter in rust similar to go's private vs public?

I agree that this should be a part of the protocol instead, but the requested change is tiny. I wouldn't mind reviewing that pull request.
That said, clashing with the filering could be a problem.

[puremourning]

I tried this out and the r-a workspace symbol is just... strange:

• Default behaviour toggles between structs and functions at will: https://asciinema.org/a/jmQpSBgMP4wlXzQCYEKBqo6Oi
• Demo if the differences of * and # suffixes: https://asciinema.org/a/kO2cpMu9FtoazuKinIbK9COt8
• Applying a similar patch to proposal by OP, the behaviour gets really wierd: https://asciinema.org/a/k3cBRJHjH5D5a4F9xaVreVui0

The default behaviour seems.. OK ? I guess. if it looks like a function and doesn't match a type, it switches to functions?

[AlexHYF]

Yes it indeed toggles at some scenarios, but it is not reliable and the toggle will not trigger if it does't look like function(Yeah, I mean trait). The most annoying part is traits are filtered by default. If I have a trait called Foo, and a struct called FooBar, then if I just type Foo, I will only get FooBar not Foo.

This is indeed a stupid design and really drives me crazy.

[AlexHYF]

The doc says:

Foo searches for Foo type in the current workspace

foo# searches for foo function in the current workspace

FFS why would do they do this?

The best part is that this harebrained scheme doesn't even work in vscode:

Note that filtering does not currently work in VSCode due to the editor never sending the special symbols to the language server

LSP is a joke.

I think you should raise this with the server vendor and say that foo should return all symbols in the workspace the match foo and if they want to subsequently filter that by symbol type, make a proposal to the LSP to add symbol type filtering to the workspace/symbols request. I'm sure there's a use case for that.

I think I will do that. Padding a # might introduce other problems in large projects.

[AlexHYF]

Okay, I found the best way to deal with this. I can pass option to R-A to make the symbol search to return everything. No need for the # hack. Not sure if we want to include a flag to pass this config to R-A.

[bstaletic]

We have a mechanism for changing the default behaviour of completers.
https://github.com/ycm-core/ycmd/blob/master/ycmd/completers/go/go_completer.py#L100-L113

So far that was only ever used to get LSP servers to cooperate.
I do not feel confident judging if we want to chabge this R-A default.

[AlexHYF]

Then I guess the best way might be to have a side note about this in the documentation. In case people like me want to perform global symbol search.