bug#70820: [PATCH] Editable grep buffers

[Jim Porter]

On 5/8/2024 4:58 AM, Eli Zaretskii wrote:
> > From: Visuwesh <visuweshm@gmail.com>
> > Cc: 70820@debbugs.gnu.org
> > Date: Wed, 08 May 2024 08:52:51 +0530
> >
> > Basing it on occur-edit-mode would be a lot more work I think, but I
> > understand your concern wrt it being already established and bug-free,
> > etc.  This was my original plan but I bailed since the occur buffer's
> > text-properties has marker objects (IIRC) but I want to avoid using
> > markers since having many buffers open was a personal pet peeve of mine,
> > along with the slow-typing experience due to occur's
> > after-change-function immediately reflecting the changes in the original
> > buffer.  The latter is avoided in my patch since we commit the changes
> > only at the end so the typing during the edit is smooth.
>
> I think having similar features that work very differently is not a
> good thing for Emacs.  So I urge you to reconsider your decisions and
> make this more like occur-edit-mode.  In particular, I don't
> understand the difficulty with using the markers and what does it have
> to do with the ability of having many Grep buffers.

I agree that using markers would probably be a good idea, assuming I'm 
imagining things correctly. (In particular, this needs to be robust 
about what happens if you have a file open with some changes already, 
run grep to find matches in that file, and then modify those matches.)

However, I agree with Visuwesh about not committing changes until the 
end. For the grep case, you could have results in many, many files, 
including (especially?) ones not open in Emacs yet. By waiting until the 
end to commit the changes, you don't have to worry about what happen to 
these files. (The only other options I can think of would be to visit 
those files, which could require opening hundreds or thousands of files 
at once; or to immediately change the files on disk, which could ruin 
those files.)