bug#31796: 27.1; dired-do-find-regexp-and-replace fails to find multiline regexps

[Dmitry Gutov <dgutov@yandex.ru>]

On 01.12.2020 07:20, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>    > To sum up, there are options, but I don't see a working solution that is
>    > based on GNU Grep.
> 
> Can people think of a new feature that would be easy to add to GNU grep
> that would make it easy for Dired to handle all cases correctly?
> 
> I don't know what the problem is, but if it has to do with parsing the
> grep output, here's an idea: an option to tell GNU grep to use quoting
> on file names and the match strings, Perhaps in the same way GNU ls
> does.

Grep already has that, more or less, with --null. pcregrep doesn't 
(which was my other example).

What Grep could add, however, is a "multiline" matching mode similar to 
what pcregrep and ripgrep have. Meaning, it would allow matches to cross 
newlines (with certain rules on whether "." matches a newline) but 
without requiring the -z mode. So it would still report correct line 
numbers for the matches.

> Another idea is an option to output numerical byte positions in the
> file instead of the lines that are matched.  Emacs can feed those byte
> positions into byte-to-position to convert them into buffer positions.

Like Eli said, that's -b.

But considering Emacs would have to visit each file, to post-process the 
results with byte-to-position, this might turn out to be not much faster 
or easier to implement than simply visiting every file that (according 
to Grep) has matches and repeating the search in Emacs.