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

["João Távora" <joaotavora@gmail.com>]

João Távora <joaotavora@gmail.com> writes:

>> > Another way would be to fix this in buffer-match-p.
>> I cannot make out what is broken in `buffer-match-p'?  The patch would
>> appear to me to be redundant, because both strings and functions are
>> handled the same way in that function.  If you could explain the
>> background, I think it would be better to fix `buffer-match-p',
>> considering that this should be how it behaves.
> If you pass a string to buffer-match-p, it will become
> a buffer by the time it is passed to the function.  So
> functions that expect strings cannot be in
> buffer-display-alist after your change, whereas before
> they could.

If the previous explanation is somehow hard to understand, here's a
hopefully simpler one with a repro which doesn't require SLY.  In Emacs
28 the docstring for `display-buffer-alist` states (emphasis mine):

   If non-nil, this is an alist of elements (CONDITION . ACTION),
   where:
    
    CONDITION is either a regexp matching buffer names, or a
     function that takes two arguments - a buffer name and the
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     ACTION argument of `display-buffer' - and returns a boolean.

In Emacs 29, the docstring was changed to state:

    If non-nil, this is an alist of elements (CONDITION . ACTION),
    where:
     
     CONDITION is passed to `buffer-match-p', along with the buffer
      that is to be displayed and the ACTION argument of
      `display-buffer', to check if ACTION should be used.

Any code that was written for the Emacs 28 contract in mind like, for
example:

   (defun foop (buffer-name _alist) (string-match "foop" buffer-name))

   (add-to-list 'display-buffer-alist '(foop . display-buffer-other-frame))

Will now fail with an obscure error message.  I've checked "Incompatible
Lisp Changes in Emacs 29.1" in etc/NEWS and could not find a mention to
this, so I assume it was not intentional.

So it is most clearly a regression.

We should plug it in Emacs 29 as quickly as possible.  

I showed one way to go about it, but maybe other ways are possible, like
extending the `buffer-match-p' mini-language to allow for this case --
not sure that is feasible since it could require asking its CONDITION
function if it accepts buffers or buffer names.  Or requiring that all
CONDITION functions added in the wild now also support buffer names.

Whichever way we go, the Emacs 28 contract of `display-buffer-alist`
must be upheld before Emacs 29 is released.

João