bug#68081: 30.0.50; derived-mode and display-buffer-alist

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 2 Jan 2024 11:46:26 +0100
> Cc: germanp82@hotmail.com, 68081@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > Thanks, but now I wonder whether we should revert the change which
>  > made display-buffer call buffer-match-p.
> 
> The problem is not with 'display-buffer'.  The problem is with
> 'pop-to-buffer' and 'switch-to-buffer'.  What would you tell people who
> already customized 'display-buffer-alist' and are happy with how it
> works with 'display-buffer'?
> 
>  > It sounds like fixing the
>  > breakage in any other way is either hard or fragile or nigh
>  > impossible.
> 
> 'info' initially used 'switch-to-buffer'
> 
>      (if (get-buffer "*info*")
> 	(switch-to-buffer "*info*")
>        (Info-directory))))
> 
> Later it called 'pop-to-buffer' as
> 
>      (if (get-buffer "*info*")
> 	(pop-to-buffer "*info*")
>        (Info-directory))))
> 
> The breakage occurred when it started to call
> 
>    (pop-to-buffer "*info*")
> 
> without checking whether that buffer exists.  It sometimes backfires to
> use a feature meant for interactive use (like 'pop-to-buffer' creating
> its buffer autonomously) in non-interactive calls.  Sometimes it happens
> decades after that feature was misused.

Do other places that are affected by the same change do the same
mistake of unconditionally calling pop-to-buffer?