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

Previous Next

Full log

Message #173 received at 31796 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: abela <at> chalmers.se, 31796 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#31796: 27.1;
 dired-do-find-regexp-and-replace fails to find multiline regexps
Date: Thu, 03 Dec 2020 00:26:40 -0500

[[[ 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. ]]]

  > Subject: bug#31796: 27.1;
  >  dired-do-find-regexp-and-replace fails to find multiline regexps
  > Resent-From: Eli Zaretskii <eliz <at> gnu.org>
  > Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
  > Resent-CC: bug-gnu-emacs <at> gnu.org
  > Resent-Sender: help-debbugs <at> gnu.org
  > To: Dmitry Gutov <dgutov <at> yandex.ru>
  > Date: Wed, 02 Dec 2020 19:47:43 +0200
  > Message-Id: <83wny0f6bk.fsf <at> gnu.org>
  > From: Eli Zaretskii <eliz <at> gnu.org>
  > In-Reply-To: <0646a65f-db21-b377-6897-caeb6ff3e10c <at> yandex.ru> (message from
  >  Dmitry Gutov on Wed, 2 Dec 2020 19:43:52 +0200)
  > Cc: abela <at> chalmers.se, rms <at> gnu.org, 31796 <at> debbugs.gnu.org

  > > Cc: rms <at> gnu.org, abela <at> chalmers.se, 31796 <at> debbugs.gnu.org
  > > From: Dmitry Gutov <dgutov <at> yandex.ru>
  > > Date: Wed, 2 Dec 2020 19:43:52 +0200
  > > 
  > > >> 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.
  > > 
  > > It could buffer them until the full file has been parsed. Encoding 
  > > detection and conversion must add a certain overhead anyway, so I'm not 
  > > sure how expensive the extra buffering would be in comparison.
  > > 
  > > As a bonus, per-file buffering like that would allow easier 
  > > parallelization of searches.

  > Buffering means you don't output matches as soon as you find them,
  > which might be regarded as a kind of regression -- see Richard's bug
  > reports a few days ago.  And since you never know where in the file
  > the telltale byte sequences will appear, you will need to always wait
  > until the entire file is read -- which could be prohibitive for very
  > large files.

In my case, I was definitely going to wait until the search finished,
to see all the responses.

But it is mudh easier to look at them if they come out one by one,
rather than all at once due to buffering.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Previous Next

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