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

Previous Next

Package: emacs;

Reported by: Žygimantas Bruzgys <me <at> zygi.xyz>

Date: Tue, 12 Jun 2018 07:56:03 UTC

Severity: minor

Found in version 26.1

Full log


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

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: Re: bug#31796: 27.1; dired-do-find-regexp-and-replace fails to find
 multiline regexps
Date: Wed, 02 Dec 2020 19:47:43 +0200
> 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.




This bug report was last modified 4 years and 246 days ago.

Previous Next


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