emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adding refactoring capabilities to Emacs


From: João Távora
Subject: Re: Adding refactoring capabilities to Emacs
Date: Sat, 09 Sep 2023 00:17:23 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Dmitry Gutov <dmitry@gutov.dev> writes:

> Although the impact somewhat depends on whether the current
> performance is proportional to the number of files, or the number of
> edits.

I think it depends on both, but a large number of edits is relatively
slow anyway.  That's probably because you have to make lots of
arrangements to get correct undo behaviour and call the self-admittedly
"very slow" replace-buffer-contents C functions.  Anyway, I never looked
at performance because noone ever complained until you (and it didn't
and still doesn't bother me).  But maybe there's some low-hanging fruit
there.

> You skipped over the remainder of my email where I explained why I
> liked to start with step 4.

Probably didn't have anything useful to add.  You can focus on whatever
you part you like, of course.

> We can still want to be able to tweak it during Emacs 30's
> development, of course, and maybe even later, but it's impossible not
> to discuss and document if we want customizable/swappable UIs for
> confirmation anyway.

I think everyone already agreed we want that.

> Anyway, I guess we'll implicitly decide that both "rename" and
> "organize imports" are always available and create commands with
> dedicated bindings for them?

At least for "rename".  For the others, not so sure yet.

> Why the latter, BTW? Or are there more commands like that? From what
> I'm reading, "organize imports" is not a part of the official LSP
> protocol, though there are extensions.

It's a common code for an LSP action.  Other common names:

 "source.organizeImports"
 "refactor.extract"
 "refactor.inline"
 "refactor.rewrite"
 "quickfix"

>>> Not sure why the cutoff is there: and not for example "if all the
>>> changes are in the current file", or "are all visible on the
>>> screen".

Seemed reasonable and easy to implement, so I did it.  Noone complained
and I quite like it.  Your ideas are also quite good, so other cutoff
criteria welcome (even if just to Eglot right now) if you want to keep
shaving this interface yak :-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]