bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance

[Dmitry Gutov]

On 05/01/2023 08:32, Eli Zaretskii wrote:
> > Cc:58950@debbugs.gnu.org
> > Date: Thu, 5 Jan 2023 02:02:06 +0200
> > From: Dmitry Gutov<dgutov@yandex.ru>
> >
> > On 31/12/2022 15:56, Philip Kaludercic wrote:
> > > I'd like to backport the
> > > changes from bug#58951 and apply them since they are fixing an actual bug.
> > Speaking of backporting, though, could you address Eli's last message in
> > bug#58951? Also, he seems to have reverted the change in the code, but
> > not in the docstring.
> I hoped the problem would be fixed very soon after the revert.  If
> this is not going to happen, please adjust the doc string, or tell me
> how to do that.

Looking more into it, it actually seems like the current code and 
doscstring work okay together.

The original description of bug#58951 seems a little confused, given 
that show-paren-predicate was already written in the style

  (not CONDITION)

and buffer-match-p was apparently working fine with it already. The 
revert that you did brought the previous (working) code back. The 
dosctring was problematic because it didn't quite match the behavior, 
and Philip's change fixed that.

The dosctring can say (as it does now) that

    * `not': the cadr is interpreted as a negation of a condition.

or it could more accurately say

    * `or': the cdr is a list of recursive conditions, of which at
    least one has to be met

as project-kill-buffer-conditions does. These two descriptions are 
compatible, however, as long as one only puts 1 item in said list. So we 
can sweep the difference under the rug as "implementation details".

And maybe there's nothing more to do in there.

Philip's patch in this bug, however, (the "Optimise performance" one) 
changes the semantics of 'not' in a way that would require us to change 
show-paren-predicate to '(not . (derived-mode . special-mode)).

I'm not sure if it's intended or not. Let's see what he says on that.