GNU bug report logs - #59935
29.0.60; project-list-buffers is slow

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 59935 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#59935: 29.0.60; project-list-buffers is slow
Date: Mon, 12 Dec 2022 20:10:32 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Cc: dgutov <at> yandex.ru,  59935 <at> debbugs.gnu.org
> Date: Mon, 12 Dec 2022 19:51:48 +0200
> 
> >> +** The argument FILTER-PREDICATE of 'list-buffers-noselect' is obsolete now.
> >> +It will be removed in next versions.
> >
> > I thought we wanted to make the command faster in Emacs 29.  I very
> > much doubt that deprecation of an argument will have that effect.
> >
> > I'm also not sure I agree with obsoleting and removing that argument.
> > We don't have enough justification for that, not yet.  That it was
> > introduced for a particular use case, and that use case no longer uses
> > it, doesn't mean there won't be others.  After all, we don't introduce
> > additional arguments unless we think it will be useful in more than
> > one case.
> 
> Having both FILTER-PREDICATE and BUFFER-LIST-FUNCTION is too problematic.
> Which one should take priority over another when both specified?

I thought I answered that in my original proposal:

> Why not leave alone that additional PREDICATE argument of
> list-buffers-noselect, and add a feature where the BUFFER-LIST
> argument could be a function?  That's be a compatible change.  Just
> keep the PREDICATE argument and the code which supports it, and
> document that if PREDICATE is a function, BUFFER-LIST cannot be a
> function.

Note the last sentence.  Doesn't it resolve the difficulty in a
reasonable way?

Previous Next

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