search

linrongbin16 / fzfx.nvim

A Neovim fuzzy finder that updates on every keystroke.
https://linrongbin16.github.io/fzfx.nvim/
MIT License
122 stars 5 forks source link

`FzfxLspReferences` does not work correctly in `Angular` projects. #585

Closed Green0wl closed 7 months ago

Green0wl commented 7 months ago

In Angular projects some references are duplicated despite the fact that the native call vim.lsp.buf.references() works correctly. Tested on an empty Angular project. The video shows the problem. This does not happen in pure typescript. If additional data is needed, I will be happy to provide it. Thank you in advance for your cooperation!

https://github.com/linrongbin16/fzfx.nvim/assets/72041440/130b6bea-a0ec-49fd-bbc8-cf93aa5b2f82

linrongbin16 commented 7 months ago

hi @Green0wl,

thanks for report, I will look into it.

update: after look again your screen recording, the issue seems that there're duplicated locations. I will dedup those duplicated lines.

linrongbin16 commented 7 months ago

hi @Green0wl , I fixed this issue in #587 , please pull latest main branch and try again.

Green0wl commented 7 months ago

Thank you very much for your work, @linrongbin16. As soon as I have a chance to test the new changes - I will be happy to let you know the results.

As far as I understand from commit 3d69db6, you want to fix the bug by checking for already existing rows in the list.

This is a simple and straightforward solution, but I suppose there could be an unnecessary load on the system when a large number of references end up being found and not included in the table, which would certainly slow down overall performance.

For example, when searching for 42 references (which then very probably turned into something like 84), everything just hung and did not respond (at least that's how it was at the time of the issue). I guess it's a good temporary solution, but it would be more rational to eliminate the possibility of duplicates altogether.

I hope for your understanding, and would be glad to hear your opinion on this.

linrongbin16 commented 7 months ago

Do you mean: use other api to precisely query lsp references instead of use vim.api.buf_request_sync (this api query on all lsp clients)?

or you feel lsp locations command is kind of stucking when it's running?

Green0wl commented 7 months ago

First, I would like to thank you for fixing duplicates when searching for variable and function references. Now everything works correctly.

If there is a possibility to use vim.lsp.buf.references(), which works faster and more correctly, without unnecessary search, it would be rational to use it, because the functionality will not change, but the speed of operations will increase. In the meantime, the plugin searches for anything that comes to hand.

Thus, today your plugin gave me the declaration of the function rxjs - interval() when searching for references, when vim.lsp.buf.references() worked correctly without adding declarations to the references, defining them much faster. And actually interval() was in the loadable node modules for typescript.

In general - yes, I think using another api will be more rational in this situation, as this api is designed for the purposes you are pursuing. LSP search and analysis of your plugin is much slower than the usual implementation of vim.lsp.buf.*, because it just sometimes frezes the system and you have to delete the process.

I don't use other LSP location finder functions that often, so it would be incorrect to say that your plugin would be as slow on them too, but I suppose it could be if you use the same actual written functions.

linrongbin16 commented 7 months ago

it's a know issue that these lsp locations commands are a little bit slow.

but I am sure the solution is not changing the api to vim.lsp.buf.references().

I will improve this part later. for now I am doing another important improvement.

I recommend you try glance.nvim. it's much faster!

Green0wl commented 7 months ago

Thanks for the interesting recommendation and best wishes for success in improving an already great plugin. Maybe I'll make a couple pull requests soon, too.

linrongbin16 commented 7 months ago

Thanks for the interesting recommendation and best wishes for success in improving an already great plugin. Maybe I'll make a couple pull requests soon, too.

Thank you! PRs are welcome, and suggestions are welcome!

Actually I'm working on using nvim buffer as file content previewer. For now the file previewing is using bat, which has great performance, and ready to use. But the colorscheme/theme is not compatible with the nvim syntax highlight we're using in nvim editor.

This feature requires tons of efforts and performance improvements, but it's close.