GNU bug report logs - #70820
[PATCH] Editable grep buffers

Previous Next

Full log

View this message in rfc822 format

From: Visuwesh <visuweshm <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70820 <at> debbugs.gnu.org
Subject: bug#70820: [PATCH] Editable grep buffers
Date: Wed, 08 May 2024 17:48:02 +0530

[புதன் மே 08, 2024] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: 70820 <at> debbugs.gnu.org
>> Date: Wed, 08 May 2024 08:52:51 +0530
>> 
>> [செவ்வாய் மே 07, 2024] Eli Zaretskii wrote:
>> 
>> > [...]
>> > Thanks for working on this.
>> >
>> > I wonder if this could be somehow either based on 
>> 
>> 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.

It is not having many Grep buffers but visiting the "original" files
unnecessarily that tends to be annoying.  I am not sure if there is a
scheme to make these visits conservative, I would need to look further.

I do not think using track-changes to keep track of the edits will do
too much harm since the trickiest part of keeping track of the buffer
modifications proper is left to an "external" library.  If I'm not
wrong, track-changes was introduced to make looking at buffer
modifications less error-prone.

>> This is what I am aiming for ideally since I am a fan of its interface
>> myself (preferring it over xref).  The major difference between
>> occur-edit-mode and my patch's grep-edit-minor-mode is that it is
>> implemented as a minor mode: I chose a minor-mode because all the buffer
>> local variables that are required to make the commands from the *grep*
>> buffer functional are killed when switching major-modes (so even g
>> doesn't work!). We could work around this by marking the relevant
>> variables permanent-local but this feels unclean?
>
> I don't think I understand this difficulty, either: with
> occur-edit-mode it is solved by making occur-edit-mode be derived from
> occur-mode.  Couldn't you do the same with your mode?

No because occur-mode makes occur-revert-arguments permanent-local so
`g' survives the major-mode changes.

For revert-buffer alone, compilation-arguments needs to be marked
permanent-local.  As it is a part of compile.el, I am not sure if
marking it as such is safe.  This is why I think having a minor-mode is
better.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.