-
Notifications
You must be signed in to change notification settings - Fork 202
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
Support for call hierarchies #614
Comments
I'd think that redrawing time << server request time. I'm happy to take a look at a prototype implementation based on |
I took a quick look at this. I have results back from Alternatively, we could just store a regular elisp list in a tree-like structure and pass that to Once that part is figured out, the actual displaying of the tree seems straightforward, Here's my current code which just makes the LSP requests (not production code that I would submit in a PR, just wrote it for some quick testing): (defun eglot-prepare-call-hierarchy (server)
(jsonrpc-request (eglot--current-server-or-lose)
:textDocument/prepareCallHierarchy
(eglot--TextDocumentPositionParams)))
(defun eglot-incoming-calls ()
(interactive)
(let* ((server (eglot--current-server-or-lose))
(call-hierarchy-item (seq-elt (eglot-prepare-call-hierarchy server) 0))
(results (mapcar (eglot--lambda (CallHierarchyIncomingCall from)
(eglot--dbind (CallHierarchyItem name) from
(message "%s" name)))
(jsonrpc-request server
:callHierarchy/incomingCalls
`(:item ,call-hierarchy-item)))))
(message "%s" results)))
(eval-and-compile
(defvar eglot--lsp-interface-alist
`(
(CallHierarchyItem (:name :kind :uri :range :selectionRange) (:tags :detail ::data))
(CallHierarchyIncomingCall (:from :fromRanges))
;; ... |
Any advice on how to implement this? This feature is the only reason I still need to use vscode. |
For top-level architecture, the approach I recommend is to propose a new library Then, Then, after that step is more or less done, you start experimenting with having Eglot add an LSP-powered function to the new special hook, buffer locally in the Instead of This is just the top-level architecture. I recommend we start a discussion in Emacs's bug tracker about this. Use |
Thanks @joaotavora! Before I create an Emacs bug for this, I want to make sure I understand one thing: what's the reason for adding this library to Emacs instead of creating it as a third-party library first, and then potentially adding it to Emacs in the future or leaving it as a third-party package? |
If it's easier, you can still follow most of my above advice and make it an optional or "soft" dependency, like The disadvantage is that many users using only Emacs won't get the benefits of using call hierarchies. But maybe it's good to start like this and then move into a |
@gsingh93 Hi, may I ask is there any update to make eglot support call hierarchies? |
I haven't had time to look into this, and honestly my elisp skills are probably not good enough to start this project. On the bright side, @joaotavora described what needs to be done in #614 (comment), so if anyone is interested in working on this that's a good starting point. |
I have just written one and it works for me. |
@dolmens I'd like to add a version of your code to eglot.el proper (and do a number of improvements on top). Do you have an FSF copyright assignment? |
@joaotavora No I haven't, I am currently working on it. |
@dolmens After reading through your code, I realized that it's heavily
So, your extension doesn't work with other server, such as Your code also has other UI problems, but those are due to the inherent limitations of Nevertheless your extension is a very good start and has very good ideas, such as the use of the UTF up and down arrows to represent a directed (possibly cyclic) graph as a tree. I'm rewriting a version of this from scratch, which works with |
@joaotavora Go ahead, I assume you are free to do what you think is appropriate. If a certain feature has a standardized approach, we adopt it, if not, it’s preferable to have an adaptation layer, allowing specific language server tasks to be delegated to plugins or users. If there’s functionality exclusive to a particular language server, then it can only be handled by plugins or users, in such cases, Eglot’s only role is just ‘allowing it’. I guess. |
Yes, that's true. For example, I've just shown in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65418#23 how to implement the clangd-specific But here, there is no such need. This feature has a standardized approach: it is described in the LSP standard, which surely you are familar with (https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/). So a server-specific adaptation layer isn't necessary, all that's necessary is, as usual, for Eglot and the servers to follow the standard. In practice, what happens is that features start out as experimental server-specific behaviour (like the aforementioned Who is "we", by the way? Are you a member of some relevant project or were you talking about "we Emacs devs"? |
@joaotavora We the community, not just the Emacs devs. Cause in standard situations, there is generally no argument. |
OK, I see. By the way I hope you are still interested in getting a FSF copyright assignment for future contribution contributions to Eglot and Emacs itself. Let me know if you need help getting the process started. |
Sure. |
Did this change get merged back to eglot? |
No, it is heavily clangd specific. And clangd needs work anyways. I have a
clangd branch with the fixes, but no time to integrate. Sorry.
…On Sun, Dec 10, 2023, 13:25 Aneesh Kumar K.V ***@***.***> wrote:
Did this change get merged back to eglot?
—
Reply to this email directly, view it on GitHub
<#614 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAC6PQ7DEPMHDJO2K4GMV4LYIWZ33AVCNFSM4W3AU2FKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBUHA4TMNJRGU3Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
https://microsoft.github.io/language-server-protocol/specifications/specification-3-16/#textDocument_prepareCallHierarchy
It would be nice if Eglot supported incoming- and outgoing-call hierarchies, introduced in the 3.16 spec.
lsp-mode
usestreemacs
, which unfortunately is not part of ELPA, to display the hierarchies. Is the newhierarchy.el
in core Emacs suitable for displaying these hierarchies?It seems that we'd have to redraw the entire hierarchy every time we expand a node when making successive call-hierarchy requests; for example, when an incoming-call hierarchy has a branch like
child <- parent <- grandparent
and we expand thegrandparent
node, the entire tree, including siblings and cousins ofchild
, would be redrawn after having fetched thegreat-grandparent
from the server. I don't understand Emacs' internals enough to know if having to redraw everything is an issue or not.The text was updated successfully, but these errors were encountered: