bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#65854: Multi-file replacement diff


From: Dmitry Gutov
Subject: bug#65854: Multi-file replacement diff
Date: Wed, 27 Sep 2023 00:39:09 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 25/09/2023 20:58, Juri Linkov wrote:
On 24/09/2023 10:36, Juri Linkov wrote:
As discussed on emacs-devel, here is the patch that implements
a standalone command that reads a list of files and replacement strings,
then shows a diff to review before applying replacements.
Also provided the Dired integration to show the replacement diff
on marked files.  Later the same function could be used
to show replacement diffs from the xref buffer and maybe
from other packages as well.
Here's a counter-proposal: we were talking about a "refactoring" packages
on emacs-devel, maybe a week ago. And I suggested a function that would
take a list of changes (as some data) and present them using some
customizable logic: the current Eglot's solution uses a diff, and I'll add
an implementation that shows a tree-like buffer with checkmarks, probably.

I'll be starting on this any day now ;-(

So... provided this won't take too long, I would suggest your code here
just focuses on creating a list of changes (those shouldn't require buffers
to visit files), and then you'd be able to pass them on to
'refact-show-changes' (name under construction), which would then use the
interface that the user prefers.

This was we'll also consolidate the diff-generating code for features of
this sort.
I'm not sure this complication is necessary.  The proposed patch
does its job already.  So more generalizations could be added later.
If you are sure.

I just wouldn't want to keep unnecessary defcustoms around.
Actually my point was that there is already eglot--propose-changes-as-diff.
And now with addition of multi-file-replace-as-diff you will have two cases
to generalize that would be simpler to do than with only one case.

Yes, that should help. Even having your patch in the bug tracker to refer to already helps (as well as the discussion around it).

I'm just saying that if Eglot has its own existing custom vars, and misearch.el has its own, it will take extra effort to unify them (or keep extra options inside said packages, I guess, increasing unavoidable duplication).





reply via email to

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