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: Dmitry Gutov
Subject: Re: Adding refactoring capabilities to Emacs
Date: Thu, 7 Sep 2023 23:41:08 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 07/09/2023 19:20, Stefan Monnier wrote:
Also, it would be very good if we could have an early backend which is
*not* LSP.  An obvious candidate is Elisp.  I'd like to know what is
the minimal effort to write a lisp function based on the new
macroexpanding tricks that Stefan Monnier developed that says
precisely where a given symbol is used as a variable in a function.
As far as I understand,  these techniques are currently being used for
accurate completion, but they could maybe be used for accurate
refactorings.

Hmm... the `elisp--local-variables` functionality (beside the
associated security issues and occasional errors) provides only
a (somewhat) reliable list of variables that are in-scope.  So it could
potentially be extended to offer a way to jump to the declaration of
a local variable from a reference to it, but it doesn't know how to find
all (and only) the references to a given variable.

We could extend it to a full code-walker that can distinguish between
identifiers that refer to functions vs variables and which skips "data"
and obeys scope, and thus collect reliably all the references.
But `cconv-analyze-form` is probably a better starting point :-)

I think the Helpful packages used some of the approach. Though I'm not sure how precise/thorough it is, and combining the outputs of xref-find-references and elisp--local-variables is likely to be faster. As a first/initial implementation anyway.

If we're only talking about 'rename', at least.

but that's already taken in diff-mode.

I don't think the current `C-c C-c` binding in `diff-mode` should get in
the way.  That command is available via different bindings already, and

diff-apply-everything is a little destructive, though (there is no 'undo' across multiple files), so maybe a warning could help. Or make it an initially-disabled command, for example.

this is a specific use of diff-mode where `diff-apply-everything` makes
a lot of sense (as opposed to `C-x v =` where the changes are usually
already applied anyway so `diff-apply-everything` is rarely what we want).

So... the binding wouldn't be used in "regular" Diff buffers, it it just would stop with a "hunk already applied" message? If it's the former, we'd need to distinguish the "refactoring diff" buffers by look somehow.

- 'git diff' has a less-frequently used option called '--word-diff'
which could reduce the length of the diff in the case I am testing (but
I guess diff-mode would have to be updated to support that output). And
another way in that direction would be to reduce the size of the diff
context (e.g. to 0).

[ Side note: we could also extend diff-mode to do such "rewrite" inside
   Emacs.  Hiding some of the context should be fairly easy, for example.
   Also I've often wished for `diff-refine-hunk` to try and interlace
   the lines so as to minimize the distance between the "before" and
   "after" lines.  ]

Interesting.



reply via email to

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