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

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, abela <at> chalmers.se, 31796 <at> debbugs.gnu.org
Subject: Re: bug#31796: 27.1; dired-do-find-regexp-and-replace fails to find
 multiline regexps
Date: Tue, 1 Dec 2020 04:21:23 +0200

On 30.11.2020 10:49, Juri Linkov wrote:

>> Even if it worked differently, -P imposes a significant performance penalty
>> from what I see, even when the extra syntax is not actually used. So we
>> couldn't enable it by default.
> 
> When a grep input pattern contains a newline, then xref could use
> the same algorithm as is used for 'M-.', i.e. run 'grep -Pzl'
> to get the file names that contain the pattern, then return
> these file names without line numbers.

Do you mean the xref items backed by find-func.el? There are a 
particular kind of references which are usually unique enough that 
special navigation logic can work. It's also implemented this way 
because the search can be performed without reading file contents (which 
would be slower).

> This works exactly
> like a new feature of extending xref-show-xrefs-function
> with a new completion function was proposed recently on emacs-devel

For Grep results, I think the line number is important because we're 
even more likely to have multiple lines with the same contents in one file.

What we *could* do, is run Grep, then take just the list of files names 
that it returns, visit them all in Emacs and repeat the search in all of 
them. But that would require a more complex abstraction than just 
"search command", as well as some juggling of buffers that weren't open 
before (we don't want to add more open buffers just because the user has 
run a search, right?).

I'm not sure cost/benefit is worth it, but if you'd like to try your 
hand at writing it, please go ahead. Just let me add ripgrep support first.

BTW, that approach could fit project-search and 
project-query-replace-regexp well, I think. Perhaps the dired-do-* 
functions, too. Should improve their performance in a number of scenarios.

> (BTW, why it's not installed yet?)

Waiting for the feedback.

It went through several minor revisions. Do you like the most recent 
version? If so, please reply to the message containing it. If you don't, 
please also reply and say why.

> So like this feature presenting such completions without line numbers:
> 
>    lisp/progmodes/project.el:(cl-defgeneric project-root)
>    lisp/progmodes/project.el:(cl-defmethod project-root ((project (head transient))))
>    lisp/progmodes/project.el:(cl-defmethod project-root ((project (head vc))))
> 
> xref for grep could work the same way without line numbers:
> 
>    lisp/progmodes/project.el:names"^Jproject--read-file-cpd-relative)
>    lisp/progmodes/project.el:names"^Jproject--read-file-absolute)
> 
> Then visiting such grep hit should use Emacs search functions
> to find the grep hit in the visited file.

These are two substrings inside that file that matched the search 
regexp. But there could be substrings in the same file that are equal to 
either of these but don't match said regexp, e.g. because they are 
preceded or followed by some different contents.

Previous Next

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