Re: Adding refactoring capabilities to Emacs

[Dmitry Gutov]

On 29/08/2023 13:53, João Távora wrote:
> On Sun, Aug 20, 2023, 23:52 Dmitry Gutov <dmitry@gutov.dev 
> <mailto:dmitry@gutov.dev>> wrote:
>
>     On .
>
>     What we don't have is any advanced UI coming with that. Traditional
>     IDEs
>     (and apparently even VS Code now:
>     https://bobbyhadz.com/images/blog/rename-variable-vscode/refactor-preview.webp 
> <https://bobbyhadz.com/images/blog/rename-variable-vscode/refactor-preview.webp>)
>     have been featuring the "preview changes" feature for years. One where
>     you could see which files will be affected, and even opt out from some
>     of the changes.
>
>     It seems like the LSP protocol provides enough information for this to
>     work (the response to the "rename" action is a list of changes to be
>     performed on the client), so the UI can definitely be extended there.
>
>
> Philip K. has proposed a patch to Eglot that implements this in 
> bug#60338.  It is not without problems, but was generally agreeable to 
> me. Would you have a look, Dmitry? We stalled while thinking about the 
> user confirmation model...

Hmmm. Some screenshots would go a long way, I haven't tried the patch 
yet, but from what I can tell from the description, it's a pretty 
power-user-ish approach to UI.

Similar to what we ended up doing with checkin-patch in VC -- powerful, 
but no very obvious to a non-pro user in how it can be operated. It is 
surely a good addition to Eglot, but the refactoring interface I was 
thinking of would have been more graphical (very vaguely in the style of 
Xref), looking a little closer to the VS Code screenshot I posted.

But those are just my expectations -- opinions welcome.

> Anyway, are we aiming at making Eglot and LSP the only provider of 
> refactoring in Emacs? If we aren't, then I think we should be working on 
> a compatibility layer (which can be modeled after LSP's request/proposal 
> mechanism) even if -- for the time being -- LSP/Eglot is the only 
> provider. That move would inherit a lot of code from Eglot related to 
> applying the changes, confirming etc, meaning those details would 
> already be solved.

We have refactorings in various places: as Arne mentioned, there are 
some established third-party packages, of different degrees of 
popularity. And from built-in ones we also have, at the very least, some 
commands which present long lists of search results with Xref interface 
(some plugged into by Eglot when it's enabled, and some not), those 
could also use a better interface for global replacements.

Regarding compatibility layer, I'm not sure I see a request-response 
mechanism here. I'd expect to see something synchronous, e.g. a call

  (refact-start CHANGES)

where CHANGES are a list of changes in some pre-determined format (with 
file names and buffer/byte positions or lines and columns). Then the UI 
takes over, shows the user the proposed changes, allows paging through 
them, maybe disabling certain ones (for all changes in a file, or all 
files in certain dir, or individual changes too), and applying in bulk 
after a confirmation.

Maybe a callback at the end could be useful, though, e.g. to update any 
views that need to be updated. Could always be added later.

And here's a general question to such UIs: what happens if one of the 
changes (in the middle of the list) becomes un-apply-able. At which step 
the user finds out about this. I don't have this solved very well in 
xref-query-replace-in-results, but an attempt was made.