[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 :-)
- Re: Adding refactoring capabilities to Emacs, (continued)
Re: Adding refactoring capabilities to Emacs, Felician Nemeth, 2023/09/07
Re: Adding refactoring capabilities to Emacs, Dmitry Gutov, 2023/09/07
Re: Adding refactoring capabilities to Emacs, Dmitry Gutov, 2023/09/07
Re: Adding refactoring capabilities to Emacs, Eshel Yaron, 2023/09/08
- Re: Adding refactoring capabilities to Emacs, João Távora, 2023/09/08
- Re: Adding refactoring capabilities to Emacs, Eshel Yaron, 2023/09/08
- [semi off topic] grep-based refactoring [was: Adding refactoring capabilities to Emacs], tomas, 2023/09/08
- Re: [semi off topic] grep-based refactoring [was: Adding refactoring capabilities to Emacs], João Távora, 2023/09/08
- Re: [semi off topic] grep-based refactoring [was: Adding refactoring capabilities to Emacs], Dmitry Gutov, 2023/09/08
- Re: [semi off topic] grep-based refactoring [was: Adding refactoring capabilities to Emacs], tomas, 2023/09/08