bug#62417: ; Regression: 59ecf25fc860 is the first bad commit

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: João Távora <joaotavora@gmail.com>,
>   62417@debbugs.gnu.org
> Date: Sat, 25 Mar 2023 13:17:40 +0000
> 
> We would have to call the function with the buffer name instead of the
> buffer object.  So the `buffer-match-p' fix would look like this:
> 
> diff --git a/lisp/subr.el b/lisp/subr.el
> index 99ddd813867..3210ab05702 100644
> --- a/lisp/subr.el
> +++ b/lisp/subr.el
> @@ -7140,8 +7140,8 @@ buffer-match-p
>                         (string-match-p condition (buffer-name buffer)))
>                        ((pred functionp)
>                         (if (eq 1 (cdr (func-arity condition)))
> -                           (funcall condition buffer)
> -                         (funcall condition buffer arg)))
> +                           (funcall condition (buffer-name buffer))
> +                         (funcall condition (buffer-name buffer) arg)))
>                        (`(major-mode . ,mode)
>                         (eq
>                          (buffer-local-value 'major-mode buffer)

No, I think we should pass to the function the original buffer-or-name
argument.  It makes no sense to me to have buffer-match-p second-guess
what a caller-defined function should get as its argument.

> I don't think I am a fan of this, as most of the time a buffer is more
> immediately useful.  Perhaps João's initial change would be better in
> that case, for the sake of backwards compatibility?  Or does it make
> sense to mention this as an incompatible lisp change?

The best solution is the one that completely removes the backward
incompatibility, and I think what I suggested does just that.