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

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Date: Mon, 27 Mar 2023 14:08:17 +0000
> Cc: philipk@posteo.net, 62417@debbugs.gnu.org
> 
> > since buffer-match-p accepts
> > both buffers and their names.  Please explain.
> 
> In the patch I showed, which you and Philip approved, the docstring of
> the variable display-buffer-alist was clarified to state that it is a buffer
> name string, and _not_ a buffer object, that is passed to buffer-match-p.
> This is absolutely necessary, and we've already been through this.

I don't understand why this is necessary, and I didn't intend to limit
buffer-match-p to accepting only buffer names.  Please explain why is
it necessary.

What I did say was that _if_ buffer-match-p will be able to accept
_both_ buffer names and objects _and_ will pass to the function
exactly the argument it was passed, i.e. either a buffer object or a
name of a buffer, _then_ the backward-incompatibility will be solved.

The responsibility of making sure buffer-match-p accepts a name when
the function expects only names is _on_the_caller_.  And the caller is
NOT display-buffer, it's the Lisp code which calls display-buffer or
which prepares the alist that will be passed to display-buffer.

> But naturally it's not enough to simply state that fact in a docstring.
> You have to actually make good on the promise by actually passing a
> buffer name to buffer-match-p, and not a buffer.  Otherwise, the user
> functions that the user places in display-buffer-alist WILL be called with a
> buffer _object_ always.  And for people programming against Emacs < 29,
> those functions are always passed a buffer name _string_.

Yes, but why in display-buffer-assq-regexp?  That function is not
supposed to have any knowledge about functions in
display-buffer-alist.  With the change you made you basically preclude
display-buffer-alist from having functions that want to accept buffer
objects.  That is not right.

So why cannot the code which prepares the alist make sure the function
accepts only buffer names, not buffer objects?

> I think there is still confusion.  It's understandable, as this new
> buffer-match-p protocol makes what was previously a relatively simple
> protocol is much harder to understand, because there's an added level
> of indirection.  Presumably added in the name of flexibility, but that
> flexibility actually already existed in Emacs 28, the buffer-match-p
> mini-language just adds so-called syntactic sugar.
> 
> As I said: there are other perfectly plausible ways to address this
> problem, including removing buffer-match-p from display-buffer-alist
> logic and losing this particular sugar.

Please don't fight "rearguard fights".  We are not going back on this
change which introduced buffer-match-p.  So suggesting that is a
non-starter.

> > (And I wish you
> > explained this before pushing, since there's no special rush anyway.)
> 
> There are people with broken SLYs in the Emacs 29 builds and master
> for a long time.  See the original link. I wish I didn't let it get
> this far, that was my bad, but this is hurting users today.

The users can easily make local changes.  That is not a reason to rush
changes which were not agreed upon, and leave some of us with bad
taste.