bug#65854: Multi-file replacement diff

[Dmitry Gutov <dmitry@gutov.dev>]

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