-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new LSP extension for workspace symbol lookup #7698
Conversation
The current PR makes the UX of using RA with VSCode a bit nicer (IMHO), but I realize it removes the filtering functionality from other editors. If that's unacceptable, perhaps we could expose these filtering knobs as settings to be controlled in VSCode? Or detect VSCode as the LSP client and set them accordingly? |
Yeah, it's sad that this got broken in vs code. That being said, I think searching in the current workspace by default works better, and I definitely think that we should keep the heuristic of "search for types by default, if there are no results, search for all symbols instead". Let's make this user configurable. In config.rs, I think we should add: search.dependencies: bool = false,
search.allSymbols: bool = false, |
Would it be possible to override these settings on per-request basis? i.e. starting ra with default to not search dependencies, but changing it for 1 request, when you might want to see them. I think this is the perfect usecase for an elisp function that takes an optional prefix argument similar to this function in lsp-clangd. That way, we can call |
@petr-tik emacs can directly add That being said, given that basically, we need to add two fields to lsp request params: |
d4bf67c
to
2c35605
Compare
Pushed code to implement a new LSP extension extending the usual workspace symbol lookup request. Aside from bikeshedding names (suggestions welcomes), I'd like some feedback for a few open points:
Of course let me know if i did something incorrectly. |
Since the markers work fine in Emacs, I would vote for keeping them. |
Should we file an issue or proposal on https://github.com/microsoft/language-server-protocol? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ouch, sorry @alcroito, this fell of my radar. Feel free to tag @matklad if the PR is not reviewed.
The PR looks good to me as is (so, you picked the right answers for your questions!), we'd only want to expand the extension docs to actually specify the accepted format.
Is there an easy way to check the per-request case?
I don't think so, it's probably best to wait until Emacs some editor implements support for this.
2c35605
to
abf4115
Compare
Updated PR. Should I add some caveat / note to https://rust-analyzer.github.io/manual.html#workspace-symbol that the |
Updating manual would be helpful, yeah (it’s in this repo)
…On Tuesday, 18 May 2021, alcroito ***@***.***> wrote:
Updated PR.
Should I add some caveat / note to https://rust-analyzer.github.
io/manual.html#workspace-symbol that that the # and '*' markers don't
work with VSCode?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7698 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANB3M3YL3X2YXYHWBL3HVLTOGG67ANCNFSM4XW5SNKQ>
.
|
The new extension allows filtering of workspace symbool lookup results by search scope or search kind. Filtering can be configured in 3 different ways: - The '#' or '*' markers can be added inline with the symbol lookup query. The '#' marker means symbols should be looked up in the current workspace and any dependencies. If not specified, only current workspace is considered. The '*' marker means all kinds of symbols should be looked up (types, functions, etc). If not specified, only type symbols are returned. - Each LSP request can take an optional search_scope or search_kind argument query parameter. - Finally there are 2 global config options that can be set for all requests served by the active RA instance. Add support for setting the global config options to the VSCode extension. The extension does not use the per-request way, but it's useful for other IDEs. The latest version of VSCode filters out the inline markers, so currently the only reasonable way to use the new functionality is via the global config.
abf4115
to
1f7d2a6
Compare
Updated manual to mention VSCode users shouldn't use the filtering symbols, but should rely on the config settings instead. |
bors r+ Thanks! |
Timed out. |
bors retry |
Timed out. |
bors retry |
As well as all symbol types (functions, modules).
Remove outdated documentation regarding symbol lookup filtering.
Closes #4881