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


View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>, Juri Linkov <juri <at> linkov.net>
Cc: abela <at> chalmers.se, 31796 <at> debbugs.gnu.org
Subject: bug#31796: 27.1; dired-do-find-regexp-and-replace fails to find multiline regexps
Date: Sun, 29 Nov 2020 04:30:14 +0200
On 25.11.2020 22:30, Eli Zaretskii wrote:
> I'd like us to fix the current binding of Q so that it supports
> everything the previous command did.

Just how much of "everything" are we talking about?

For instance, a number of character classes in Emacs regexps are 
dependent on the syntax table. Like [:word:], for instance.

Even [:space:] is dependent on syntax, while it matches a fixed set of 
characters in Grep. So when searching across different file types we 
can't even "expand" such constructs into concrete characters to search for.

One approach I've considered is replacing such unsupported constructs 
with '.', or removing them entirely for constructs like \< and \_<. And 
then post-filter the resulting matches in Emacs.

For example, xref-references-in-directory uses a special case of this 
approach. In the general case though, I worry users would sometimes 
create regexps that result in an exponentially slow or just match-all 
regexp being passed to Grep, which would never finish, for no obvious 
reason.

Someone should try it, but it's a fair amount of work to handle all 
supported constructs, and to catch all (most?) the regexps which we 
can't support in this mode.




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.