Re: Adding refactoring capabilities to Emacs

[João Távora]

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*.

> 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.

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).  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.

João