`FzfxLspDefinitions` feedbacks
linrongbin16 opened this issue · 9 comments
comments from #129 :
Now I am using fzf-lua in UNIX, and this plugin has lsp related symbols commands, since Lsp_diagnostics has been finished, is symbols on the schedule ?
Hi @leoatchina , I had implement the lsp_definitions command in #150 , feel free to try and give me feedbacks!
But when I develop the FzfxLspDefinitions command, I feel like there's some difference between lsp commands and normal fzf search list.
Usually I will make several variants to help user prefill the query, e.g. the FzfxLiveGrep command, you can also input the query by visual select (FzfxLiveGrepV), cword (FzfxLiveGrepW) and yank text (FzfxLiveGrepP).
But for lsp definitions/implementations/references/etc, users' habit is to press gd
and go to symbol locations. For example I have the key mapping defined as:
vim.keymap.set('n', 'gd',
'<cmd>lua vim.lsp.buf.definition()<cr>',
{ desc = 'go to definitions' })
The implementation is using Neovim's lsp api: vim.lsp.util.make_position_params, which always search the cword text.
So I think only one FzfxLspDefinitions
command is enough? I think I don't need to provide other variants like FzfxLspDefinitionsV, FzfxLspDefinitionsW or FzfxLspDefinitionsP. Because they all make no sense in this scenario.
acturally, I use fzf-lsp
, glance.nvim
in my config, since fzf-lsp
do not offer floating windows after definition
, declaration
, etc so glance.nvim
is used to call up floating windows. Below is what I configed (may be not beautiful)
-- glance
map('n', '<M-;>', [[<cmd>Glance definitions<CR>]], opts)
map('n', '<M-,>', [[<cmd>Glance type_definitions<CR>]], opts)
map('n', '<M-.>', [[<cmd>Glance implementations<CR>]], opts)
map('n', '<M-/>', [[<cmd>Glance references<CR>]], opts)
-- fzf_lsp
vim.lsp.handlers["textDocument/codeAction"] = fzf_lsp.code_action_handler
vim.lsp.handlers["textDocument/references"] = fzf_lsp.references_handler
vim.lsp.handlers["textDocument/definition"] = fzf_lsp.definition_handler
vim.lsp.handlers["textDocument/declaration"] = fzf_lsp.declaration_handler
vim.lsp.handlers["textDocument/typeDefinition"] = fzf_lsp.type_definition_handler
vim.lsp.handlers["textDocument/implementation"] = fzf_lsp.implementation_handler
vim.lsp.handlers["textDocument/documentSymbol"] = fzf_lsp.document_symbol_handler
vim.lsp.handlers["callHierarchy/incomingCalls"] = fzf_lsp.incoming_calls_handler
vim.lsp.handlers["callHierarchy/outgoingCalls"] = fzf_lsp.outgoing_calls_handler
if vim.g.ctags_type ~= '' then
vim.lsp.handlers["workspace/symbol"] = vim.lsp.tagfunc
else
vim.lsp.handlers["workspace/symbol"] = fzf_lsp.workspace_symbol_handler
end
map('n', 'gh', [[<Cmd>FzfOutgoingCalls<Cr>]], opts)
map('n', 'gl', [[<Cmd>FzfIncomingCalls<Cr>]], opts)
map('n', '<M-l>s', [[<Cmd>FzfDocumentSymbols<Cr>]], opts)
map('n', '<M-l>w', [[<Cmd>FzfWorkspaceSymbols<Cr>]], opts)
After littlely test latet fzfx.nvim
, I'm glab to find it offterd floating window, which fit my needs well. But symbols
, call hierrachy
is not completed.
Editing in floating window like glance.nvim
, lspui.nvim
are not strongly recommended , but preview ``symbols,
call hierachy` in floating is also what I want,.
@leoatchina, me too, I also use glance
for lsp definitions/implementations/references symbols navigation. because It's much more friendly to me.
'Editing contents directly in preview window' (just like glance.nvim
) is a super big feature request for this plugin, because the whole architecture is quite different.
For now the whole floating window is actually a terminal running fzf command, using fzf option --preview
and --preview-window
. So the preview window is not an editable nvim buffer/window.
So I cannot provide this feature in just 1-2 PRs, but I am also interested in this feature, will try to implement it because it seems quite useful and fancy.
Also I could try to cover other lsp protocol methods in this plugin.
editable windows is an amazing feature but preview and repon in tab/vsplit/split is also acceptable, and this workflow is as efficient as glance, just keep it simple and stupid
Also I could try to cover other lsp protocol methods in this plugin.
so I can delete fzf-lsp
editable windows is an amazing feature but preview and repon in tab/vsplit/split is also acceptable, and this workflow is as efficient as glance, just keep it simple and stupid
no worry, I will first do some investigation on the solution.
hi @leoatchina , do you have any idea, how to test the incomingCalls
and outgoingCalls
lsp protocol methods? I have read the language specifiction
but I am still confusing about what is incoming calls
and outgoing calls
......
incoming & outgoing calls merged into main branch.