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

From: martin rudalics <[email-masked]>
Date: Tue, 2 Jan 2024 11:46:26 +0100

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

BTW note that C-h F ignores _any_ efforts you put into customizing
'display-buffer-alist' like say

(customize-set-variable
  'display-buffer-alist
  '(("\\*info\\*" display-buffer-pop-up-window (inhibit-same-window . t))))

So there is worse than C-h i.

martin