search

smjonas / inc-rename.nvim

Incremental LSP renaming based on Neovim's command-preview feature.
MIT License
637 stars 8 forks source link

Trigger preview on first keypress #20

Closed weilbith closed 1 year ago

weilbith commented 2 years ago

Hey 👋🏾

I think the title is pretty dump, but I fail to summarize the issue better. The problem is that if I use a keymap like from the README, the whole preview, coloring, ... process only starts once I type something. So the current word under the cursor gets inserted, but nothing happens. Only when I alternate the word it starts. I would expect (I think think it was like that in the past) to get all occurances highlighted immediately and also dressing.nvim to pop-up right away. Right now it looks like it is hanging. Am I doing something wrong?

smjonas commented 2 years ago

Hey, no you're not doing anything wrong :) I think this has been a limitation of this plugin from the start. The reason why the highlighting only starts on the second keypress is that the LSP request to fetch the references is asynchronous. This means that on the first invocation of the preview callback, there is nothing to highlight yet because the references haven't been retrieved yet. I might add a synchronous option which would wait for the references to arrive and starts highlighting immediately (by using vim.lsp.buf_request_sync instead of vim.lsp.buf_request). That might be quite laggy in some cases though, especially if the LSP server hasn't started up yet. Do you think that would work for you?

weilbith commented 2 years ago

Hmm. I'm a bit unsure if I get this right. If this is asynchronous, shouldn't it still work for the initial case where we insert the <cword>? Then the UI should just pop-up immediately, but the preview happens when ever the asynchronous respond arrives. Or what is the problem? 🤔

smjonas commented 2 years ago

The problem is that I can't do the highlighting outside of the preview callback. When the LSP server responds with the results, we have already returned from the preview callback. While I could theoretically handle all of the buffer / highlights restoration within the plugin directly, that should really be the task of Neovim's command preview. Does that make sense?

As I said, the only way I think this can be avoided is to make the LSP request synchronous.

weilbith commented 2 years ago

Okay, interesting.

Then maybe do it synchronous for now and add a configuration option for people who dislike it?