Re: Adding refactoring capabilities to Emacs

[Dmitry Gutov]

On 30/08/2023 23:37, João Távora wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
>
> > 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,
>
> Just imagine a diff like *vc-diff*.

Sure.

> > 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.
>
> IMO showing a diff to a user such a is not a power-user-ish thing.  Or
> rather, it might be, but I don't see any better way to show potentially
> complex code changes to users.
>
> > 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.
>
> I don't know how VSCode does it, but refactorings -- at least the kind
> provided by LSP servers -- aren't in general as trivial as simple
> renamings.  They are arbitrary sets of changes to code, like moving
> whole functions from one file to another, adding new sections or new
> files, removing sections or whole files, etc, etc.

I previously posted a link to a screenshot from VS Code, here it is 
again: 
https://bobbyhadz.com/images/blog/rename-variable-vscode/refactor-preview.webp

Indeed, refactorings could be very arbitrary changes, though most of the 
time they are classified in certain types where each changes has some 
semantic meaning where the IDE previews knows how to render it (be it a 
renaming of a file, or of a function, or extracting a variable, etc). 
It's also helpful to show two related changes that are intermixed in the 
diff (e.g. when renaming a class also renames the file it's defined in).

It might be useful to experiment with different changes (simpler and 
more complex) in VS Code and see what kind of previews it managed to 
show for them, naturally based on the data format returned by LSP.

> In fact, they are just like patches.
>
> And I don't know any better way today to display patches to users other
> than diff.
>
> > 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
>
> Synchronous is doable (Eglot does it, and the user shouldn't be doing
> changes to the code while the refactoring backend is computing the
> changes).

It's possible that the backend malfunctions, or e.g. auto-revert-mode 
applies some changes while the user is still considering the changeset.

> What I meant by request-proposal is that there is this
> sequence
>
> 1. a request by the user selecting one of multiple offered
>     refactorings.
>
> 2. a synchronous response proposing changes
>
> 3. The decision by the user to apply some or all of these proposed
>     changes.  This decision might be taken in advance in step 1, if the
>     user trusts the refactoring engine enough.
>
> Note: Files are not saved automatically, because this is a different
>        concern.

"Not saving files automatically" is a power-user approach too.

We have that in query-replace and naturally in 
xref-query-replace-in-results too, but having a large refactoring across 
many files end up in a not-synced-to-disk condition is a complication. 
Not everyone knows about save-some-buffers and auto-revert-mode.