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

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

I'm _not_ doing that.  Buffer-match-p continues to accept buffer objects
or buffer names.  It's only that _when given a buffer name and a
function, it will call that function on the buffer name string_. 

> Please explain why is it necessary.

I've tried already 3 or 4 times.  I don't understand how better to
explain than to show you some perfectly code that worked on Emacs 28 and
doesn't work in Emacs 29 from yesterday.

If you want I will revert the patch, but _some_ solution should be
found.  Unforeseen, unmotivated, backward-incompatible lisp changes this
late in the game would be a sad thing.

> 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.

And this is _exactly_ what happens.  But that, by itself is not enough,
becase display-buffer-assq-regexp was _also_ changed to always pass
buffer objects along with functions that expect buffer names.

>
> 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.

Because that function was changed in order for buffer-match-p.  It was
_that_ change that broken compatiblity.

But it can be fixed anywhere else.

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

The alist is open to the public, it is the user-facing interface.  The
"code that prepares the alist" is out in the wild and has worked fine
from Emacs 24 on, maybe even earlier.

>> 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.

Just a suggestion.  It is one of the many things that would fix this.

>> > (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.

The bad tasting thing here was introducing the bug in the first place.
I'm just trying to solve it.  I've proposed two ways already.  If you
have better one, go ahead, I don't care, I really don't.  I just want
SLY users not to have to worry about this.

João