linrongbin16/fzfx.nvim

`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.