[செவ்வாய் மே 07, 2024] Jim Porter wrote:

> On 5/7/2024 8:12 PM, Visuwesh wrote:
>> Thanks for your input.  If I missed something from wgrep that you use,
>> please let me known.  I will play around with wgrep in some time to
>> learn more about what it offers myself.
>
> In addition to the things you mentioned, here are the most important
> features from wgrep for me:

Thanks.

> * Mark all non-result parts of the buffer (the command string, file
>   names, line numbers, etc) as read-only. This is especially valuable
>   if you want to use 'query-replace' or similar to modify the
>   results. Then you can't inadvertently edit those bits.

This is now done.

> * Fontify any results with changes (both in the grep-mode buffer and
>   the original files). This is really useful for being able to see
>   what I've changed.

I agree that it would be nice to have this in *grep* buffer but I would
like to avoid editing the file on-the-fly since it introduces typing lag
IME with occur-edit-mode.  If you want to know the edits that were made,
you can use diff-buffer-with-file so I hope leaving out the highlighting
in the file would be okay.

> * Adding all the necessary hooks/functions so other grep-like modes
>   can use this. For example, see this file from wgrep, which lets you
>   use wgrep with ag.el:
>   <https://github.com/mhayashi1120/Emacs-wgrep/blob/master/wgrep-ag.el>. (This
>   matters to me partly because I'm the author of Urgrep - a "universal
>   recursive grep" mode that can use any grep-like program to do
>   searches. I've added my own support in Urgrep for wgrep.)

With grep-edit-minor-mode, as long as the compilation-message
text-property is present at the beginning of the line, you do not need
to do anything extra.  I look at this to gain the information about the
filename and the line number.