GNU bug report logs - #66806
30.0.50; [PATCH] 'project-find-regexp' passes Git submodules to the search program

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>, Jim Porter <jporterbugs <at> gmail.com>
Cc: 66806 <at> debbugs.gnu.org
Subject: bug#66806: 30.0.50; [PATCH] 'project-find-regexp' passes Git submodules to the search program
Date: Mon, 30 Oct 2023 00:14:48 +0200

On 29/10/2023 08:06, Eli Zaretskii wrote:
>> Cc:dmitry <at> gutov.dev
>> Date: Sat, 28 Oct 2023 22:36:07 -0700
>> From: Jim Porter<jporterbugs <at> gmail.com>
>>
>> --- a/lisp/progmodes/project.el
>> +++ b/lisp/progmodes/project.el
>> @@ -960,7 +960,8 @@ project-find-regexp
>>            (default-directory (project-root pr))
>>            (files
>>             (if (not current-prefix-arg)
>> -              (project-files pr)
>> +              ;; XXX: See the comment in project-query-replace-regexp.
>> +              (cl-delete-if-not #'file-regular-p (project-files pr))
>                    ^^^^^^^^^^^^^^^^
> I think we want to prefer using seq.el functions, since seq.el is
> nowadays preloaded.  Is there a good reason to use cl-delete-if-not
> here?

I'm okay with using seq with other things equal, but in this case both 
cl- approaches are too slow, and seq-difference is no better because of 
consing and indirection overhead (about 10-20% slower than current). I'd 
say it's a shortcoming of seq.el: only having non-destructive versions.

I had some hope for cl-nset-difference, but looking at the 
implementation it just delegates to the non-destructive cousin (I guess 
providing the optimized implementation was left as TODO).

Previous Next

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