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

[Philip Kaludercic]

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

> tag 62417 patch
>
> João Távora <joaotavora@gmail.com> writes:
>
>> I haven't yet investigated the reason.  There are other use cases inside
>> SLY that are also failing with similar errors, but they are not as easy
>> to trigger.
>
> The simples way to fix this is to make display-buffer-assq-regexp keep
> the old protocol before trying `buffer-match-p'.
>
> diff --git a/lisp/window.el b/lisp/window.el
> index 2da2f8bb2c8..0932a05aabf 100644
> --- a/lisp/window.el
> +++ b/lisp/window.el
> @@ -7502,8 +7502,13 @@ display-buffer-assq-regexp
>  the form of the action argument passed to `display-buffer'."
>    (catch 'match
>      (dolist (entry alist)
> -      (when (buffer-match-p (car entry) buffer-name action)
> -        (throw 'match (cdr entry))))))
> +      (let ((key (car entry)))
> +        (when (or (and (stringp key)
> +                       (string-match-p key buffer-name))
> +                  (and (functionp key)
> +                       (funcall key buffer-name action))
> +                  (buffer-match-p (car entry) buffer-name action))
> +          (throw 'match (cdr entry)))))))
>  
>  (defvar display-buffer--same-window-action
>    '(display-buffer-same-window
>
> 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.

> João

-- 
Philip Kaludercic