-
Notifications
You must be signed in to change notification settings - Fork 40
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
CallHierarchy support #48
Comments
Thanks a lot! Do you mean this request (https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_prepareCallHierarchy)? |
Yes |
the other nice thing about structuring it around outgoingCalls instead of request_references is you can easily rebuild just a single node when a method gets edited |
Further, one feature of multilspy that I personally like is that it is very easy to access the underlying language server connection handler. This means, it is very easy to use a lsp feature that hasn't been implemented as a first class feature in multilspy. Please refer to detailed steps I shared about it in another related thread (#12 (comment)). This isn't to discourage new feature requests, but so that multilspy users can get started with using the features they want, till a detailed implementation of it can be integrated first-class into multilspy. Please let me know if you have any questions! |
Good timing with #47 -- it will be easy to add outgoing calls on top of that. |
Hi there and thanks for creating multilspy!
I'm using it to create a language-agnostic-ish call graph to solve LLM code assistant context. [Article.]
Currently this is two passes:
(1) is about 0.1s per file which is not great but I can live with it. But (2) is about 2.5s per source file.
Multithreading helps a little but not much (about a factor of 2x), because Python.
I think I could do (2) in request-per-file instead of request-per-symbol if I had CallHierarchy with outgoingCalls support.
WDYT?
The text was updated successfully, but these errors were encountered: