Ability to use multiple-cursors when performing an eglot-rename

[cowboyd]

Like most folks, I use eglot-rename all the time and love it. However, one thing I do miss from my IntelliJ days is the way that the editor highlighted every occurrence of the variable and showed multiple cursors operating on the document at once as you played with the new name. It's just such a pleasant interaction that lets you see how it will look everywhere before you actually commit.

I assume that the primary reason that this is done in a "modal" fashion is because it isn't actually the editor that is making the changes to the document, but instead it is the LSP server. However, given that it is a very reliable function, how hard would it be to make the edits in multiple places in real time, and only reset the document back to the old state in the event that the edits failed?

Again, the current functionality is just fine, and it works in exactly the same way that VSCode does today. However, the IntelliJ method was simply delightful. Is there a way this sort of "optimistic" editing could be made pluggable?

[joaotavora]

Could theoretically be implemented:

• at the expense of very resource intensive interaction with the server, each character typed (or deleted), needing a LSP round trip. Also LSP renames ids in other buffers and files as well.
• OR, much more efficiently, using the ranges returned by an LSP textDocument/rename for a single rename, and then (ab)using those ranges establish multiple cursors (using whatever package gives that funcionality -- in a way that works across other buffers and unvisited files, too)

But both approaches are very laborious. I certainly won't work on this, and I don't think it should be part of core Eglot. Maybe that elusive refactor.el package, who knows? @dgutov if he's not tracking this already.

[dgutov]

Looking at the UI and its limitations (multiple cursors not being visible outside of the current buffer's viewport), I would probably expect it to be based on the current "highlight occurrences of symbol at point" feature. Something would issue the request for their positions once, then enable multiple-cursors regions based on the result, and let the user do the input without any additional requests until the multiple cursors are collapsed.

It could be a refactor/rename UI options as well, but I wonder what we'd expect to do with the matches that are in files that have no currently visited buffers. Could we even delegate to the multiple-cursors package for handling of such changes?

[dgutov]

For later reference, IntelliJ's rename UI mentioned seems to be depicted here: https://www.jetbrains.com/help/idea/rename-refactorings.html#inplace_rename

@cowboyd Do you remember what happens to the occurrences outside of the current viewport? Are they renamed silently?

[cowboyd]

I would probably expect it to be based on the current "highlight occurrences of symbol at point" feature.

Yes, I wouldn't expect it to do anything in any other buffer, or outside the current buffer's viewport. It did not feel heavyweight or un-performant in any way. It's purely a visual flourish.

[joaotavora]

Yes, I wouldn't expect it to do anything in any other buffer,

If it doesn't do anything then you will end up with broken code. It has to do the rename there as well.

[dgutov]

Yes, I wouldn't expect it to do anything in any other buffer, or outside the current buffer's viewport.

If so, does IntelliJ's functionality differ much from that the multiple-cursors package currently offers? That is, adding cursors to occurrences of the given symbol according to Emacs's buffer syntax table (not any language-specific parser). Do you encounter many cases where the results are different?

The IntelliJ doc tree I linked above mentions a separate "multiple cursors" functionality as well, so it apparently does these two things in somewhat different ways. But I'd have to install it again to find out.