GNU bug report logs - #31796
26.1; dired-do-find-regexp-and-replace fails to find multiline regexps

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: abela <at> chalmers.se, rms <at> gnu.org, 31796 <at> debbugs.gnu.org
Subject: bug#31796: 27.1; dired-do-find-regexp-and-replace fails to find multiline regexps
Date: Wed, 02 Dec 2020 19:39:48 +0200

> Cc: abela <at> chalmers.se, 31796 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Wed, 2 Dec 2020 19:17:06 +0200
> 
> On 02.12.2020 16:56, Eli Zaretskii wrote:
> > The point is that our heuristics for detecting encoding is not
> > perfect, so it could fail.
> 
> Do you imagine Grep could use a more reliable detection algorithm?

No, I don't.  But it could allow the user to specify a different
encoding for each file, as in

   grep --encoding=FOO FILES1* --encoding=BAR FILES2*

etc.  And even if it just did the job of the same quality as we do, it
will do it faster, which is why we use Grep in the first place, right?

The important part of the "enhancement" I described is actually the
fact that the output gets encoded in a single encoding, no matter what
was the encoding of the original files.  This makes reading and
decoding the output simple and always correct.

> Although... since it has to scan the full file anyway, it could first do 
> a quick detection, and then maybe rescan from the beginning if the 
> encoding turns out to be something else.

That'd be too late, as some matches were already output.

Grep does begin by scanning a small portion of the file (at least it
did, back when I was familiar with its code), so detection in the same
style as Emacs does should be a natural addition, I think.

Previous Next

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