Conversation
ray-x
left a comment
There was a problem hiding this comment.
hi @ddaniel27
Thanks for the PR
Just a question regarding root check. Otherwise, the changes look good to me.
| if value ~= nil and value.result ~= nil and not vim.tbl_isempty(value.result) then | ||
| table.insert(data, value.result[1]) | ||
| if value ~= nil and not vim.tbl_isempty(value) then | ||
| table.insert(data, value[1]) |
There was a problem hiding this comment.
Thanks. I did not notice it was broken.
| for _, client in ipairs(vim.lsp.get_clients({ bufnr = bufnr, method = method })) do | ||
| if client.server_capabilities.callHierarchyProvider then | ||
| local root = client.config and client.config.root_dir | ||
| if not root or file:find(root, 1, true) == 1 then |
There was a problem hiding this comment.
Should it be?
if root and file:find(root, 1, true) == 1Is there an example of lsp returns nil value for root_dir?
There was a problem hiding this comment.
My thoughts here were to not enforce root to cover edge cases where a bad configuration or architectural decisions of some LSP's could lead to a nil root_dir since the protocol allows it. Personally, I've no encounter these cases since all the LSP's that I use always have a defined root_dir but I'll let you decide here, if you think it's better to enforce root I can change it, let me know.
Hey again! Recently I updated the plugin version from a loooong time without updating it (since now I have some time to deal with this kind of errors lol) and found that when you have multiple LSP's running in a buffer (like a code agent running aside the main LSP as in the screenshot) you will have an error calling the hierarchy lsp function since the handler chooses the first option from the returned clients.
This PR's adds a new function called
pick_hierarchy_lsp_clientjust to pick the first LSP that has the server capabilities to use thecallHierarchyrelated functions and has a relation with the current buffer. Let me know if more information is needed or any change required!Thanks again for this amazing plugin! :)
EDIT:
Why I updated the plugin and what I want actually work is the
definition_previewhandler, I added that too in this PR, basically the actual response structure forresultis a structure like thislocal result = client:request_sync(method, params, timeout_ms or 1000, bufnr)So, I updated the for loop where
datais being populated, let me know your thoughts!