GNU bug report logs - #78149
31.0.50; find-file not working (cl-remove-if)

Previous Next

Full log

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: germanp82 <at> hotmail.com, 78149 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#78149: 31.0.50; find-file not working (cl-remove-if)
Date: Wed, 30 Apr 2025 09:51:45 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: German Pacenza <germanp82 <at> hotmail.com>,  Stefan Monnier
>>   <monnier <at> iro.umontreal.ca>,  78149 <at> debbugs.gnu.org
>> Date: Wed, 30 Apr 2025 09:37:41 -0400
>> 
>> > Spencer, please replace cl-remove-if with seq-remove or something else
>> > that is available when minibuffer.el is preloaded by loadup.  Calling
>> > cl-seq functions in preloaded files is a no-no, because the
>> > corresponding autoloads are not in loaddefs.el, they are in
>> > cl-loaddefs.el instead, and that file is not loaded until cl-lib is.
>> 
>> Ah, I see.  Apologies for the breakage.  Done in the attached patch.
>
> Thanks.  But AFAIU, cl-remove-if is non-destructive, whereas
> seq-remove is destructive.  Does that matter in this case?

I think seq-remove is also non-destructive:

(let ((l (list 1 2))) (seq-remove #'numberp l) l)
; => '(1 2)

Looking at the implementation, it works by doing delq on the result of a
cl-map over the list.  cl-map makes a copy, so the delq is only
destructive on that copy.

Previous Next

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